Design system design and audit

The problem this solves

The complaint arrives fully formed: the system is too rigid, or too loose, or nobody uses it. Underneath, it is almost always one of four things, and only one of them is a component problem.

The product may have outgrown the set, so the system supports simple tables and the product now needs bulk actions and pinned columns. The right pattern may exist and nobody trusts it. Nobody may know how change happens, so every extension becomes a negotiation. Or — most often — the team never agreed the product rule the component is supposed to encode, and the library is getting blamed for an unmade decision.

Building more components fixes exactly one of those. An audit tells you which one you have before anyone opens Figma.

What you get

• A component and coverage audit

  What exists, what is duplicated, what the product needs and does not have, and what can be retired. Counted rather than estimated.

• A token layer that names decisions

  Primitive, semantic and component layers, where the middle one says text-muted rather than grey-700. That layer is the difference between a system and a palette with extra steps.

• A governance model your team will actually follow

  Who can extend a component, who reviews it, when an exception becomes a pattern, and how a change reaches the products using it. Written as a process, not a policy.

• Documentation that lives beside the code

  When to use each pattern and when not to. Adoption debt is almost always a discoverability problem wearing a compliance costume.

How it runs

1. 1

   Inventory what is really there

   Both trees: the design library and the code. The gap between them is usually where the frustration lives.

2. 2

   Interview the people who work around it

   The teams filing exceptions, not the team maintaining the system. They know which rule costs the most.

3. 3

   Name the debt

   Decision, coverage, adoption or governance. This is the finding, and it changes what the rest of the work is.

4. 4

   Fix the layer that is broken

   Sometimes tokens, sometimes an exception process, sometimes six missing components. Rarely all three at once.

5. 5

   Hand over the process, not just the file

   A system nobody can change without asking you is a system with one bus factor and a queue.

The longer version of this, with what happens in each week, is on the process page.

Where this has been done

• HelloUI

  200+ components, 5+ product lines, 40% faster UI build

  Inconsistent components across product lines were slowing every release. I built the reusable component, token and documentation system the teams could share, which is the part that made the speed change stick.

• Starlink Qatar

  Eight HR services as one mobile experience

  Eight separate services had to behave like one product. Taken from stakeholder workshops through UX and interactive prototypes to formal engineering handover.

Typical engagement

An audit on its own is typically two to three weeks and ends in a document you can act on without me. The build that follows depends entirely on what the audit finds: a governance fix can be a fortnight, a token layer rebuild across several products is a quarter.

I would rather do the audit first and quote the rest honestly than price a rebuild before anyone knows which of the four debts you have.

Who this is not for

• You want a component library built from scratch with no product using it yet. Systems designed before their first consumer encode guesses.
• The real problem is that two product teams disagree about the product, and you are hoping a system will settle it. It will not, and it will get blamed.
• Nobody will change how decisions are made. Governance is the deliverable that actually holds, and it needs someone able to say yes.
• You need a library audited but not the code it ships as. Half the truth lives in the implementation.

How I think about this

• Your design system isn't slow. Your product decisions are. — the four kinds of debt this audit is built to tell apart
• Name the decision, not the colour — why the middle token layer is the whole system
• A scalable B2B website with a design system — the same layers applied to a marketing site an AI assistant has to extend
• Feedback needs a subject — how the review conversation runs once a system exists to review against

Frequently asked questions

What does a design system audit actually check?

Coverage against what the product needs, duplication, token structure, how far the design library and the production code have drifted apart, and how change gets made. The last one is usually the finding: most systems that feel slow have no agreed route from a product team's need to a system change.

How long does a design system audit take?

Two to three weeks for most products, and it ends in a document you can act on with or without me. Longer if there are several product lines with separate front-end stacks, because the drift between design and code has to be checked per stack rather than once.

Do we need a full-time design system team?

Almost certainly not, and reaching for one is often what turns a governance problem into a headcount problem. What you need is a named owner, a review path and a rule about when an exception becomes a pattern. That is a process, and a small team can run it.

Can you work with our existing library rather than replacing it?

That is usually the better answer. A replacement throws away the parts that work and restarts adoption from zero. Most audits end with a token layer, a governance model and a handful of missing components rather than a rebuild.

What timezone do you work in?

Karachi, UTC+5. That overlaps most of the European working day and the US East Coast morning. Workshops get scheduled at your end of the day rather than mine.

What do you need from us to start?

Access to the design library and the front-end repo, and thirty minutes each with two or three product designers or engineers who work around the system rather than on it. Their workarounds are the audit's most useful input.