Start with a buying decision
A catalogue filter should answer a question a shopper actually has before opening individual products. For a small Hong Kong retailer, that might be whether a kettle fits a compact counter, whether a replacement part matches a model, or whether an item is available for collection. Start with real product attributes and actual customer enquiries. If staff cannot explain how an attribute changes the buying choice, do not add it merely because the database contains a field. Conversely, a useful attribute hidden only in product descriptions forces shoppers to open and compare many pages. Search, filters and sorting do different jobs: search finds a known term, filters narrow a set by stated constraints, and sorting orders the surviving set. Decide which job the customer is trying to perform before designing controls.
Audit the product data before promising a filter. A colour choice is only reliable if the same colour vocabulary is used across products and variants; an availability choice needs a defined source and update interval. Decide whether the filter applies to a parent product or to a purchasable variant. A shoe displayed as one card may have one size sold out and another available. If a size filter shows the card but sends the shopper to an unavailable default variant, the control has failed its purpose. Write an attribute dictionary with allowed values, data owner, update trigger and the on-page explanation of each value. Mark uncertain or missing data as unknown internally; silently treating it as false can hide products that might be suitable.
Make the selection legible
Use labels in the language of the shopper rather than database column names. A price range needs a currency and a clear rule about whether endpoints are included. For a multi-select attribute such as material, checkboxes can communicate that several values may be chosen; for a mutually exclusive choice, use a radio group or a single select. W3C guidance explains that related controls benefit from a visible and programmatic group name, commonly a fieldset and legend. The individual labels still need to make sense when read on their own. Do not convey selected state only through colour, and ensure focus and checked states remain visible with a keyboard. An expand button must reveal a named set without changing the current product set until the shopper chooses a value.
Decide explicitly when the results change. On a short desktop list, immediate updates may be understandable; on a long mobile filter panel, an Apply button can prevent repeated loading and give the shopper a chance to review the set. Either choice needs a consistent rule. Display selected conditions above the results as removable chips or plain text controls, with a clear way to remove one condition and a separate way to clear all. Never reset other choices unexpectedly when one filter changes. If the back button loses the selection, the shopper cannot compare two products without rebuilding the same query. Keep the chosen state in a shareable URL where it is suitable, and restore it on browser navigation. That user-state decision is separate from whether search engines should crawl filtered URLs.
Explain the results honestly
Show the number of matching products after a change, but count the same unit that is displayed. If the interface shows product cards while the database counts variants, a message claiming twelve products can be misleading. Put the count near the results and identify the active constraints. W3C's status-message guidance gives a search-result count as an example of a change that assistive technology should be able to announce without forcibly moving focus. For dynamic filtering, announce a concise updated count once the result set is stable. Avoid announcing every intermediate request or reading out the entire grid. If an update fails, preserve the previous visible result set and say that the new selection has not yet been applied, rather than silently showing stale products under a new count.
Zero results are a decision point, not an error by the shopper. State which combination returned nothing and offer the smallest useful adjustment, such as removing the most restrictive value, while leaving the other choices intact. Never invent a near match as though it satisfies the selected constraint. If stock is uncertain, distinguish an out-of-stock item from a missing stock record. A shopper looking for collection today needs a stricter availability promise than one browsing for ideas. Make the displayed product price and availability come from the same current records used by the filter, or explain the delay. A filter that looks precise but disagrees with the product page can waste more time than no filter at all.
Work through one shop example
Imagine a shop selling desk lamps in several finishes and plug types. A buyer needs a lamp that fits a small desk, uses the plug supplied locally and can be collected this week. Begin with three candidate controls: width band, plug type and collection availability. Confirm that width is measured in one unit and that every eligible variant has a value. Define collection availability from the actual fulfilment location rather than total warehouse stock. Test the combination against a known lamp: selecting its plug and width should retain it, while selecting an incompatible plug should remove it. Open the retained card and check that the variant and collection promise match the filter. This is an illustrative test case, not observed customer behaviour or a claim about any shop's stock.
Then test a shopper journey rather than an isolated control. Choose two filters on a narrow phone, apply them, open a lamp, go back, remove one condition, and use the keyboard to reach the result count and first card. Repeat with a screen reader to hear the group name, option names, selected state and updated count. Test a deep link to the selected set and a reload after the catalogue changes. Finally, test a missing width value and a product that goes out of stock while the shopper browses. Record the expected behaviour for each case before implementation so product staff, designers and developers agree on what a pass means. A useful filter is a promise about the products that remain; every handoff in this journey must keep that promise.
Launch with checks that reveal mistakes
Before release, sample a small set of products from each category and compare their stored attributes, filter membership, card text and detail page. Include products with multiple variants, incomplete attributes, and a recent stock change. Measure whether shoppers use a control and whether it helps them reach a relevant product, but do not call raw filter clicks a success metric. A high click count can also mean labels are confusing and people repeatedly revise choices. Pair usage data with customer-service questions and short observation of real tasks. If the data feeding a control cannot be kept current, narrow or remove that control until the underlying catalogue is repaired. This is a product decision, not a reason to misstate certainty.
Give one owner responsibility for the filter vocabulary and another clear route for correcting bad records. When a new product family is added, review whether its values belong in an existing group or need a new decision path. When an item is retired, confirm it disappears from active result counts as intended. Document the rule for combining values: many shops use OR within one group and AND across groups, but the interface should state and test its actual behaviour. A customer who selects blue and green may expect either colour; a customer who selects a size and material usually expects both. End the release review by asking staff to complete three ordinary shopping tasks with the live catalogue and by recording discrepancies for repair. The goal is a trustworthy route from a shopper's constraint to an actually suitable item.
Before you proceed
- Does each filter value correspond to a reliable product or variant attribute?
- Do selected conditions survive navigation, and does the result count match displayed cards?
- Can keyboard and screen-reader users identify groups, selected options and updated results?
