How To Build A Design System
How To Build A Design System: practical guidance, examples and decision criteria from ANODA. Learn how the topic applies to your product and team.
- For product families
- With repeated interface patterns
- 6–12 weeks
- For an agreed scope
- Foundations and components
- With pattern and usage guidance
- An adoption direction
- One product area at a time
In short
One shared way for your teams to design and build interfaces.
What's included
- A prioritised inventory
- Foundations and components
- Usage guidance
- An adoption direction
Helps you decide
- What the system holds first
- Who owns it
- How teams adopt it
Where it stops
Improves how design work moves through the team.
Design Systems
Gives the product one set of foundations and components.
Not included
- A coded component library, unless scoped
- A system that maintains itself
A system that helps the next feature fit.
We define the first useful scope with your team and document how it should be applied. A design library and a production component library are separate deliverables; the engagement makes their relationship explicit.
- Status and Submitted headers swapped
- Reject appears only in expanded rows
A prioritised system inventory
What exists, what should be consolidated and what needs a new pattern.
- Status and Submitted headers swapped
- Reject appears only in expanded rows
Foundations and components
A design library with the agreed rules, variants and states.
- No bulk approve or reject
- Pay Cycle column repeats one value
Pattern and usage guidance
Examples and documentation that keep decisions consistent.
- Notes squeezed into a one-line field Move note editing to a side drawer with a multi-line field, Save and Cancel.
An adoption direction
A rollout sequence, ownership expectations and an engineering handoff.
- Sections grouped by task
- Campaign views in one row of tabs
The design library and its documentation hand off to your engineering team, with a coded component library scoped separately.
Discuss your productA system built around the product it supports.
The system grows from the interface you already have and the states it really meets, then is governed so it stays one system.
-
Inventory
What exists across screens, libraries, brand rules and code, and where it has drifted.
-
Foundations
Tokens for colour, type, spacing and elevation that every component builds on.
-
Components and states
Components with their loading, empty, disabled, error and success states.
-
Patterns and documentation
How components combine in real workflows, and when to use which.
-
Governance and adoption
How changes are proposed and reviewed, and how teams move onto the system.
Ownership and decision rights
- System owner
- What enters the system and when.
- Product designers
- Propose new components and patterns from real work.
- Engineering lead
- Where the design library meets coded components.
How you will know it works
- New screens built from system components
- Fewer one-off variants
- Faster reviews and handoffs
Shared components need shared responsibility.
-
Patterns that repeat
You have repeated interface patterns or several related product areas.
-
Design and engineering aligned
Design and engineering can agree how the system will be used.
-
A named owner
There is an owner for decisions, contributions and maintenance.
-
Adoption through real work
You want to introduce the system through actual product work.
Tell us what your product needs
Share where the product is and what has to change. We will come back with a useful scope and a realistic next step.
How the engagement works
What we need from your team, who does what, and what happens after the handoff.
What we need to start
- Material
- The existing screens, components, brand rules and code the system can build on.
- Scope
- The product areas and recurring patterns the first useful scope should cover.
- An owner
- Someone who can decide, review contributions and maintain the library.
- Engineering
- Engineering in the conversation, so implementation constraints are known early.
Who does what
- ANODA
- reviews what exists, defines the foundations, components and patterns, and documents how to use them.
- Your team
- names an owner, reviews contributions and maintains the system after handoff.
After the first scope The system extends as it is adopted, one product area at a time; a coded component library is a separate engagement with frontend engineering. Usually 6–12 weeks for an agreed scope.
In the client's words
We now have a full design system and user journey ready for development, perfectly aligned with our vision.
Where is your interface starting to drift?
Tell us about the products, teams and libraries involved. We will discuss the shared patterns that would make the next phase of delivery easier to manage.
Message received.
Within 15 minutes, we’ll email you initial feedback and follow-up questions.
Design System Components: What to Include and How to Govern Them
Learn what design system components include, how they differ from patterns and UI kits, and how product teams document, govern and scale them.
Design Systems: common questions
Do we need to start from scratch?
Usually the first step is to assess what already works. Existing components, brand rules and code can provide the basis for the system. We distinguish useful reuse from inconsistencies that need to be resolved.
Will the system include code?
A coded component library is included only when frontend engineering is explicitly scoped. The design system engagement can cover foundations, components, states and documentation in design, with a clear handoff to your engineering team.
Can you support multiple products or themes?
Yes, when that requirement is part of the scope. We identify what should be shared and what needs a controlled variation. Different roles, product needs and themes should have explicit rules rather than become separate, drifting copies.
How do you approach accessibility?
We consider accessibility in component behaviour, states and usage guidance and agree the relevant review criteria. A design library alone does not establish the accessibility of the implemented product; implementation and testing remain part of delivery.
Can we roll it out gradually?
Yes. We can start with a useful set of patterns and one product area, then extend the system as it is adopted. The sequence should account for existing code, release plans and dependencies rather than require an immediate full-product replacement.
Who maintains the system afterwards?
Your team needs an agreed owner and a way to review contributions. We can define the initial guidance and discuss ongoing support, but continuing maintenance is a separate responsibility that should be made explicit before handoff.