How many components do we need?

Fewer than you think, with far more state coverage than you have. Forty well-adopted components with seven documented states each are worth more than two hundred that teams route around.

Should the system live with design or engineering?

With a named owner who has allocated time, reporting somewhere that can arbitrate between product teams. The failure mode is shared ownership with no one accountable, which reliably becomes no ownership at all.

Expertise / Design Systems Consulting

Design systems don't fail on craft. They fail on funding and governance.

Year one is enthusiastic. Year two, the original team moves on, teams start forking components, and there are three systems, the official one, the real one, and the legacy one.

Start a conversationUI/UX Design in full

Who this page is for

For teams building a design system, or trying to rescue one that has stalled.

Related capability

UI design
UX design
Wireframing
User flows
Information architecture
Interaction design
Motion design

Infrastructure, not a project

A design system behaves like shared infrastructure: when it breaks, every team pays. Yet it is often budgeted as a project with an end date, then left without an owner the week after launch. We help you fund and staff it like the platform it is.

The practical consequence: before we build anything, we establish who owns it, how contributions are reviewed, what the versioning policy is, and what the recurring budget looks like. A system without those decays regardless of how good the components are.

Tokens before components

The most common sequencing error is building a component library on hardcoded values. Components then encode decisions that cannot be changed centrally, and the first brand or density change makes the system the obstacle it was meant to remove.

Colour, type and spacing decisions ship as code that engineering installs, so a change is released once and picked up everywhere, rather than redrawn screen by screen.

Rescuing a stalled system

Most rescues are not rebuilds. We audit adoption and drift, find where teams route around the system and why, and usually discover the same three causes: contribution is slower than forking, the components missed the states real features need, and nobody owns the decision to make an exception.

Fixing those is organisational work with a design deliverable attached. It is less satisfying than designing new components and it is what determines whether the system survives.

Signals

When this work is worth doing

If two or more of these are true, the conversation is probably overdue.

Teams are forking componentsGoing around the system is currently faster than going through it.
Adoption stalled after launchThe system was resourced as a project and the project ended.
A rebrand means a manual sweepThe system is built on hardcoded values rather than tokens.
Accessibility is audited per featureIt should be enforced once, at component level.

How we scope it

Three ways this usually runs

Durations are typical rather than fixed. We scope after the first conversation, not before.

System audit
2 to 3 weeks
Coverage, drift and adoption measured; governance and contribution model assessed.
You receive
- Coverage & drift analysis
- Governance assessment
- Recovery plan
Build a system
12 to 20 weeks
Tokens, core components with full state coverage, documentation and a contribution model.
You receive
- Token package
- Component library
- Documentation & governance
Systems coaching
Ongoing
Working alongside an in-house system team on standards, review and the funding argument.
You receive
- Review cadence
- Standards & checklists
- Adoption measurement

Design Systems Consulting

Questions we hear before we start

As delivery cost, not consistency. Without a system, every feature re-decides spacing, re-builds a table, re-specifies a date picker and re-discovers the missing empty state. That overhead recurs on every team, every sprint, and is invisible because it is distributed. Measure coverage and drift and the argument becomes countable.