We did not begin with a component inventory. We began with a product that had grown faster than its shared language.
The visible problem was inconsistency
TAP Mindset had eight card variations, six chips and four inputs. Most were close enough to look related and different enough to behave unpredictably. The obvious response was to consolidate the library.
But inconsistency was only the symptom. The consequential problem was maintenance: documenting one component took 45 to 60 minutes, knowledge lived in individual designers and every new feature made the system more expensive to understand.
Count usage before deciding what deserves to exist
I mapped the main flows and inspected more than 28,000 component instances. Usage exposed three different kinds of repetition:
- Load-bearing patterns. Components used across critical journeys whose behaviour needed to remain stable.
- Accidental variants. Small visual differences representing the same product concept.
- Local exceptions. Patterns created to solve one constraint that had never been evaluated as part of the wider system.
This changed the conversation. We were no longer debating which component looked cleaner. We could ask which concept the product needed, where its behaviour diverged and whether that divergence was intentional.
A smaller API creates clearer decisions
The audit reduced the public component API from 55 concepts to 38. That number mattered less than the reasoning behind it. Each surviving component needed a clear responsibility, a predictable set of states and an explanation of when not to use it.
A design system becomes useful when choosing the shared path is cheaper than creating an exception. Consolidation alone does not achieve that. The component must also be understandable in Figma, inspectable in Storybook and practical to implement.
Documentation had to become part of the system
Once code became a source of truth, manual synchronisation had an expiry date. I built custom tooling to read coded component structure into Figma and generate documentation from a maintained template.
The tools carried names, properties and structure. They did not decide whether a pattern should be one component or five, how properties should be grouped or which accessibility decisions were acceptable. Automation accelerated the repeatable work; product judgment stayed explicit.
What changed in my practice
I no longer begin a design-system project by asking what the library is missing. I ask what the product is already repeating, which decisions teams keep remaking and where implementation has become more expensive than it needs to be.
The goal is not perfect consistency. It is continuity: a system clear enough to survive another feature, another team and another tool.