Design systems at catalog scale: consistent pages without the rework

Large B2B catalogs almost never become inconsistent through a single bad decision. They grow one product at a time, often over years, through many hands: a product manager adding a new range, a marketing coordinator uploading supplier photos, a developer building a one-off page for a launch. Each addition is a reasonable choice. Together, they make the catalog feel like it was assembled from several different websites.

This article covers how to use a design system to keep a large catalog consistent by default - so that product 1,000 looks and works as well as product 10, without a designer touching every page.

Why catalog inconsistency is expensive

• Comparison becomes hard. When two similar products present specifications in different orders or formats, buyers cannot compare them - and comparison is how many B2B buyers decide.
• Trust erodes. Inconsistent pages look unmaintained. In Stanford's large study of how people judge websites, "design look" was the most frequently cited credibility factor.
• Every change costs more. Updating a layout, adding a field or fixing an accessibility issue means touching hundreds of one-off pages.
• Speed suffers. Without templates, each new product line becomes a small design project. Figma's research found designers completed a task 34% faster with a design system than without one.

Design a small number of templates, thoroughly

The practical approach is to decide on a small set of page types and design each one thoroughly - as a real template with defined components, content slots and states. On a B2B hospitality equipment catalog, the key templates covered home, business area, solutions, product listing, individual product and case study pages. Every product then inherits its template's consistency automatically.

Six to eight well-designed templates cover the vast majority of a real catalog's pages.

Define the content model, not just the layout

Templates only stay consistent if the content feeding them is consistent. For each product type, define:

• Required attributes - for commercial kitchen equipment, perhaps dimensions, power requirements, capacity, material, certifications and warranty.
• Optional attributes - shown only when present, never as empty labels.
• Units and formats - millimetres or centimetres, kW or W, one date format.
• Image standards - background, angles, minimum resolution, number of views.
• Naming conventions - how product names are structured so they sort and search predictably.

A content model is unglamorous work, and it is what makes filters, comparison views and search function properly. It also stops the most common drift: one team writing "600 mm W" while another writes "Width: 60cm".

Define component states once

Catalogs are full of states that, if designed ad hoc, fragment quickly. Define each one once and reuse it everywhere:

Each state should combine text, not colour alone, so it works for everyone and in print. Pair this with an accessible colour system - see WCAG contrast testing.

High-fidelity, not just wireframes

A wireframe tells a team the structure of a page. It does not tell them how spacing, colour, typography or component states should look in production - which is exactly where inconsistency creeps back in during implementation. High-fidelity templates, handed off with documented components, states and responsive behaviour, are what prevent drift once engineering starts building.

A useful handoff package for each template:

• Designs at desktop, tablet and mobile breakpoints.
• Every component state, including empty, loading and error.
• Content rules: character limits, image ratios, which attributes appear where.
• Accessibility notes: heading structure, focus order, alt-text guidance.
• Examples with real products, including awkward ones - long names, missing images, many variants.

Governance: how new products stay consistent

• Content entry guided by the model. CMS or PIM fields that match the template, with validation for required attributes and formats.
• A named owner for templates and the content model.
• A route for exceptions. When a new product type genuinely needs something different, extend the system rather than building a one-off page.
• Periodic audits. Sample products each quarter for missing attributes, off-standard images and broken states.

How it connects to IA and brand

Information architecture decides where products live and how buyers find them; brand identity decides how the company is perceived. Both depend on a design system to survive contact with a real, growing catalog. Without one, both degrade as new products are added by whoever is available, using whatever pattern seems closest. See information architecture for large B2B catalogs and brand identity for B2B trade companies.

Frequently asked questions