Everything about Popou,
explained clearly.

Popou is built for product designers, UX researchers, product managers, frontend engineers, QA engineers, founders, and anyone studying how digital products work.

Guests can explore published knowledge, registered users can personalize their research, and administrators govern content quality and publication.

Product research is often scattered across folders, design files, articles, cloud drives, and personal notes. A screenshot without context is difficult to search, compare, maintain, or reuse.

Popou turns those disconnected references into searchable knowledge with hierarchy, version history, ordered journeys, and maintained authorship records.

A screenshot gallery emphasizes visual browsing. Popou emphasizes understanding: where a screen belongs, what task it supports, which version it came from, and how it connects to the screens before and after it.

That makes Popou suitable for repeatable research and product benchmarking rather than collecting disconnected images.

No. Popou is not intended to be general image storage, a design portfolio, or a place to upload unrelated visual work.

Screenshots are accepted as evidence inside a structured product journey and never exist independently from their Flow and broader product context.

Popou currently highlights many products used in Indonesia, reflecting the library and community being built today. The underlying knowledge model is not limited to one country or industry.

Coverage grows through administrator-led curation, so the available catalog may expand over time.

Yes. Guests can browse, search, and open publicly published Products, Features, Flows, Screenshots, and historical Versions without signing in.

An account is only needed for personalized features such as saving research and organizing Collections.

Enter a term such as a product, feature, flow, or screen name and explicitly submit the query. Popou searches published knowledge and returns results with their complete product hierarchy.

Search is case-insensitive and supports partial matching. Exact matches are prioritized before Flow, Feature, Product, Screenshot, tag, metadata, description, and older-version matches.

Search can surface Products, Features, Flows, Screenshots, and relevant supporting metadata. Each result preserves Product, Platform, Version, Feature, and Flow context where applicable.

Private drafts, active submissions, review material, and approved-but-unpublished content are never exposed through public search.

The public Explore experience can refine results by result type, Category, Platform, and sorting options. The domain is designed to support more specific Product, Version, Feature, and Flow refinement as the catalog grows.

Filters never remove the hierarchy from a result; they only narrow which published knowledge is shown.

Popou uses explicit search execution so you can finish forming a query before processing begins. This keeps the experience predictable and avoids unnecessary requests for every keystroke.

Suggestions may help construct a query, but they do not silently replace the words you submit.

When multiple results are equally relevant, Popou prioritizes the latest valid published Product Version. The result still shows its version context so you know which product state you are studying.

Older published Versions remain accessible through a Product's version timeline.

Try a broader product or task term, remove a filter, or browse by Category. A missing result may mean that the experience has not been documented or that relevant knowledge has not yet been published and indexed.

You can also suggest the missing product directly to the Popou team.

Popou uses the hierarchy Category → Product → Platform → Version → Feature → Flow → Screenshot. Each child inherits context from the levels above it.

You can open a deep link directly, but the hierarchy remains visible so the screen or journey never loses its business meaning.

A Category is the highest business classification, such as Finance, Travel, or E-commerce. A Product is the digital application being documented, while a Platform identifies a specific implementation such as Android, iOS, Web, or Desktop.

A Product can have multiple platform-specific knowledge histories because its experiences may differ across platforms.

A Version represents a released state of a Product on a particular Platform. Popou uses the product's native version identifier where it is known instead of inventing a separate numbering system.

Every published Version is an immutable snapshot, making historical research dependable even after the Product changes.

A Feature is a business capability such as Authentication, Checkout, Booking, or Payment. A Flow is a complete user journey within that capability, such as Login with OTP or completing a card payment.

One Feature can contain several Flows, and every Flow contains an ordered sequence of Screenshots.

A Screenshot is the smallest unit of knowledge in Popou. It represents one interface state at a specific position inside a Flow.

Its value comes from its title, description, ordering, Product, Platform, Version, Feature, Flow, tags, and attribution—not only from the image itself.

An isolated screenshot rarely explains what the user was trying to do, which app state produced it, or what happened next. Requiring a Flow ensures every Screenshot is part of a meaningful journey.

This rule also improves search quality, comparison, and the reliability of product research.

Digital products evolve, and replacing old documentation would erase evidence of how a journey worked at a particular time. Popou preserves historical Versions so past research remains trustworthy.

The latest published Version is shown by default, while older Versions remain available from the timeline.

Incremental versioning records changed knowledge in a new Version while allowing unchanged Features, Flows, and Screenshots to be inherited from the prior state.

Users still see a complete Version, while administrators avoid duplicating everything that did not change.

No. Missing historical Versions are allowed because trustworthy partial history is more useful than fabricated completeness.

The timeline reflects what has actually been documented and published, and administrators can fill gaps later.

The Version identifies the Product release being documented. The published date records when Popou made that knowledge publicly available.

A historical app Version can therefore be documented and published on Popou much later than the app's original release date.

Published Versions are immutable and cannot be hard-deleted. Corrections or product changes are introduced through governed Admin drafts and new Version records instead of silently rewriting history.

Administrators may archive knowledge from active discovery while preserving its history, relationships, attribution, and audit records.

Popou supports version timelines and basic change summaries as part of its core experience. Advanced visual or side-by-side Version comparison is a Post-MVP capability and may not yet be available.

Until then, open each published Version from the timeline to inspect its complete state.

The current public experience offers free account registration. Popou does not currently document paid plans or feature tiers, so the site does not make a promise about future pricing.

You can still browse all published public knowledge without creating an account.

Guests consume public knowledge. Registered Users can access personal capabilities, while Administrators create, review, publish, moderate, and maintain the catalog.

Administrator access is assigned by the platform and is never available through public registration.

A Bookmark is a quick save for an individual Product, Feature, or Flow. A Collection is an organized private grouping intended for a larger research topic.

These personal-workspace capabilities are part of the Popou MVP definition. If they are not visible in your account yet, they are not currently available in the active interface.

Yes. Personal workspace content and internal Admin drafts are private or restricted to authorized accounts. They must never appear in public discovery or search.

Only knowledge that completes review and publication becomes publicly accessible.

Use the password-recovery flow from the sign-in page and complete any required email verification. Make sure you are using the same email address originally registered with Popou.

If recovery does not resolve the problem, contact the Popou team and describe the issue without sending your password or verification code.

An Admin content package moves from Draft into the governance workflow: Submitted, Under Review, and then one of Revision Requested, Approved, or Rejected. Approved knowledge enters a separate publication process before it becomes public.

This separation lets reviewers focus on quality while publication performs final integrity checks and creates the public Version snapshot.

Review covers content completeness, hierarchy and relationship correctness, screenshot quality and order, taxonomy consistency, duplicate risks, and policy compliance.

Feedback can target a specific Product, Version, Feature, Flow, or Screenshot so the responsible Admin knows exactly what needs attention.

Revision Requested means the Submission can be corrected and resubmitted using actionable feedback. Rejected means the package did not qualify and requires a reason. Approved means it passed review but is not public yet.

Publication is a separate final transition that turns approved material into public community knowledge.

Open the affected Submission, review the entity-level issues, update the requested content, run validation again, and resubmit the same package.

Submission and review history remain immutable, so the complete sequence of feedback and revisions stays traceable.

Yes. Popou supports a single-admin operation, but every decision still requires a complete checklist, reason, and permanent audit event.

Administrators cannot bypass versioning or directly rewrite already published knowledge.

Knowledge becomes publicly accessible after the publication transaction succeeds. Search indexing then runs asynchronously, so a newly published page may be accessible before it appears in search results.

An indexing failure does not roll back valid publication; it is observable and retryable by administrators.

Archiving removes knowledge from active public discovery without deleting its history, relationships, or audit records. Restoring returns that preserved knowledge to public visibility.

Hard deletion and unpublishing are intentionally not part of the MVP publication workflow.

Verified knowledge has passed the governed Submission, Review, Approval, and Publication workflow. It indicates that required context, relationships, media quality, and policy checks were completed.

Verification improves reliability, but product interfaces can still change; always check the Platform, Version, and published context shown on the page.

Quality is protected through structured fields, validation rules, duplicate warnings, minimum Flow requirements, administrator review, atomic publication, version immutability, moderation, and audit history.

Popou prioritizes trustworthy context over publishing the largest possible volume of screenshots.

Use the Report content action on supported public knowledge pages and select the reason that best describes the problem, such as misleading metadata or a content concern. Add enough detail for the moderation team to investigate.

A report opens a moderation case; it does not immediately remove or alter the published record.

Popou permanently records who created or improved published knowledge and when the change occurred. Attribution is retained across later Versions and is not transferred to the reviewer or publisher.

Governed ownership allows ongoing maintenance while preserving the historical author of each published revision.

Public search indexes only Published Knowledge. Drafts, submissions, review packages, personal Collections, Bookmarks, and administrative material are excluded by visibility and authorization rules.

If you believe private material is publicly visible, stop sharing the affected URL and contact Popou immediately.

Not in the current MVP. Search is structured and keyword-based, with ranking designed around exact matches and the Popou knowledge hierarchy.

AI-assisted search, semantic search, natural-language search, and AI-generated summaries are future possibilities rather than currently supported capabilities.

Not currently. OCR-powered screenshot search and visual similarity search are explicitly outside the MVP scope.

Screens are discoverable through their structured titles, descriptions, tags, metadata, and surrounding Product, Feature, and Flow context.

A public API, enterprise single sign-on, official knowledge integrations, and granular enterprise administration are not part of the current MVP.

Any future availability should be treated as unconfirmed until it is announced through an official Popou channel.

Product and Category additions are curated internally by Popou administrators to keep naming, evidence, and classification consistent.

Send product suggestions to the Popou team with a clear product name, platform, and reason it would improve the catalog.

Email hello@popou.design with a concise description, the page URL, the expected behavior, and what actually happened. Screenshots can help, but remove passwords, verification codes, and other sensitive information first.

For an issue with a specific published record, prefer its Report content action so the moderation case retains the correct content context.