A shopper has reached the Everyday sneaker range in Example Sneaker Store, a fictional shop. They want a pair for a walking commute and casual workplace, in their labeled US men’s size 9, in black or navy, available to buy. Can the list help them find plausible options without opening every product and discovering the wrong size is in stock?
A useful product listing helps people compare and narrow individual items. It may sit on a category page, search page, or curated collection. Here, the range is already chosen, with Use: Everyday selected. We’ll follow the shopper through the listing rather than repeat how the store organizes its categories.
All models, brands, use tags, and stock below are fictional teaching inputs. They are not test results, fit advice, or claims about real shoes.
For an initial review of your own list, ask whoever maintains the store for a known size-and-color combination and whether it is available. Select those requirements, inspect a returned product, then remove one choice. The sections below explain what each part should help the shopper do.
Give Each Card a Reason to Open the Product
A product card should help the shopper decide whether an item deserves a closer look. Too little information sends them through repeated product-page visits. Too much makes the list difficult to scan.
In our store, a card saying only “Harbor” beside a lifestyle photograph leaves important questions unanswered. A more useful card identifies the model, shows the shoe clearly, presents the actual price, and makes relevant color and size availability intelligible. The illustration does not supply prices, so we won’t invent a ranking or claim that one model is cheaper.
Choose the remaining details according to the shopper’s decision. Full construction specifications and a brand story usually belong elsewhere unless they resolve something essential before opening the product. Put corresponding details in consistent places so someone can compare Harbor with another model, Ridge, while browsing.
NN/g’s anatomy of a list entry explains this balance between useful information and clutter. A formal comparison tool is one possible feature, not a prerequisite for comparing these shoes.
Make the Important Requirements Easy to Select
The shopper needs size 9. Looking at attractive styles that cannot be bought in that size is wasted effort. Make the size choice recognizable, including the sizing system, rather than hiding it under a vague label such as “Configuration.”
Relevant controls for this fictional range include use, size, color, and availability. Brand or price may also matter to the real assortment and customer. Don’t add a filter merely because another store has it, or offer ratings without reliable rating data.
NN/g’s guidance on filter categories and values helps connect the controls to the shopper’s language and requirements. In a real store, use customer research, search terms, and questions to decide what deserves prominence.
On a phone, open the filter controls and follow the same task. Can the shopper find their size, choose colors, understand what is selected, and return to the products? A desktop sidebar is not a universal phone solution. If there is an Apply action, make its effect and the route back to results clear.
Let “Black or Navy” Mean Either Color
Our shopper would accept black or navy. Selecting Navy after Black should keep both when the control offers alternative colors. Otherwise they must compare two separate result sets from memory.
The combined request is: Everyday, size 9, black or navy, and available. A matching shoe needs the selected size and an acceptable color together. It does not need to be both black and navy at once.
Baymard’s research on combining filter options explains why alternative values within a filter should work together. Match the meaning of the choice rather than applying this rule blindly to every control. Selecting two required features could reasonably mean a product must have both.
Check the Same Available Variant, Not Stock Somewhere in the Model
To see why the combination matters, consider this small subset of our fictional catalog. It is not the whole store, and the listed sizes are US men’s:
- Harbor, Brand A, Everyday: black in size 9 is available. Navy in size 9 is unavailable. Navy in size 10 is available.
- Ridge, Brand B, Everyday: navy in size 9 and black in size 10 are available.
- Court One, Brand B, Court: black in size 9 is available.
With Everyday, size 9, black or navy, and available selected, Harbor and Ridge qualify. Harbor has an available black/9 option. Ridge has an available navy/9 option. Court One is outside the chosen use.
Now remove Black, leaving navy, size 9, Everyday, and available. Only Ridge qualifies in this subset. Harbor must not appear as an available match by combining its black/9 stock with its navy/10 stock. Its actual navy/9 option is unavailable.
That false match creates a concrete customer failure: the list appears to have found the requested shoe, but the product page cannot offer the combination the shopper selected. Better-looking controls won’t repair that mismatch.
Ask the catalog or search owner to verify returned products against a dated record of which size-and-color combinations are available. At least one available variant must satisfy the selected size and one of the acceptable colors together. Record the mismatch you can observe rather than diagnosing the search configuration from its appearance.
A store may intentionally show unavailable products for discovery, but that state needs to be clear. It should not silently behave that way when the selected control promises available options. Inventory can change, so establish the data and timing before calling a result incorrect. If you cannot get that information, report the selected options and what the page showed, then ask whoever maintains the store to confirm the stock.
Group Variations Without Concealing the Match
Harbor’s black and navy versions need not look like unrelated models. One card can show the available colors and keep the list easier to compare, provided its information reflects the current selection accurately.
In the black-or-navy size-9 available view, Harbor qualifies through black. Showing a navy shoe as the apparent matching option without explaining its unavailable state could mislead the shopper. In the navy-only size-9 available view, Harbor does not qualify at all in our subset.
Grouping the display and checking variant availability are separate responsibilities. Don’t combine genuinely different models to tidy the grid, hide important differences, or make color choices discoverable only by hovering over a card.
Show What Is Shaping the List
After returning from the phone filter panel, the shopper should be able to understand the current selection. “Filters (4)” alone does not tell them that Everyday, US men’s 9, Black, Navy, and Available are affecting the results.
Show the selected values in a readable overview and let the shopper remove one choice without starting again. If they remove Navy from the original two-color selection, black/9 Harbor remains the matching model in this subset. Size, use, and availability should stay selected.
Baymard’s applied-filter guidance discusses this context and the phone-layout tradeoffs. A stacked overview makes values visible but uses height. A horizontal one saves height but can hide choices off-screen. Judge whether this shopper can understand and change the selection, not whether the site uses a prescribed arrangement.
If you show a result count, establish what it counts. Two model cards are not the same as two available variants. Ask the team to check the total against the same catalog data and grouping used for the display.
Sort the Matches, and Make Empty Results Recoverable
Sorting changes the order of candidates. Filtering decides which ones meet the requirements. A shopper may prefer lower prices without having a firm budget, but a low-price sort cannot establish that a shoe is available in size 9.
Keep the active sort understandable and retain the selected filters when it changes. Use options backed by actual data. Don’t invent “best-selling” or rating-based orders to fill a menu.
For a recovery example, start with Everyday, navy, size 9, and available. Ridge qualifies. Adding Brand A produces no matches in this illustrative subset. The page should explain that the chosen combination has no matches and keep the choices understandable.
Removing Brand A restores Ridge while preserving the size and color requirements. Don’t silently remove size 9 or present unmatched shoes as though they satisfy the request. If you offer alternatives outside the selection, label them as alternatives.
Check the Whole Refine-and-Compare Task
On the actual phone and desktop layouts, choose size and color, return to results, compare the relevant card details, and remove one choice. Use known catalog data to check the result. Repeat the empty-result case and see whether the next action preserves the shopper’s requirements.
Try the controls with a keyboard, too. Ask an accessibility-aware tester to check control names, selected and expanded states, panel behavior, and any displayed result-status messages. A visible result count or screenshot alone cannot confirm what assistive technology receives.
Include the page address, checked view’s dimensions, selected options, time, and screenshots when you report a problem. Keep your observation separate from the stock or accessibility checks someone else still needs to complete.
A useful hypothetical note for our store would be:
The Everyday, navy, US men’s 9, available view includes Harbor, but this example’s navy/9 variant is unavailable. Please check that one available variant meets the size and color together. Harbor’s black/9 and navy/10 stock should not make it qualify.
The goal is a shortlist the shopper can trust enough to explore further. Clear cards and controls help them compare, while accurate matching keeps that comparison connected to something they can actually buy.
