Sizes, colors, and customizations: how to organize variants customers can understand

A catalog with sizes, colors, and customizations almost always breaks at the same point: combinations multiply until no one knows which ones actually exist anymore. The customer chooses, gets to the end, and finds out that combination can't be made; or they order it, and you find out in production. The fix isn't a bigger catalog, but deciding in advance what counts as a variant and what doesn't.

The distinction sounds theoretical, but it decides everything: what code the product has, what the warehouse sees, whether the price changes, whether the piece can be resold in case of a return.

Three different things that look the same

The consequence is practical: a variant can be kept in stock, a customization can't. Treating an embroidery like it's a color means promising availability that doesn't exist; treating a size like an option means not knowing how many are left.

Allowed combinations are declared, not inferred

If a product has four sizes, three materials, and two finishes, the system calculates twenty-four combinations. Some don't exist: the finish doesn't apply to that material, the smallest size can't take the embroidery. If the exclusions aren't written down, the catalog offers them anyway, and sooner or later someone orders them.

• It's better to declare the exclusions than to list every valid combination by hand: exclusions are few and can be explained with a rule.
• Every exclusion has a reason, and the reason needs to be noted next to it: technical, commercial, or temporary. A year from now no one will remember it, and without a reason no one will dare remove it.
• Rules are written once and reused. If every product has its own hand-written exceptions, maintenance becomes impossible as soon as the catalog grows.

When exclusions become more numerous than allowed combinations, the model is wrong: you're almost always keeping two different products together, and it's better to split them.

Codes, price, and availability: where each thing gets decided

• A code is assigned to everything that needs to be counted separately. If you need to know how many size M are left, size M gets a code.
• The price can start from a base with surcharges, or be fixed for each combination. The first way is easier for buyers to read, the second is more precise; mixing the two creates discrepancies between what the product page shows and what the cart calculates.
• The availability of a combination depends on all its components. A customized product is never "available": it's "can be produced within a certain time," which is different information and needs to be worded differently.

Example: a sweatshirt with size, material, and embroidery

The classic case of customized corporate apparel, with three attributes and two exclusions.

• Sizes from XS to XXL: variants, each with its own code and stock level.
• Two materials, light and heavy: also variants, because in the warehouse they're two different products.
• Embroidery with logo or without: customization. It changes the price, extends the lead time, and makes the piece non-resellable.
• Declared exclusions: the light material doesn't exist in the two extreme sizes; the embroidery doesn't apply to the light material.

With these rules, whoever chooses the light material no longer sees embroidery among the options, and whoever has already requested embroidery finds the light material not selectable, with the explanation next to it. The difference between removing a choice and explaining why it's not there is the whole customer experience: in the first case, they think the site is broken.

What the person choosing needs to see

1. The image that changes with the choice, at least for the attributes that are visible. A color without a matching photo forces the customer to imagine, and someone who has to imagine puts off the purchase.
2. The lead time, when it changes. If embroidery adds days, it needs to be stated at the moment of choice, not on the shipping page.
3. The summary before purchase: all the choices in one place, with the price broken down. This is the moment the customer notices a mistake, if there is one.
4. The ability to go back on a choice without starting over.

Edge cases and second thoughts

Before publishing, it's worth testing the situations that happen every day in real life. These are the ones where poorly built models show up immediately.

• Changing size after entering the customization: does the entered data stay valid, or does it need to be requested again?
• Choosing a combination that runs out while it's in the cart.
• Increasing the quantity of a customized product: two pieces with the same embroidery, or two different embroideries?
• Requesting a return on a customized piece: if it's not resellable, the rule needs to be written and shown before purchase, not communicated afterward.

What this guide doesn't cover

Here the product itself is modeled: attributes, allowed combinations, codes, price, and availability. When the choice stops being a selection and becomes a calculation — free-form measurements, components that depend on other components, a price built from rules — you're in the territory of quote-based configuration, which is designed a different way. Preparing data and images to bring a catalog into the site is also its own piece of work.