Product comparison tables: which details help customers choose?

Choose products that belong to the same decision

Do not force a desk and a conference table into one comparison just because they share a catalogue category. Define the task a visitor is choosing for: perhaps computer work in a small room. That task determines which rows appear first. Width, usable surface and cable management may matter before the full colour range in this particular scenario.

Make selection and removal controls clear. Two or three products provide a manageable starting point for a prototype, not a universal maximum. Evaluate the actual catalogue and readable screen space together. If people cannot identify what they have selected, adding more columns will not solve the underlying problem.

Prepare the attribute dictionary before filling the cells

Create a small data dictionary so the same feature does not appear under conflicting names. Width should refer to the same dimension for every product; included should describe the same delivery scope. Convert mixed units and have a product owner verify the conversion. Never copy illustrative values into a real catalogue.

Define missing values deliberately. Not available, not applicable and awaiting confirmation mean different things. A dash for an unverified feature may imply that the product lacks it. Keep the source and review date in the content team’s records so a later editor can check where each value came from.

Explain the trade-off without inventing a winner

Desk B may be wider, but that does not make it better for every customer. Someone with a small room could prefer Desk A. Tie each difference to a use condition instead of automatically awarding a best-choice badge. If prices appear, compare the same currency, tax basis and selected configuration.

A differences-only view can be useful, provided its active state is obvious and visitors can restore all attributes. When no differences remain, avoid suggesting that the products are identical in every respect. Your table may cover only a limited set of features, and that scope should remain understandable.

Inspect a two-product example

Keep the relationship intact on mobile

Shrinking every column to fit a phone can make the information unreadable. Reducing the selection or allowing controlled horizontal movement inside the table are two possible approaches. If the table scrolls, product identity and attribute context must remain understandable. The entire page should not overflow sideways. Check enlarged text and long product names as well.

W3C’s table guidance explains how HTML associates header cells with data cells. In the example, column headers identify products and row headers identify attributes. Visual dividing lines alone cannot communicate those relationships to assistive technologies.

Listen to the reason behind a test choice

Ask someone to choose a desk for a small room and explain why. If they misunderstand whether a cable tray is included, revise the labels as well as the typography. Assign responsibility for checking comparisons whenever catalogue data changes; separate copies of the same information can drift apart.

This differs from writing a single product page: the goal is to explain relationships between alternatives. Our Gerhman project page offers context for industrial presentation; the example table is not a claim that this feature exists in that project. Include data mapping and mobile review in the website design scope.