Enterprise Design System
One system powering 10+ products and a 15-person design team.
Ten-plus products pulling in ten-plus directions
Customer apps, enterprise tools, internal platforms — each had drifted into its own patterns. The cost showed up as slow delivery, inconsistent experience, and a design team spending its time re-solving solved problems.
The hard part was never the components
Anyone can build a button library. The real problem is adoption: getting independent teams, in a regulated and fast-moving organisation, to actually build on a shared system instead of around it.
Treat the system as a contract, and the rollout as the product
- Tokens and components as a shared contract — one language for colour, type, spacing, and behaviour.
- Governance and contribution — a way for teams to extend the system without forking it.
- Adoption as a rollout, not a launch — measured, supported, team by team.
- Tied to delivery speed — the system earned its keep on velocity, not aesthetics.
The tension
Standardisation makes everything consistent — and can strip the autonomy teams need for their domain.
The call
Opinionated defaults for the 90%, deliberate escape hatches where a product genuinely needs them.
One system, measurably faster
A design system is an adoption problem, not a component problem. It proves judgment, not just craft.
The component gallery is the easy 10%. The differentiator is regulated context, multi-team adoption, and a system that teams choose because it makes them faster.
Next: Quikr Marketplace Redesign