What is a design system?
A design system is a unified visual language of colour, typography, components, patterns and the rules that bind them. It lives in design files and in working code, so everything a team ships stays coherent as it grows. It scales across products and teams because each decision is made once, recorded and reused, never argued twice.
Why do teams need a design system?
Because products are built by many hands, and hands disagree. Without a shared system every feature is a fresh set of decisions (which blue, which button, which spacing), each a chance to diverge. A design system settles those questions once. We define, name and share colour, typography, components and patterns, so the product stays coherent no matter who is shipping this sprint. The design conversation then rises a level, from what should this look like to what should this do.
The second dividend is speed, and it compounds. Designers assemble flows from proven parts, engineers reuse built components, and review stops relitigating padding. The third dividend is onboarding, because a documented system is a curriculum. A new designer or engineer reads how the product speaks: the tokens, the components, the patterns and the reasons behind them. They contribute within days, because the system carries knowledge that otherwise lives in the heads of whoever was there first.
Signs you have outgrown ad-hoc design
- Three shades of the primary colour are in production and nobody chose any of them
- The same screen, built by two teams, arrives looking like two products
- Engineers rebuild buttons that already exist because nobody can find the last one
- Every redesign starts with an archaeology phase to establish what the current rules are
- New designers take weeks to learn conventions that are written down nowhere
- Design review spends its time on spacing and shades, never on the actual problem
What is the difference between a design system and a style guide?
A style guide is documentation. A design system is the working machinery that documentation describes. The guide tells you what the brand's colours are and how the logo may be used. The system gives you those colours as named tokens, the buttons as built components, and the patterns as reusable flows. It lives in the design tool and in code, versioned with the product it serves. One is a book you consult, the other a kit you build with.
They are complements, not rivals. Most organisations need the guide, meaning the brand's rules written where anyone can find them. Any team shipping software at pace needs the system too, because reading a rule and having the rule already built are different speeds. When we build a design system, its documentation is in effect a style guide. It has far less room to drift from the product, because both come from the same parts.
- Tokens
- The named values at the bottom of everything: colour, type scale, spacing, radius, elevation. Change a token and every surface that uses it follows.
- Components
- The built parts (buttons, fields, tables, cards), each designed once, coded once, and reused everywhere with their states and accessibility already handled.
- Patterns
- How components combine to do a job: forms, navigation, empty states, confirmations. Patterns are where a system stops being a parts bin and becomes a language.
- Governance
- Who decides, and how a change is proposed, reviewed and released. These are the quiet rules that keep the system one system as it grows.
Where we stand on Design Systems
- 01A design system is parts plus rules plus code, not a brand deck with a components page.
- 02Consistency, speed and onboarding are the three dividends, and all three compound.
- 03Teams skip governance, which is why a system fragments as it grows.
- 04A system that lives only in the design tool is half a system: parity with code is the point.
- 05Adoption is the real measure. A system nobody builds with never becomes machinery.
Work featuring Design Systems
What’s included in Design Systems?
- Design tokens
- The brand's decisions encoded as named, versioned values.
- Theming & multi-brand support
- One system carrying several brands or modes, with the token layer doing the switching.
- Component libraries
- Buttons through to data tables, built as one set with every state, every size and accessibility handled.
- Pattern documentation
- How a form behaves, how errors speak and what an empty state offers, written down.
- Governance & contribution models
- Ownership, proposal, review and release, sized to the team.
- Code–design parity
- The component in the design file and the component in production share names, tokens and behaviour. A change lands in both.
Final questions
How long does a design system take to build?
A useful first release arrives in weeks, not months. It holds the tokens, the core components the product uses most, and the patterns behind its main flows. From there the system grows alongside the product it serves. We scope that first phase around whatever your team is shipping next, so the system proves itself on real work immediately.Do you build the coded components too?
Yes. A design system that stops at the design tool leaves the hardest half undone. Our engineers build the component library in production code alongside the design files, with the same tokens, the same names and the same behaviour. That parity between file and production is what a team can depend on.Which tools do you build it in?
Figma and code. The design file and the production components carry the same names, the same tokens and the same behaviour, so a designer assembles from the parts an engineer will ship rather than from a drawing of them. Keeping the two in step is the work rather than a by-product of it, and it is what stops the file and the product drifting into two systems.How do you keep a design system adopted?
We make the system the easiest path. Components are quicker to use than to rebuild, and documentation answers questions in the moment. A contribution route lets teams improve the system, so nobody has to work around it. The test we design for is a new hire shipping their first on-system feature in their first week.