Model the catalogue before you design the interface

On a manufacturer site, the catalogue is not content. It is the data model, and every page is a view onto it. Getting it wrong is not a design problem you can fix later with a redesign — it is a migration.

What a product actually is

The first question is what constitutes a single product. Is a thermal break profile one product with 27 dimensional variants, or 27 products? The answer determines the URL structure, what a search result looks like, what a filter operates on, and how a buyer requests a sample. It is a commercial decision disguised as a technical one, and it should be made by the people who sell the thing.

Organise around the buyer’s selection path

Internal product codes are how the company thinks. A specifying engineer thinks in application, profile system and dimension. Those are rarely the same tree. When the site follows the internal codes, buyers cannot navigate it, and the company concludes that buyers do not want to navigate it.

Attributes are the filter

Filtering is only as good as the attribute data behind it. If dimensions are recorded inconsistently — sometimes 14.8, sometimes 14,8, sometimes “about 15” — no interface can filter on them. Most catalogue projects spend more effort normalising existing product data than building the pages, and that effort is where the value is.

The order of work

• Export whatever product data already exists, in whatever state
• Decide what a product is, and what is a variant of one
• Normalise the attributes that will become filters
• Model the taxonomy the way a buyer selects, not the way stock is coded
• Only then design the pages

A catalogue built in this order can be redesigned cheaply. One built in the reverse order has to be rebuilt.