How should a Hong Kong shop help customers compare products without hiding the differences that decide a purchase?

Start with the buying decision

A useful comparison begins with a question a customer can actually answer, such as which compact appliance fits a narrow counter and can be cleaned after daily use. A row of every database field is usually less useful than a short set of attributes that change the decision. Ask recent customer service questions, inspect product returns for recurring misunderstandings, and talk to staff who explain models in person. Those inputs identify candidate fields; they do not prove that a feature is important to every buyer. Separate requirements from preferences. A buyer may need a maximum external width, while colour is negotiable. Keep a route back to the full product page for photographs, warranty wording, delivery eligibility and documents. The comparison should help someone narrow a choice, not quietly replace the source detail needed to commit to an order.

Define the comparison set before designing the interface. Compare products that a shopper could reasonably choose for the same task, and label a different capacity or bundle plainly. A model sold with an accessory is not directly price-equivalent to a bare unit. Show current selling price with its currency and state whether a listed figure is a one-time price, a range, or subject to a selected variant. Avoid a badge such as 'best value' unless the shop publishes the criteria and can keep them true. If one specification is missing, write 'not confirmed' and link to a source or request for clarification; a dash can look like zero or not applicable. Where a manufacturer uses a different measuring method, do not line up the numbers as if they share a basis. Explain the method, or omit that row until the values are comparable.

Choose and govern the fields

For each field, record a name, unit, definition, source, last checked date and owner. 'Size' is ambiguous; 'external width in centimetres, excluding the power cord' is testable. Make the unit visible in the row label and preserve the precision supplied by the source. A capacity in litres should not be converted to an apparently exact number of portions without a documented assumption. Treat promotional text differently from product specifications: a claim such as 'quiet' is not a comparable numeric noise result. If customer questions reveal that installation clearance matters more than body width, add a separate clearance field once it has a reliable source. The comparison content then becomes a maintained dataset with a publishing rule, not a one-off visual design file that quietly ages after product updates.

Set a rule for changes to price, availability and versions. The page should draw these from the same governed source as the product page where practical, but shared storage alone does not guarantee consistency: a cached comparison may still lag behind a live detail page. Decide how quickly a change propagates, what happens when a product is discontinued, and whether an older comparison URL should remain available with a clear notice. If a selected colour changes the dimensions or included accessories, the comparison must either update those fields with the variant or explicitly say that it compares base models only. Never let an unavailable variant appear as the in-stock representative of the whole model. Make a small change log for material corrections so support staff can explain why a buyer saw different data yesterday.

Make the differences readable

A side-by-side table works when each row is a single attribute and each product has a clear column heading. W3C's table guidance explains that row and column headers need structural associations, with a caption identifying the table. This matters when a screen reader encounters one cell at a time. Do not encode the only verdict in a green tick or a red cross; state 'included', 'not included', or the actual condition in text. Keep the full product name or a short unambiguous model identifier available in the column header. On a narrow screen, a horizontally scrollable table can work only if the reader can perceive that more columns exist and reach them with a keyboard. An alternative is a pairwise card view that repeats each attribute label next to its value. Check both presentations for the same facts.

Keep the mechanics modest. Let the shopper remove one candidate and add another without losing the remaining selection. Provide a visible limit if only a few models fit on screen, and explain why the limit exists. Keep selected products in the URL only if the identifiers reveal no private customer data and the resulting link can reliably reconstruct the view. Do not force a sign-in merely to compare public products. A 'highlight differences' control should preserve all rows and merely change emphasis; otherwise people may miss an apparently identical field whose footnotes differ. W3C also advises splitting complex tables when relationships become hard to follow. If the comparison needs many grouped headers and exceptions, first ask whether separate small tables by topic would answer the question more clearly.

Work through a buyer scenario

Imagine a small shop comparing three countertop appliances for a customer whose shelf is limited, who needs a removable washable container, and who can collect in person. The team first confirms external width and whether the container can be removed from the manufacturer's current documentation. It labels one missing width as unconfirmed rather than guessing from a photograph. The page shows each model's current listed price separately from delivery cost, because collection may change the total. One bundle includes an extra container, so the label and price note make that distinction visible. The customer can eliminate a model that fails the width requirement, then open the remaining product pages to inspect the cleaning instructions and exact collection terms. The comparison has supported a decision without pretending that one model is universally superior.

The acceptance test is a buying task, not a screenshot review. Ask one participant to find which eligible model fits a stated width, and another to explain why a cheaper bare unit may cost more once the needed accessory is added. Repeat with keyboard navigation, a screen reader, mobile zoom and both site languages if the shop publishes both. Inspect the result after a price edit, a variant switch and a discontinued item. Record where a person had to leave the comparison because a fact was unclear; that is a content repair ticket, not proof that the interface failed statistically. Release when the compared values, links and caveats are accurate for the current catalogue. Recheck whenever the products or terms change, because a polished table with stale facts is still a poor buying aid.

Before publishing a comparison, decide who is allowed to change a field and what evidence is acceptable. A manufacturer's current specification sheet may support a dimension; a supplier email may need confirmation if it conflicts with the packaged item. Record the source beside the internal value, not necessarily in the public table. When two sources disagree, hold the disputed attribute and explain that it is being checked. Staff should never fill a gap with a number copied from a competitor listing. Set a review trigger when a manufacturer revises a model, a bundle changes, a price rule changes, or a customer reports a mismatch. This makes the table repairable without forcing a full editorial redesign each time.

Be precise about what the test can establish. A short usability session can reveal that people misunderstand 'capacity' or cannot find the warranty detail; it cannot establish a market-wide conversion lift. Keep an issue list with the participant's task, where they hesitated, the field involved and the correction made. Then repeat the task with a different product pair so the solution is not tailored to one example. If the design adds a recommendation badge, test whether a person understands its rule and can still see the underlying evidence. A comparison succeeds when a customer can explain why one choice fits their own constraints and can trace each consequential claim to current product information.