Start with the shopper’s decision
A sort control changes the order of products already eligible for a list. It should help a shopper answer a specific question: which available item is cheapest under the displayed price, which was added most recently, or which matches a search query most closely? A filter answers a different question by removing items that fail a condition. Mixing these functions creates confusing counts and makes “sort by price” seem broken when hidden products reappear. Write down the candidate sort options and the business definition behind each before building a dropdown. A short, truthful set is often more useful than ten unexplained choices.
The default order needs a name too. “Recommended” implies an editorial or algorithmic judgement that the shop should be able to explain; “Featured” may mean selected placement; “Relevance” only makes sense when there is a query or another matching signal. If the store has no documented ranking method, a neutral label such as “Default order” may be more honest. The control should show the current choice after the page loads, after a refresh, and after the customer follows a product and returns. Do not advertise a performance or conversion gain without measurement. The immediate standard is simpler: a customer can predict what the selected option will do and observe that it happens.
Define the value being ordered
Price ordering is deceptively specific. Is the key the displayed unit price, a sale price available to everyone, a member-only amount, or a price range for variants? The shopper must not see “low to high” while the visible cards appear out of order because the backend used a different price. Choose one basis, display it consistently, and make exceptions explicit. If a product has several variants, decide whether the list card shows the lowest purchasable variant or a range; the sort key should match that visible promise. Delivery charges that depend on postcode or basket cannot be quietly folded into a product-only sort key.
Use a worked hypothetical example to test the rule. Product A displays a current public price of HK$80, product B HK$95, and product C a range starting at HK$70. If the label promises increasing displayed starting price, the sequence should be C, A, B. If C has no purchasable variant at HK$70, the displayed range and sort key both need correction; changing only the order hides a catalogue defect. This example is illustrative and says nothing about actual store prices. Test equal prices as well: choose a deterministic secondary key, such as product identifier, so the same set does not shuffle every time a customer moves between pages.
Use honest labels for other orders
“Newest” should specify what event makes a product new. A recently edited description is not necessarily a new arrival. If the catalogue has a reliable first-publication date, use that; if it does not, avoid a claim the data cannot support. “Best selling” likewise needs a defined period, counted event, treatment of returns, and minimum data coverage. Without those rules, the label can mislead. “Relevance” for search may combine text matching and merchant choices; be clear enough that an exact match does not appear inexplicably far below unrelated products. These are editorial and data decisions, not merely interface copy.
Availability is another source of confusion. If unavailable products remain visible, decide whether they are included in the same sort and how their state is marked. A sort choice should not silently act as an availability filter unless the label says that. If the business wants available items first, state the rule and keep the price or date order within each availability group. Do not promise stock in the sort label unless the stock data and checkout reservation process can support that promise. A buyer should be able to distinguish “shown earlier because it is available” from “priced lower”. The decision record should identify which system owns the availability state.
Make the control and result understandable
W3C guidance calls for labels that identify form controls. Give the sort selector a visible name such as “Sort products by”, and make option text explicit in English and Traditional Chinese. “Price: low to high” communicates more than an arrow icon. The selected option should be available to assistive technology through the native control state, and keyboard users must be able to change it without losing their place unexpectedly. When the list updates without a full navigation, announce the meaningful result politely and keep focus on the control or a predictable destination. Avoid announcing every product card individually; that would drown out the change the customer asked for.
Check the resulting list against its label rather than merely checking whether the dropdown opens. In each language, read the first several prices or dates aloud and verify the claimed direction. Include ties, discounted products, variants, unavailable items, and a filtered view. Use a keyboard and a screen reader to confirm that the control name, current option, and resulting count or update are understandable. A real customer may not know your internal ranking key; if a plausible shopper cannot explain why the first two cards appear in that order, revisit the rule or label. This is an editorial acceptance test as much as a software test.
Write an acceptance record for each option
For each sort, record the visible label, the data field, direction, tie-break rule, treatment of missing values, and what happens when products change. Compare a small manually checked sample against the production query, then repeat with enough records to span pages. Verify that English and Chinese labels express the same rule, the selected state survives navigation, and the URL policy does not create unwanted indexed duplicates. If “best selling” cannot be backed by a defined dataset, remove that option until it can. The release decision should be based on the truth of the order shown to shoppers, not on whether a sophisticated dropdown has been built.
A merchandising team may want to pin a campaign product at the top. Decide whether that pin applies only to the default order or also to explicit customer choices. If a shopper selects increasing price and an expensive promoted item remains first, the label is false unless the exception is clearly disclosed. Keep promotional placement visibly separate or restrict it to a named featured order. Record when the campaign starts and ends in the business system, and test that an expired pin disappears without leaving the list unstable. This makes the commercial choice visible while preserving the meaning of customer-controlled sorting.
Before you proceed
- Can a shopper explain the rule behind every visible sort option?
- Do the displayed prices and item order use the same value and a stable tie-break?
- Does the selected order survive navigation and work in both languages?
