Start with the actual sellable item
A product page often describes a family of items while the warehouse fulfils a specific item. A shirt can have a colour and a size; a phone case may fit one device model and have a finish. Before designing buttons, list the combinations the business really sells, including any combinations that do not exist. Give each sellable combination a stable internal identifier, and decide which fields can change when the customer selects it: displayed price, stock message, image, delivery estimate and order line. The page should never present a colour and size as selectable if their combination cannot be ordered. The UI is a view of this model, not a source of truth for fulfilment.
Decide whether each option changes the identity of the item or merely expresses a preference. Engraving text, gift wrapping and a delivery note are usually configuration or service requests, while a size is commonly part of the stocked item. That distinction affects validation and customer support: a missing size can prevent picking the order, whereas an optional note can be blank. Document the rule in the catalogue data and reuse it at checkout and in staff tools. Otherwise the product page can say one thing, the cart another and the packing list a third. A clear item model also makes returns easier to investigate because staff can see what was selected at the time of purchase.
Use a default only when it is a defensible business choice and unmistakably visible. Preselecting the first size may turn an unconsidered choice into a mistaken order, especially on a small phone screen. A neutral prompt such as Select a size can make the required decision explicit. If a colour is selected by default to show photography, distinguish the preview from a completed purchase choice and verify the actual variant before add to cart. A shopper returning from the cart should see the same selected variant. Changing colour should preserve a compatible size, but it must clear or explain a size that is unavailable in the new colour. This state rule deserves a test of its own.
A product matrix also exposes a common edge case: an option can be temporarily unavailable without ceasing to exist. Keep a distinction between a combination the business never sells and a sellable combination currently out of stock. The former should not look like an orderable item; the latter might remain visible with an honest status and a way to choose another item. If the shop offers preorders, explain the actual dispatch condition and obtain a deliberate choice rather than silently treating the preorder as normal stock. This distinction is especially important when staff update inventory through a separate system, because a stale browser page can otherwise turn yesterday's availability into today's promise.
Make every choice understandable and operable
Use controls that match the choice. A compact native select can work well for a long list of sizes or device models. A short colour or size group can use radio buttons with visible text labels. W3C's forms guidance says related radio buttons should be grouped with a fieldset and legend, and that controls need associated labels. The group question might be Size, while each option's label is Small, Medium or Large. If the design uses colour swatches, a coloured circle alone is not a label: include a readable colour name and a visible selected state. A selected border or tick should remain distinguishable when colours look similar or a customer cannot perceive colour.
Tell the customer what the choice changes at the moment it changes. If the blue large shirt costs more than the blue medium shirt, update the displayed total and label the amount clearly before the add-to-cart action. If the image changes, its alternative text should describe the newly shown product rather than retain the previous colour. If a delivery promise depends on the variant, show the condition beside that variant, not as an unqualified statement above the page. Do not silently replace an unavailable option with the nearest available one. Explain that the selected combination is unavailable and offer a deliberate alternative, perhaps another size or a stock notification if the business actually supports it.
Instructions should be available before a customer makes an error. W3C recommends stating required fields, formats and relevant limits, then associating local instructions with the control. For a variant picker this may mean saying that size is required, that a fit guide opens in a new view, and that a made-to-order option has a different return condition if such a condition actually applies. Do not bury a material condition inside a tooltip that is hard to reach with a keyboard. Test the controls using only Tab, Shift-Tab, arrow keys and Enter or Space as appropriate to the native element. Then use a screen reader to confirm the group name, option name and selected state are announced coherently.
Follow one order through the whole journey
Consider a worked example: a shop sells a jacket in navy or cream, with three sizes, but cream in the largest size is not stocked. A customer opens navy, chooses the largest size, then switches to cream. The safe interaction removes the now invalid size, announces that the combination is unavailable and asks for a new size. The price and photo must correspond to the eventual cream variant. If the customer returns to navy, the shop can decide whether to restore the earlier size, but the choice must be visible and revalidated. This is a scenario for testing, not a claim about any real merchant's sales or measured conversion.
At add to cart, send the chosen variant identifier to the server and validate it against current catalogue rules and availability. The server should calculate the authoritative price and present any changed price or availability for the customer to accept; the browser's displayed text is insufficient evidence. Keep the selected variant name and attributes in the cart, checkout review, confirmation email and staff pick list. If stock changes while the customer is reading the page, explain the change at the action point and preserve the rest of the basket. A vague message such as Something went wrong makes it hard to decide whether to choose another option, wait or contact support.
A small shop can run a focused acceptance exercise without a large research programme. Write down all combinations, mark the unavailable ones and select one case for each state transition: no choice, valid choice, invalidated choice, changed price and changed availability. Ask someone unfamiliar with the catalogue to place a test order on phone and desktop, with keyboard and screen reader passes. Compare the visible selection with the actual variant identifier in the saved order and with the packing document. A pass means the same item is named consistently at each stage and a customer is never asked to pay for a combination they could not knowingly select.
For bilingual shops, repeat the acceptance test in English and Traditional Chinese. A translated option name must still map to the same internal variant identifier, and a price or stock change must be understandable in both languages. Do not encode the display label itself as the identifier: copy edits, punctuation and translation can change while the physical item remains the same. Also check that a product link shared with a selected option either reconstructs that option reliably or clearly returns the visitor to an unselected state. A hidden selection carried only in one browser tab can make a shared link misleading when a support agent opens it elsewhere.
Choose a sensible first release
Prioritise accuracy before visual polish. If the catalogue has only two or three variants, a simple, well labelled native control can be sufficient. If options interact, the development effort should go to a reliable variant matrix and state rules rather than a decorative swatch animation. Record the intended behaviour for unavailable combinations and price changes in plain language that customer service can use. Where merchandise has fit uncertainty, a size guide, measurements or a route to ask a question can help the shopper decide, but those aids must describe the actual product and should not pretend to guarantee fit.
After release, review customer questions and returns for signs of misunderstanding, but do not infer success from a single metric. A lower add-to-cart count might mean the picker now prevents accidental selections; a higher count might coexist with more wrong-size returns. Examine the whole chain: selection, cart, payment, fulfilment and support. If analytics is unavailable, staff can still log specific confusing combinations and reproduce them in a test environment. Change one behaviour at a time so the team can identify what improved or broke. The practical next action is to choose one high-variation product, document its variant matrix and test a complete order before applying the pattern across the catalogue.
Before you proceed
- Can a shopper identify the exact variant and its price before adding it to cart?
- Do keyboard and screen reader users hear group names, option names and changes?
- Does the saved order match the visible choice after an unavailable combination is selected?


