Every product accumulates inconsistency. It starts small — a second shade of blue because the first one didn't work on that background, a button with slightly different padding because it sat in a tighter space. Nobody makes a bad decision. Eighteen months later there are fourteen button variants, four grey ramps, and three different date pickers, and nobody can say which one is correct.
A design system is the thing that prevents this. Not by policing decisions, but by making the correct decision the easiest one to make.
What is a design system?
A design system is a documented set of reusable components, patterns, and rules that define how a product looks and behaves. It sits between brand guidelines and the codebase, and it exists so that the same problem doesn't get solved differently every time it appears.
At minimum it contains:
- Design tokens — the foundational values: colour, typography, spacing, radius, elevation, motion.
- Components — buttons, inputs, cards, modals, navigation, defined with all their states and variants.
- Patterns — how components combine to solve recurring problems: forms, empty states, data tables, onboarding sequences.
- Rules — when to use which component, and equally, when not to.
The distinction from a UI kit matters. A UI kit is a collection of pieces. A design system includes the reasoning: why this component exists, when it applies, what it does in every state, and how it behaves when things go wrong.
Why design systems pay for themselves
Design gets faster, and the acceleration compounds. The first screen built from a system is no quicker. The fiftieth is dramatically quicker, because it's assembly rather than invention.
Development stops rebuilding the same things. A button implemented once and reused is cheaper than a button implemented eleven times with slight variations — and vastly cheaper to change afterwards.
Consistency stops requiring vigilance. Without a system, consistency depends on everyone remembering. With one, it's the default, which is the only version that survives team turnover.
Changes become cheap. Updating a component updates every instance. Without a system, a change to how buttons look is a search-and-replace across the entire product, and the ones you miss stay wrong for years.
Onboarding accelerates. New designers and developers have a documented answer to "how do we do this here," instead of reverse-engineering it from inconsistent examples.
Accessibility gets solved once. Contrast, focus states, keyboard behaviour, and semantic structure built correctly into a component are correct everywhere it's used. Handled per-screen, they're correct approximately nowhere.
Two levels, and choosing between them
This is where most design system projects go wrong. Teams build something far more elaborate than their product needs, spend months on it, and end up with a beautiful system that slowed everything down. Or they build something too thin to hold, and the drift starts again within a quarter.
We work at both ends deliberately, and matching the level to the situation is part of the job.
Rapid initial design systems
A foundational system built in days rather than months. Tokens, core components, essential states, and enough documentation to be usable — covering the 80% of interface needs that recur constantly.
This is the right choice when:
- You're building an MVP or early-stage product where scope will change
- You need consistency now and can't pause delivery for a large upfront investment
- The product's eventual shape is still uncertain, making elaborate structure premature
- A small team needs shared foundations more than exhaustive coverage
A rapid system is not a compromised system. It's a correctly-scoped one. Built properly, it extends cleanly as the product grows, rather than needing replacement.
Advanced, fully-fledged design systems
The complete build: exhaustive component libraries, full variant and state coverage, multi-brand or multi-theme support, comprehensive documentation, contribution and governance models, and tight coupling to the front-end implementation.
This is the right choice when:
- Multiple teams work on the same product and need a shared source of truth
- The product spans several platforms or brands
- The codebase already has a component library the design side needs to mirror
- The product will be maintained and extended for years, where the investment compounds
- Governance genuinely matters — who can add components, how changes get approved, how versions are managed
The investment is significant and it repays over time. On a product with an eighteen-month horizon it usually doesn't. On a platform with a five-year one it almost always does.
The honest guidance: most teams asking for an advanced system need a rapid one first. Starting foundational and expanding as real needs emerge produces a better system than designing for hypothetical requirements — because the components you discover you need are different from the ones you predicted.
Working in Figma
Figma is where these systems live, and using it properly is a substantial part of the value.
Variables and modes handle tokens natively — colour, spacing, and typography defined once, with light and dark modes, density options, or brand variants switching without duplicated files.
Component properties and variants collapse what used to be dozens of separate components into one configurable element, with states and options exposed as controls rather than buried in a layer tree.
Auto layout makes components genuinely responsive, so they behave correctly when content is longer than expected instead of breaking in ways that only surface in production.
Libraries and versioning let updates propagate to every consuming file, with change tracking so teams can adopt updates deliberately rather than being surprised by them.
Dev Mode and code connect narrow the gap between design and implementation, exposing values, specs, and component mapping directly to developers.
Systems built without these capabilities technically work and are considerably more expensive to maintain. A component library that needs manual updating across files is a system that will be out of date within months.
Where AI fits
We increasingly use AI in design system work, in the places where it genuinely helps rather than as a headline.
Generating component variants and states. Producing the full matrix of states across a component set is repetitive, error-prone work that AI handles quickly. Reviewing the output is still a human job.
Documentation drafting. Usage guidelines, do-and-don't examples, and prop descriptions are faster to edit than to write from scratch.
Auditing for inconsistency. Finding every off-token colour, orphaned component, and detached instance across a large file set is exactly the kind of exhaustive pattern-matching that machines do better than people.
Migration and refactoring. Restructuring an existing library into a token-based system involves a large amount of mechanical transformation.
Accelerating the initial build. For rapid systems especially, AI meaningfully shortens the path from nothing to a working foundation.
What it doesn't do is decide what the system should contain. Which components a product actually needs, how they should behave, where the edges are, what to leave out — those are judgment calls informed by how people use the product. AI makes the execution faster; it doesn't make the decisions.
Building from existing solutions
Building everything from scratch is often the wrong answer.
Mature open-source and commercial systems — Material Design, Radix, shadcn/ui, Ant Design, Carbon, Fluent, and others — represent an enormous amount of solved problems: accessibility handled, edge cases covered, states thought through, patterns tested at scale.
Starting from a quality foundation and adapting it to your brand and needs is frequently faster, cheaper, and more robust than starting empty. You inherit the accessibility work and the edge case handling, and you spend your budget on what actually differentiates your product.
When adapting an existing system makes sense:
- Your product uses conventional patterns and doesn't need a distinctive interaction model
- Your development team already uses a component framework
- Speed matters more than complete visual distinctiveness
- Accessibility compliance is required and you'd rather inherit it than rebuild it
When building custom makes more sense:
- Your product's interaction model genuinely differs from conventional patterns
- Brand distinctiveness is a core part of the product's value
- You have unusual requirements that off-the-shelf systems handle badly
- You're operating at a scale where the customisation cost is marginal
Most projects land somewhere between: an existing foundation, substantially adapted. We'll tell you which end of that range your situation actually calls for, including when the answer is "you don't need us to build this from scratch."
What a usable design system contains
Tokens, not values. Colour, spacing, and typography as named references rather than hex codes and pixel numbers. This is the difference between a system that can change and one that can only be replaced.
Components with complete state coverage. Default, hover, focus, active, disabled, loading, error. A component missing states is a decision deferred to whoever implements it under deadline pressure.
Documented usage rules. When to use each component and when not to. The negative guidance prevents more inconsistency than the positive guidance.
Patterns, not just parts. How components combine for recurring problems — form layouts, empty states, error handling, data display.
Accessibility built in. Contrast ratios, focus indicators, touch target sizes, and semantic structure correct at the component level.
Content guidelines. Button labels, error message tone, empty state copy. Interface text drifts as fast as visual design and is rarely governed.
A contribution model — for larger systems. How new components get proposed, reviewed, and added. Without it, a system ossifies and teams start working around it.
Common mistakes
Building for a hypothetical product. Components created because a system "should have them," not because anything uses them. Unused components are maintenance cost with no return.
Over-engineering early. Elaborate governance and exhaustive variants before the product has found its shape. The system becomes an obstacle rather than an accelerator.
Designing in isolation from code. A design system that doesn't correspond to the front-end implementation creates translation work on every handoff and diverges steadily.
No maintenance ownership. Systems decay. Without someone responsible, drift resumes within months and the investment is lost.
Treating it as a one-time project. A design system is infrastructure. It needs updating as the product evolves, and the update cost should be planned rather than discovered.
Documentation nobody reads. A hundred-page document is a way of transferring responsibility. Documentation should live where the work happens and answer questions at the moment they arise.
How we approach design systems
We scope to your actual situation, not to what's impressive. Rapid foundational system or comprehensive platform library — the recommendation follows your product's stage, team size, and horizon. Building more than you need is a common and expensive failure, and we'd rather tell you that upfront.
We build on quality foundations where it makes sense. If a mature existing system fits your needs, adapting it is faster and more robust than starting empty. We're not attached to building from scratch.
We use Figma to its full extent. Variables and modes, component properties, auto layout, library versioning, Dev Mode. Systems built without these are more expensive to maintain and go stale faster.
We use AI where it accelerates execution. Variant generation, documentation drafting, consistency auditing, and migration work — the repetitive parts. Structural decisions stay human, because they depend on understanding how your product is actually used.
Accessibility is built into components. Solved once at the component level rather than repeatedly at the screen level, which is the only approach that actually holds.
The approach is grounded in certification from the Nielsen Norman Group — the institution that shaped modern UX practice — in information architecture, journey mapping, usability testing, UX leadership, and analytics, and thirteen years of work across agencies, startups, and corporate teams in insurtech, fintech, health, education, enterprise, and transportation.
Every engagement is run personally. No account layer between you and the person doing the work.
Frequently asked questions
How long does a design system take to build?
A rapid foundational system — tokens, core components, essential documentation — typically takes one to three weeks. A comprehensive system with full component coverage, multi-theme support, and governance runs from six weeks to several months depending on scope and how many teams need to be accommodated.
Do we need a design system?
If you have more than a handful of screens, more than one person designing or building, or a product expected to grow, almost certainly yes — though possibly a smaller one than you're imagining. A single-purpose product with a fixed scope and one designer probably doesn't.
What's the difference between a design system and a UI kit?
A UI kit is a collection of visual components. A design system adds the reasoning: usage rules, state coverage, patterns, accessibility requirements, and governance. The kit tells you what things look like; the system tells you when and how to use them.
Can you work with our existing design system?
Yes. Auditing, extending, and refactoring existing systems is common work — often more valuable than building new, since an existing system already carries organisational knowledge worth preserving.
Should we build custom or adapt something existing?
Depends on how distinctive your product's interaction model genuinely is. Conventional patterns are usually better served by adapting a mature system — you inherit solved accessibility and edge cases. Genuinely novel interaction models justify custom work. Most projects sit in between.
How does AI change design system work?
It substantially accelerates the repetitive parts: generating variant matrices, drafting documentation, auditing for inconsistency, and migrating existing libraries. It doesn't decide what the system should contain — that requires understanding how your product is actually used, which remains a judgment call.
Who maintains it afterwards?
Ideally your team, with the system built and documented to make that straightforward. Where in-house capacity doesn't exist, ongoing maintenance can be part of the engagement. What doesn't work is nobody owning it — that's how systems decay.
Where to start
A quick diagnostic: how many distinct button styles exist in your product right now? If nobody knows the answer, or the answer is more than three, the drift has already started.
The cost of fixing it only goes up.