When a component library isn’t enough

Look past the visual inconsistency

Teams usually ask for a design system when their screens start to look different from each other. That inconsistency is real, but the more costly problem often sits underneath. The same task behaves differently in two parts of the product. Teams use different words for the same thing. Errors are handled one way here and another way there.

So before planning a library, collect examples of the problems that keep coming back. Note what each one costs users and what it costs the delivery team. Two button styles are quick to fix. Using “Save”, “Submit” and “Complete” to mean different things needs an agreement about the workflow, not just a component.

A library is an asset; a system is a set of decisions

A component library gives you reusable building blocks. A design system also explains the decisions around them: when to use each one, how it behaves, which states it needs and how pieces combine into patterns.

Big public systems like IBM’s Carbon treat usage and accessibility guidance as part of every contribution. You don’t need Carbon’s scale to borrow that idea. Treat the guidance and the upkeep as part of the system, not an appendix someone will write later.

Start with one repeated task

Pick a pattern that appears in several important journeys: entering information, reviewing a record, confirming an action. Document what’s common and which differences genuinely matter. That gives you a concrete test of whether the shared pattern helps.

Say several teams have built their own confirmation dialogs. Standardising the corner radius won’t help users understand what they’re confirming. Agree the message structure, the action wording, the destructive variant and how people undo a mistake first. Then express those decisions in reusable design and code.

On a major UK telecoms platform, this happened at scale: a page audit found the recurring structures across a big digital estate, and those became reusable page families with clear rules for content and components. The rules mattered as much as the templates.

Decide who owns it

Someone has to decide how changes get in, how they’re reviewed and how other teams hear about them. Without that, a library slowly fills up with local exceptions while still looking centralised.

A light contribution process can ask for the problem, examples of where it’s needed, the proposed behaviour, accessibility considerations and what it means for the code. Keep experiments separate from stable patterns, so teams can try ideas without everyone else having to adopt them immediately.

Keep design and code together

A Figma component and a coded component can drift apart even when they share a name. Review states, content rules, responsive behaviour and interaction together, and bring engineering into decisions about how components combine and extend.

Don’t measure success by the number of components. Ask whether teams find and use the right pattern, whether the repeated problems go down and whether changes get easier. A small system people use beats a big one they ignore.

Choose the smallest next step

Before committing to a big programme, answer:

• Which repeated user problem will you tackle first?
• Which teams will use the shared pattern?
• Who owns the design, the code and the documentation?
• How will changes and exceptions be reviewed?
• How will you know it’s helping?

Design Leadership can help your team look at consistency and decision-making within an agreed scope. If the real problem is one difficult end-to-end journey, Complex Workflow Design might need to settle the behaviour before you standardise the components.