Setting up a Shopify clothing store: sizes, returns and photography

Clothing has the highest return rate in retail, and the overwhelming majority of returns are fit. Almost every decision in setting up an apparel store should be judged against whether it reduces that number — because a return costs you the shipping twice, the handling, and often the item.

Variants: colour and size

The standard structure is colour × size, which multiplies fast. A shirt in eight colours and seven sizes is fifty-six variants before you've added a second product.

Two approaches:

One product, colour and size as options. Simple, one page, one URL. Works well up to moderate ranges.

One product per colour, linked as a group. More products, but each colour gets its own URL, its own images, its own search result and its own metadata. Better for search and better for large ranges — and it sidesteps Shopify's variant ceiling.

For a serious apparel catalogue the second is usually right, with a colour switcher in the theme that links between them.

Size guides belong in structured data

The single highest-return technical decision in an apparel store.

A size guide pasted into the product description as an HTML table is unmaintainable, inconsistent across products, invisible to filtering, and breaks in a redesign. A size guide as a metaobject — referenced by every product it applies to — is edited once, renders identically everywhere, and survives.

Model it properly: a size guide record per fit type, with rows of measurements, referenced from the products that use it.

Then put the actual measurements on the product too: garment measurements, model height and the size they're wearing. "Model is 178cm and wears M" does more to prevent returns than any amount of copy.

Filtering is the collection page

Apparel shoppers filter by size and colour before anything else, and a filter that shows sold-out sizes is worse than no filter.

• Size and colour as proper options, so filtering works natively.
• In-stock filtering available and obvious. The most-used filter in apparel.
• Hide filter options with no matches in the current collection.
• Show counts.

Collection pages and filtering covers the mechanics. The tag vocabulary matters especially here — Navy, navy and Dark Blue produce three filter entries for one colour, and shoppers don't forgive it.

Photography standards

Apparel is sold on photography more than any other category, and consistency reads as quality:

• The same crop, background and lighting across the whole catalogue.
• On-body and flat-lay for each item.
• Detail shots of fabric, stitching and hardware.
• Every colourway photographed, not recoloured in software. Customers notice.
• Scale and fit visible.

This is a process standard as much as a design one — worth writing down as part of the brand identity.

Returns and exchanges

Since returns are inevitable, make them cheap to process and reassuring to read:

• State the policy in one line on the product page. Not behind a link.
• Offer exchanges, not just refunds. An exchange keeps the revenue; a refund doesn't.
• Track return reasons. Fit, colour, quality, changed mind. Six months of that data tells you which products need better photography or a corrected size chart — the single most useful report an apparel store can run.

Policy pages covers writing the policy so it converts rather than just complies.

Seasonal operations

Apparel catalogues turn over constantly, which makes automation worth setting up early:

• Automated collections on tags so "New in" and "Sale" maintain themselves.
• A fixed tag vocabulary given to whoever adds products.
• A plan for discontinued products. Don't delete them — they have search equity and inbound links. Mark them unavailable, or redirect to the successor.

That last point is where apparel stores quietly lose rankings: a seasonal catalogue deleted twice a year leaves hundreds of 404s behind.

Every apparel decision is a returns decision. Structured size guides, honest measurements and consistent photography pay for themselves faster than anything else in the build.