Design & Product
Design Systems
Tokens, components and pattern libraries
A design system is the shared set of decisions that stops every new screen from being an argument. Colours, spacing, type, buttons, forms, tables, modals and states — defined once, built once, documented, and then used by everyone. It is infrastructure for design, and the return on it grows with every screen you add.
You need one when the symptoms show up: four slightly different blues in the same product, three button heights, a form that behaves differently on two pages, a developer rebuilding a dropdown that already exists twice, or a designer waiting for a decision that was already made last quarter and written down nowhere.
What's included
What we deliver
Design tokens
colour, typography, spacing, radius, shadow, motion and breakpoints as named values in a single source, consumed by both the design tool and the code so they cannot drift.
A component library
real, working, accessible components in your front-end framework, with every state defined: default, hover, focus, active, disabled, loading, error and empty.
Matching design-tool libraries
so what a designer assembles is what a developer already has available, and a mockup cannot invent a component that does not exist.
Pattern documentation
the compound patterns above component level: forms and validation, tables with filters and bulk actions, page layouts, navigation, notifications, and the rules for each.
Content and voice guidance
how buttons are labelled, how errors are phrased, how dates and numbers are formatted. Inconsistent wording makes a product feel unfinished as much as inconsistent spacing does.
Accessibility built into every component
keyboard behaviour, focus management, ARIA semantics and contrast checked once, in the component, instead of being everyone's individual responsibility forever.
Bidirectional support
every component correct in Arabic and English, using logical properties so direction is a setting rather than a second implementation.
Theming
light and dark, or multiple brands, where you need them.
Contribution and governance rules
who can add a component, how a change is reviewed, and how a version is released, because a system with no owner decays into a folder of old files.
How we build one
- Audit. An inventory of what already exists across your products: every colour actually in use, every button variant, every form field. This is usually the moment the problem becomes undeniable.
- Foundations. Tokens and typography agreed first, since everything else derives from them.
- Core components. The twenty or so that make up the majority of every interface, built and documented before anything exotic.
- Adoption on a real screen. The system proves itself by being used to rebuild one genuine part of your product, which is what surfaces the gaps a specification never would.
- Rollout. Migration planned page by page rather than as a big-bang rewrite, with the old and new coexisting during the transition.
- Handover. Documentation, contribution guidelines and training for the designers and developers who will own it.
The honest caveat
A design system is a product, not a document. It needs an owner, a review process and a small amount of ongoing attention, and if your organisation cannot provide that, a lighter-weight approach will serve you better than an elaborate system that ossifies in six months. For a single small product, a well-documented set of tokens and a dozen components is often the right size — and we will say so rather than sell you a programme you cannot sustain.
On working with Codigoo
They refused to do a big-bang launch, which annoyed me at the time. We traded through the entire migration without a single hour of downtime, so they were right.
Questions we are usually asked
- How is this different from a brand guideline?
A brand guideline describes how the brand should look; a design system contains the working code and the design-tool components that make it happen. One is a PDF people cite in meetings, the other is what actually ships. They complement each other, and we build the second to express the first.
- Can it work across our website, app and internal tools?
That is exactly the case where it pays off most. Tokens are shared at the foundation level, while components can differ per platform where the platform conventions require it. The consistency lives in the decisions, not in forcing an identical implementation everywhere.
- Which framework do you build it in?
Whichever your teams actually use — there is no point delivering a library your developers cannot consume. We can also deliver tokens in a framework-agnostic format so that a future change of front end does not restart the whole exercise.
- Will this slow our teams down?
For the first few weeks, slightly. After that it is the main reason a new screen takes days instead of weeks, because most of the decisions are already made and most of the parts already exist and are already accessible.
If you have more than one product, more than one team, or a growing pile of near-duplicate components, a consultation will tell you what size of system you actually need.
Talk to us about Design Systems
Thirty minutes with an engineer and a strategist who do this work — not a sales team. You will get an honest answer about whether it is the right thing to buy, and what it would realistically cost.