Mobile app product catalog design: where orders are lost
A user opens the app with a specific need — they need one item, not the entire storefront. If the path to a product card takes more than three steps, part of the audience drops off during catalog navigation: category, subcategory, filter, sorting. Each intermediate screen is a point where a person closes the app and goes to search.
The most costly loss is drop-offs on the results page. Returning from a product card resets filters, sorting, and scroll position, and the buyer ends up at the beginning of the list even though they were comparing the third or fourth item.
Resetting filters hits the comparison scenario specifically, and that is exactly where the purchase decision is made.
A separate issue is an overloaded results page. A tile with six attributes per card looks convincing in a mockup, but on a real assortment the differences between items blur, and price and availability have to be hunted deeper. The person does not understand how one product differs from another and postpones the choice.
Mobile app product catalog design starts not with a mockup but with the structure of the path and the screen state on return. The cost of these failures for the owner is measured not in traffic but in the share of those who already came with purchase intent. We break down how this is addressed — from catalog navigation to listing behavior.
What reworking navigation and product cards changes
Catalog rework starts not with the product grid but with a map of the path to purchase.
We mark up every transition — category, filters, product card, variant selection, cart — and identify drop-off points: going back with filters reset, lost search context, leaving for another app to compare.
We check positions and gestures against Apple Human Interface Guidelines — familiar elements do not have to be explained again.
The number of steps to purchase drops when size or configuration selection happens right on the product card, quick filters stay on screen, and list state is preserved on return.
The first screen opens from cache, the next page is preloaded — an empty screen stops being a drop-off point. Benchmark: four actions from entering the catalog to the cart instead of the previous seven.
Drop-offs at the selection step are eliminated by comparison inside the product card: specifications are displayed in a table, differences between variants are highlighted, and the selection button remains reachable while scrolling.
The separate comparison screen was removed — it collected traffic but lost the buyer in the transition. The indicator for this area is the share of scenarios with two or more back navigations.
Category browsing depth grows when the hierarchy is clear at first glance: clear names, item count, transition to an adjacent section from the product card. Repeat visits rely on predictability — having found what they need without search, a person returns to the same place. Support load also drops: "I can't find the section" requests go away.
Listing formats: list, grid, feed, hybrid
Listing format is a decision about density, not decoration: how many items a person sees on screen and how many taps are needed to reach the product card.
A list fits 6–8 names with title, price, and action button; a grid fits 4–6 with a large photo; a feed fits 2–3 with a full-width image.
The format is chosen based on assortment and purchase scenario, not taste. A catalog where products are compared by specifications lives in a list; visual categories — clothing, furniture, decor — live in a grid or feed.
The benchmark is simple: the share of items with quality photos and the frequency of comparison by parameters.
How the modes differ
| Format | When it fits | Limitations |
|---|---|---|
| List | Products with specifications, comparison by parameters, catalog search | Low image density, visual categories sell poorly |
| Grid | Homogeneous categories with good photos, choosing "by eye" | Long names are truncated, specifications move into the product card |
| Feed | Collections, new arrivals, promotional blocks, one product per screen | Few items on screen, long scroll to the right one |
| Hybrid listing | Large catalog: some categories visual, some parametric | Higher support burden: two sets of templates and a mode switcher |
Hybrid removes the main compromise: the mode is selected by category type, and the client's choice is preserved between sessions — when switching, they do not lose their place in the listing.
We test density on the real assortment: the share of transitions to the product card and scroll depth matter more than the beauty of the mockup.
Stages of work on the storefront interface
We start work on the storefront not with a mockup but with an analysis of how customers search for products now: we review analytics, session recordings, and support requests, and mark the steps where people abandon the catalog.
Only after that do we lock the structure and test it on a prototype — this way the interface does not have to be redone in the middle of the build.
- Analysis of the current storefront. We consolidate data on transitions, drop-offs, and returns to the catalog, find where the share of buyers who reach checkout is lost, and which sections they cannot find at all.
- Navigation scheme. We break down the category, filter, and search tree into specific screens, check nesting depth, and whether a popular product appears on the first screen of the list.
- Interactive prototype. We assemble a clickable scenario on the real assortment — with empty states, slow loading, and an out-of-stock product, not just perfect product cards.
- Scenario testing. We run typical paths: search by SKU, selection by filters, comparison, and return to the list. We make edits before handoff, while they remain an edit in the scheme, not in the code.
- Handoff to development. We provide screens with element states, grid rules, and copy so the build proceeds without guesswork and unnecessary clarifications.
- Build support. We compare the finished app with the prototype on intermediate builds and close discrepancies as they appear.
Describe the task — we will come back with an estimate and a stage-by-stage plan.
Mockups, screen states, and layout rules
The catalog lives longer than other screens: categories and promotions change, while the product card grid remains.
That is why we hand over not static mockups but a system description — what the user sees at each loading step, what a screen without data looks like, and by what rules blocks rearrange for different device sizes.
- State map: loading with card skeletons, empty search result, network error, partially loaded data — with a description of what happens on screen in each case.
- Component library: product card, category tile, filter, availability badge — with "default," "pressed," "disabled" variants and nesting rules.
- Style tokens: colors, spacing, radii, typography, and shadows as named values — editing one token changes the entire catalog.
- Adaptation rules: grid transition from two columns to three, minimum tap target sizes, behavior of long names and prices on narrow screens.
- Empty screen state: copy, illustrations, and alternative actions — reset filter, go to an adjacent category.
- Update policy: how to add a new card type without breaking existing screens, and who is responsible for changing tokens.
- Specification for layout and acceptance checklist: padding, scroll behavior, data loading points, testing on small and large devices.
Layout follows unambiguous rules, not guesses from a picture — catalog improvements do not require re-establishing agreements from scratch.
Case study: app storefront before and after rework
The initial storefront was designed as an extension of the website catalog: a vertical list with expandable filters at the top, a product card without price and availability on the first screen, and returning from the card reset the list position to the top.
Because of this, a user who had selected a product by three parameters lost the selection on return and started filtering again.
According to Baymard Institute measurements, a significant share of mobile checkout drop-offs is related specifically to navigation and loss of context when returning to the list.
What we changed
Filters were moved into a separate modal layer with state preservation and a counter of applied conditions on the entry button.
The product card received price, availability, and an add button on the first screen, and the list received scroll position restoration and preservation of selected parameters between sessions.
Loading was made incremental, triggered upon reaching the last card, instead of waiting for the full selection.
Metrics before and after
The share of sessions with a transition to a product card grew from 41% to 63% — price and availability on the first screen had an effect.
Returns from the product card to the list with preserved selection reduced repeated passes through filters: the share of abandoned carts fell from 78% to 61% on the same audience and the same assortment.
Support requests with navigation complaints decreased threefold, and this relieved the first line more than any edit to hint texts. The comparison ran on equal traffic shares so seasonality would not distort the picture.
What to do if the storefront is already built on a ready-made template?
A standard template is a ready-made set of screens where the catalog, product card, filters, and cart are rigidly connected: the storefront is assembled from ready-made blocks, and data arrives in a predefined structure.
As long as the assortment is homogeneous and the selection logic is simple, such a solution covers the task. Template limitations appear later — when the business requires something not provided for in the block structure.
Partial rework works where the change is described by data and settings, not a new screen structure.
The set of card fields, order of sections, sorting and filter rules, labels, banners, collections — all of this changes on the data source side, without rebuilding the app and without a new release in the stores.
When the storefront reads an external service, you control the catalog content while leaving the shell unchanged.
Hard limitations begin where a different data schema is needed: product variants within one card, dependent specifications, item comparison, personalized collections, non-standard loading and transition logic.
Such an edit runs not into decoration but into the screen structure — the template cannot store and display these relationships. Workarounds via settings produce hacks that fall apart at the first platform update.
To understand which case you have, it helps to examine the boundary: the data schema, extension points, and what the template exposes outward. If the scenario can be assembled from data, we go through partial rework.
If custom logic is needed, we change individual screens without rebuilding the entire app, in order to preserve a working cart and current releases.
Technical concerns before starting work
Before the start, the client checks not deadlines but how the storefront will behave in operation: whether it will withstand a large assortment, whether it will fall apart under unstable traffic, and whether their team will retain control over the code. Below are answers to the concerns that come up most often.
How to separate a storefront problem from a traffic problem?
Catalog bottlenecks are visible in list behavior. If empty cards flash during fast scrolling, but reopening from cache is smooth — the issue is in the loading and incremental page loading strategy.
If the screen lags even with a warm cache, we look at rendering and the number of unnecessary re-renders. We take measurements on a real device on a throttled network and separate the two classes of causes by numbers, not by feel.
Can changes be released in parts?
Yes. The catalog is divided into independent blocks — product grid, filters, product card, empty states — and each changes separately. Components sit on a shared data contract, so editing one block does not drag in rewriting neighboring ones, and release remains predictable.
Will your team be able to maintain it?
Yes. We hand over components, the data schema, state rules, and screen notes — this is enough for edits within your team to not require us. A large assortment and spiky traffic do not change the architecture: filters and loading work by the same rules.
Let's discuss the task: what to send for an estimate
The more complete the inputs at the start, the more accurate the scope of work and stage order — fewer clarification rounds and edits to an already agreed estimate.
There is no need to prepare separate documents: screenshots, design files, or a working build already in the project will do.
- Access to current catalog screens: we look at the card grid, the "list is empty" state, loading additional pages on scroll, and behavior on a weak connection.
- Section structure and category hierarchy: how many nesting levels, how filters and sorting are arranged, whether tags and collections exist.
- Purchase scenarios: the path from entering the catalog to the cart, return points, how search and deep links from emails and ads work.
- Behavioral data: analytics exports — where users leave, which filters they do not use, how far scrolling reaches.
- Platform limitations: minimum supported OS version, device list, offline mode and image cache requirements.
- Localization requirements: languages, unit and date formats, interface behavior for right-to-left writing.
- Design system and component library: if one exists, we reuse it; if not, we will estimate its creation as a separate block.
After reviewing the inputs, we come back with a work plan, stage order, and timelines — and separately note the places where your product decisions are needed.