Design systems to promote unity within your organisation
Consistency across your digital experiences.
Comprehensive component libraries
All your website's UI elements in one place
Lighten the legwork
Focus on complex UI/UX problems
A single source of truth
Unify your digital experiences
Tighten the reins on your UI
One library to rule them all
Store, manage and share your UI elements with all who touch your website, all based on a consistent design system.
Style guides
Rules and regs on how collaborators use and translate your brand online.
UI kits
Your UI components, patterns and styles, pre-designed and ready to use – and reuse.
Component libraries
An online repository to house your pre-built UI components, complete with code snippets. Tried and tested.


One team to bind them
With U & I together, UX can only get better.
Your UI partner
The ‘guardians’ of your design system, as and when it evolves, we’ll keep it up-to-date.
Design system strategy
Identify and plan your design system requirements.
UI audits
Unclear on what's going on with your UI? We’ll assess the damage and make a plan to fix it.
Why Honcho?
We’re not a full-service agency
We're web experts with business acumen
We've been around since 2013 AD
We’re here for the long run 💍
We'll guide you to success
Even our developers speak like humans
We don’t cut corners to sacrifice quality
We’re efficient AF
Ongoing training
We never stop learning
We're not afraid to speak our mind
Honesty + Experience + Truth
We build long-term partnerships for success.
Like marriage, but with more sex.
We know what works
But we’re ready to be challenged
Trusted by 180+ organisations
Solid process. Zero guesswork.
1. Discovery
A deep dive into where you're at – and where you need to be.
2. Strategy
Identify and plan the requirements of your design system. Take an inventory and make a checklist.
3. UI kit
Create the styles, components and patterns of your design systems, ready to use.
4. Component library
Develop the components of your design system in html and css. View, copy, paste.
5. Implementation
If we're doing your web development, your design system is our single source of truth.
6. Learn, evolve and grow
If your website grows like an adolescent boy, so will your design system.
Three small steps for you. One giant leap for your UI
Get in touch
Give us the low-down.
Strategy
Planned and aligned for success.
Delivered
Piping hot. On-time. On budget.
Ready to talk?
Our insights
Contents
The ultimate introduction to design systems
Teams building digital products today often face familiar challenges: inconsistent user interfaces, slow delivery cycles, repeated design and development work, and ongoing friction between design and engineering teams. These issues stem from the lack of a unified approach to managing design at scale.
Without a clear system, each product or feature risks drifting away from brand identity and user expectations, causing confusion and inefficiency.
"Have you ever performed a UI audit and found you’re using a few dozen similar hues of blue, or permutations of the same button?" Marco Suarez, Design Systems Handbook (InVision).
The resulting delays, duplicated work, and wasted design efforts frustrate teams and stakeholders alike, highlighting the need for a better way to collaborate and scale design.
Enter the design system. 🥳 A design system is a comprehensive framework of reusable components, guidelines, and tools that helps teams create consistent, efficient, and cohesive digital products.
In one Figma experiment, designers completed tasks 34% faster when they had a relevant design system - Figma Blog, Measuring the value of design systems
However, if a design system is not properly implemented, it can actually increase disorganization and inefficiency, compounding the very problems it is meant to solve.
“Bespoke design simply doesn’t scale. Bespoke design is slow, inconsistent, and increasingly difficult to maintain over time.” Marco Suarez, Design Systems Handbook (InVision)
This underscores the importance of having a robust design system in place.

Where the idea came from
In the early days of design systems, their origins can be traced back to the influence of print media, where print design standards and brand manuals historically provided consistent visual guidelines for logos, typography, and colour. These print media frameworks laid the groundwork for systematic design thinking.
Christopher Alexander, through his pioneering work on pattern language in architecture—especially his book ‘, A Pattern Language introduced the idea of interconnected patterns that could be reused across projects. The concept of reusable patterns and shared mental frameworks became foundational to modern design systems, establishing a common language and strategic approach for teams. Alexander’s insights into pattern language inspired early thinking about design as a collection of reusable components, a principle that would later influence software development and UI design.
As digital products emerged, the challenge shifted to applying these ideas in fast-moving, complex environments. In these early days, the emergence of the design pattern library and user interface library, such as the Yahoo! User Interface Library (YUI), provided foundational resources for consistent UI component development. Early attempts to reuse design elements and code hinted at the potential for systematic approaches, but the scale and speed of software development demanded new solutions.

The shift to digital products
UI kits and static style guides? They hit a wall pretty fast. Sure, you get some components and a few rules, but when your product starts sprawling across teams and channels, these tools show their age. They can't keep up. Your brand starts looking patchy, your user experience gets messy, and you're left playing catch-up with inconsistencies that multiply faster than you can fix them.
Here's what actually works: proper design systems. Not the half-hearted kind, but the real deal with solid guidelines, rock-solid resources, documentation that doesn't make people cry, and components you can actually reuse without breaking things. You document your patterns, you apply them systematically, and suddenly you've got consistency that scales. It's not magic – it's just doing the work properly from the start.

Design system foundations
A design system isn’t just a bunch of assets sitting in a folder, it’s a solid framework that helps design and dev teams build digital products that actually work together. It establishes a consistent visual language and core design principles that guide the look and feel of all digital products. This includes typography, colour palettes, iconography, and spacing, which together create a visually cohesive experience that strengthens brand identity. Clear design principles help teams make informed decisions, ensuring every UI element aligns with the brand’s values and user needs.
"A style guide is an artifact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem.” Nathan Curtis, Center Centre
At its heart, a good design system acts as your single source of truth, pulling together component libraries, pattern libraries, style guides, and a clear design language. These core pieces give you reusable components and proper documentation, which cuts out the busy work and stops teams from building the same thing twice. Design system documentation plays a crucial role here, providing structured, accessible guidelines and resources that help teams design consistent user interfaces and follow best practices across platforms.
In Sparkbox’s 2022 survey, 95% of respondents said their design system includes components, and 85% said it includes component documentation. - Sparkbox, The 2022 Design Systems Survey
When you set up a system that makes your visual and functional standards clear, different teams can actually work together without the usual headaches. Dev teams get components they can trust and understand, while designers can focus on solving real problems instead of rebuilding buttons for the hundredth time. This approach doesn’t just speed things up, it makes sure every digital product feels like it belongs to your brand and identity and does what users expect. Get your design system right, and you’ll work more efficiently, keep everyone aligned, and build products that can grow without falling apart.

How different stakeholders use a design system
A design system serves various roles depending on the stakeholder, ensuring alignment and efficiency across the entire product lifecycle.
Designers
Designers rely on a design system to maintain visual consistency and streamline their workflow. The system provides them with a library of reusable components, clear design guidelines, and a unified language that helps ensure every element aligns with the brand’s identity and user experience goals. By leveraging a design system, designers can focus more on solving complex UX problems and less on recreating basic UI elements, allowing for faster iteration and higher-quality designs. It also helps them seamlessly switch between different themes or platforms without losing coherence.
“Designers want to focus their time on solving the problems unique to their product, instead of spending time reinventing the wheel.” - Barnardo’s design system, quoted by Amy Hupe
Developers
Modern design systems include code snippets and component libraries that bridge the gap between design and development teams. These resources provide developers with ready-to-use, tested UI components, reducing guesswork and speeding up implementation. This integration ensures that designs are faithfully translated into functional interfaces, improving collaboration and reducing errors. Developers benefit from consistent components and clear documentation that help maintain code quality and accelerate the development process.
“Rather than focusing on pixels, developers can focus on application logic, while designers can focus on user experience, interactions, and flows.” - Salesforce Trailhead, Lightning Design System
Product Managers
Product managers use design systems to align cross-functional teams (groups composed of members from different departments or areas of expertise within an organisation) around shared goals and expectations. The system offers a clear framework for prioritising features and ensures that design and development efforts contribute to a cohesive user experience. By referencing the design system, product managers can better communicate requirements, track progress, and make informed decisions that balance user needs, technical feasibility, and business objectives.
Stakeholders and Executives
For stakeholders and executives, a design system provides visibility into the design and development process, enabling better oversight and strategic planning. It serves as a single source of truth that demonstrates how consistent branding and user experience are maintained across products, reducing risks associated with fragmented design efforts. By investing in and supporting a robust design system, leadership can drive efficiency, cost savings, and faster time to market, ultimately contributing to stronger brand equity and customer satisfaction.
Content Strategists and Writers
Content strategists and writers use design system guidelines to ensure that tone of voice, language style, and content structure align with the brand’s identity and user experience goals. Clear documentation helps them create consistent messaging across digital products, reinforcing the overall brand experience.
Quality Assurance (QA) Teams
QA teams refer to the design system to verify that UI elements and interactions meet the defined standards, ensuring consistency and reducing bugs related to visual or functional discrepancies. The system acts as a benchmark for quality and usability across products.
Marketing Teams
Marketing teams leverage design systems to maintain brand consistency across campaigns and digital touchpoints. By aligning marketing materials visually and thematically with product interfaces, they help create a cohesive brand presence that resonates with users.
Onboarding and Training Coordinators
Design systems serve as educational resources that help onboard new team members quickly by providing a clear understanding of design principles, components, and workflows. This accelerates ramp-up time and ensures that new hires contribute effectively to design and development efforts.

Material design and other inspirations
Google’s Material Design gets it right. It’s a solid design system that gives you guidelines, components, and the building blocks you need to keep things consistent. No guesswork. No reinventing the wheel every time. It works so well that plenty of other companies have borrowed its approach, and that’s smart.
“Google’s Material Design set a new standard by combining comprehensive design guidelines with coded components, enabling teams to create consistent and scalable digital experiences.” — Google Material Design, Material.io
Apple’s Human Interface Guidelines. and Microsoft’s Fluent Design do the same job, just with their own flavour. Different companies have unique requirements and contexts, which influence how they implement design systems, typography, and terminology. Study them. Learn what makes them tick. Take the good bits and use them in your own work. The secret sauce is design tokens, those standardised variables that control colours, spacing, and fonts. They’re simple but powerful. Set them up once, and your whole team can move fast while keeping everything looking like it belongs together. No more design drift. No more “close enough” compromise

The role of design tokens
Design tokens are the backbone of modern design systems, acting as named variables that store core design attributes such as colours, typography, and spacing.
$bg-dark: $colour-neutral-20;
$bg-light: $colour-neutral-90;
$text-size-body: $font-size-m;
$text-size-micro: $font-size-s;
$space-inset-base: 16px;
$space-stack-large: 32px;"Design tokens and styling hooks are visual design ‘atoms’… named entities that store visual design attributes." Salesforce Developers
They enable teams to create consistent visual elements across different platforms and devices, all based on a set of unified variables. Tokens simplify updates by allowing changes to propagate automatically throughout the system.
In Sparkbox’s 2022 survey, 69% of respondents said their design system includes design tokens. - Sparkbox, The 2022 Design Systems Survey
When Google's material design went mainstream
Breakthrough moments helped bring design systems into the mainstream. Yahoo!’s Pattern Library in 2006 was a pivotal moment that sparked mainstream interest in design systems, serving as an early public effort to organise reusable UI patterns systematically.
Google’s Material Design in 2014 marked a significant milestone, introducing a comprehensive design language that combined visual guidelines with coded components, setting a new standard for digital design systems.
At scale, public-sector projects like GOV.UK demonstrated how design systems could unify diverse teams and products under a single, accessible framework, proving their value beyond commercial applications.
"The GOV.UK Design System helps teams that work on government services follow the Government Design Principles and GOV.UK Service Manual." GOV.UK Design System
The rise of open source design systems and platforms like the Figma Community have made these resources more accessible, enabling teams to collaborate, adopt, and scale consistent design practices efficiently.

What changed for teams after this point
These developments revolutionised how teams approach design. Design systems evolved from mere collections of components and style guides into powerful tools that supercharge collaboration between design and engineering teams. By creating a unified language that bridges disciplines, they cut through confusion and streamline workflows like never before. Packed with reusable components, clever design tokens, core principles, and detailed documentation, design systems empower teams to effortlessly switch between platforms or themes without reinventing the wheel. This not only guarantees consistency and efficiency but also steers product design towards seamless, cohesive user interfaces that uphold brand integrity every step of the way.
“Homebase connects product management, design, and engineering through a shared language that describes the digital products we make at Wayfair.” - Wayfair

Creating a design system
Building a design system isn't rocket science (easy to say for an agency that creates them 🤣), but it does require some actual thinking upfront. Start here: what are you actually trying to solve? Don't just say "consistency"—that's what everyone says. Dig deeper. What products need this system? What principles will guide your decisions when things get messy? And they will get messy. Pick principles that mean something specific, not fluffy mission-statement speak.
Here's where most teams stumble: designers and developers working in silos, then wondering why nothing fits together. Skip the drama. Get them in the same room from day one. Build your component libraries and pattern libraries together, not separately. Your style guide isn't decoration—it's the rulebook that stops arguments about whether that button should be 8px or 10px padding. Every decision about type, colour, spacing, and icons needs to be documented. Otherwise, you're just creating organized chaos.
Design tokens are your secret weapon, though most people use them wrong. They're not just fancy variables—they're the difference between updating your entire colour scheme in five minutes or spending three weeks hunting down every hex code. Want to support light and dark modes without losing your mind? Tokens make it trivial. Want to rebrand without a complete rebuild? Tokens again.
A solid design system saves time, cuts waste, and stops your users from feeling like they're using five different products. Look at Material Design—Google didn't build it to show off. They built it because scattered, inconsistent interfaces cost real money and frustrate real people. Your design system should be the single source of truth that settles arguments, aligns your team, and makes your brand feel intentional instead of accidental.

Cross-functional teams collaboration
Design systems foster better collaboration among cross-functional teams by providing a shared language and resources. Designers, developers, product managers, and other stakeholders can work from the same playbook, reducing misunderstandings and improving efficiency. This alignment accelerates decision-making and helps deliver a unified user experience.

Governance and Maintenance
As design systems grow, governance becomes essential. Establishing clear roles for who approves new components, maintains documentation, and manages updates helps keep the system reliable and flexible. Ongoing maintenance ensures the design system evolves with the product and continues to meet team needs without becoming outdated or cumbersome.
Sparkbox found that only 44% of teams reported having a governance model or sharing a design system roadmap - Sparkbox, The 2022 Design Systems Survey
"It wasn’t hard to get them to follow the guidelines, it was hard to get them to agree on the guidelines." Lori Kaplan, Atlassian (via Design Systems Handbook, InVision)

Best practices for implementation
Getting a design system to actually work takes a bit of sense and a lot of patience. Here's what works: start small. Pick one thing—maybe your button library, maybe your basic patterns—and get it right before you go mad trying to fix everything at once. Your teams need wins, not overwhelming to-do lists. Build momentum, listen to what people actually say (not what they think they should say), and sort your process as you go.
You can't build this thing in a corner. Get your designers, developers, and product folk talking from day one. Everyone needs skin in the game, or you'll end up with something that looks pretty but doesn't work, or works brilliantly but nobody uses. When people help build it, they'll actually champion it. When they don't, well, good luck with that.
Documentation isn't glamorous, but it's everything. Write it like you're explaining to your colleague, not like you're trying to win a corporate writing award. Code snippets, clear examples, the real stuff people need when they're stuck at 4pm on a Friday. And yes, you'll need to talk to people face-to-face sometimes. Training sessions work. Conversations work. Hoping people will figure it out on their own? That doesn't work.
Sparkbox found that only 30% of teams reported having support, training, and onboarding for their design system, but “successful” systems had these in place 76% of the time. - Sparkbox, The 2022 Design Systems Survey
Here's the bit most people get wrong: your design system isn't a monument. It's a living thing. Trends shift, users change their minds, businesses pivot. If you're not updating and reviewing regularly, you're building tomorrow's technical debt. Flexibility isn't weakness—it's survival.
Look at what Atlassian and Salesforce actually did. They didn't create perfect systems overnight. They built smart, stayed practical, and kept iterating. The result? Teams that work better together, faster development, and experiences that don't make users want to throw their laptops out the window. Follow their lead: be structured, but not rigid. Be inclusive, but not democratic about everything. Be adaptable, because the alternative is obsolescence.
Overcoming implementation challenges
Rolling out a design system? It's messy. Especially when you've got multiple products or teams scattered everywhere. The biggest headache is keeping everyone on the same page. Here's what works: get one team to own the whole thing. Make them responsible for the system's evolution. No exceptions. Everyone else follows their lead.
Getting stakeholders on board can be a pain. Don't dance around it. Show them the real benefits—faster work, less wasted effort, a brand that doesn't look like it was designed by committee. Bring them into the process early. Ask for their input. When people feel like they own something, they actually care about it.
Technical integration is where things get tricky. Your new design system needs to play nice with existing software and workflows. Work closely with your dev teams—they're not the enemy. Use design tokens and modular components. Makes updates simpler and stops everything from breaking when you change one button.
Learn from others who've been through this mess. Airbnb and Uber built their own systems and lived to tell about it. Open source options like Material Design give you a solid starting point without reinventing the wheel. Know the pitfalls before you hit them. Do this right and you'll get efficiency, better teamwork, and users who actually enjoy what you build.
The business impact and lessons from real projects
A design system pays for itself when it stops your team from redoing the same work. It cuts decision churn, removes “near enough” UI, and gives everyone a shared baseline they can ship from.
The speed gains can be real. In a Figma experiment, designers finished tasks 34% faster when they had an up-to-date, relevant design system to work from.
That is the difference between a team that moves with confidence, and a team that keeps second-guessing spacing, states, and component behaviour.
Most teams already understand what a design system should contain. Sparkbox’s 2022 survey found 95% include components, 85% include component documentation, and 69% include design tokens.
But the same survey shows where things often fall apart. Only 44% reported having a roadmap or a process for deciding what gets added, updated, or removed. Only 30% reported having onboarding for new subscribers or contributors.
So you end up with a library that exists, but doesn’t scale.
The clearest proof comes from teams that measured outcomes after rollout. IBM’s Commerce Platform team moved their checkout flow onto Carbon and reported a 5% increase in conversion rate.
IBM Cloud also shared a brutal, practical metric: they estimated saving 2,000 hours per pattern, making teams 80% more efficient than designing or coding screens from scratch.
And in the public sector, Triad built a Common User Interface aligned to GOV.UK Design System principles and said it saved each project team around six weeks of development time.
These numbers only show up when the system behaves like a product. Someone owns it. People can learn it quickly. Decisions stay visible. The system evolves as the work evolves.
Want a simple gut check?
If you paused all new feature work for two weeks, would your team use that time to build one shared set of components, or would they keep polishing one-offs?

Is it time for your own design system?
If your teams struggle with inconsistent UI, duplicated work, or slow iterations, it may be time to consider a robust design system.
Ask yourself: Are design decisions duplicated across teams? Is onboarding new members slow and inefficient? Are product updates inconsistent or costly across platforms?
Answering yes to these questions signals that ad-hoc approaches have been outgrown and a strategic investment in a design system is warranted.
Design systems are not mere assets or libraries; they are critical infrastructure for scalable, consistent digital products. Ignoring their value risks ongoing inefficiency, higher costs, and fragmented user experiences.
The next step is to assess your current design process, align stakeholders on goals, and plan governance and tooling to build a sustainable design system that empowers your teams and users alike.
Is your product starting to feel like it was built by different teams who never spoke?
That’s usually the moment a design system stops being “nice to have” and becomes urgent.
If you want a design system that your team actually uses, get in touch.
We’ll help you:
- audit what you have now
- define the principles and guardrails that stop design drift
- build a component library and tokens your developers can ship with confidence
- set up governance so it stays useful
Book a call and we’ll tell you, straight, whether you need a design system, a clean-up, or something simpler.

Ready to talk design systems?
Reach out to tell us about your design system challenges.
Want further reading?
We've written a lot about design systems, here are some of our other articles.
- Design system governance best practices - Ben explains how strong design system governance keeps UI consistent at scale by setting clear roles, contribution rules, versioning, tooling, and feedback loops so teams can ship faster without drifting into chaos.
- How to create a design system to unite your collaborators and cultivate consistency - Mole explains how to build a design system by defining clear principles, creating a reusable UI library (styles, components, patterns), and setting up a team and process so your digital products stay consistent and faster to design and build.
- How design systems reduce cost and improve team efficiency - Ben explains that design systems cut cost and boost team efficiency by reducing rework and inconsistency, speeding up design to development handoff, improving collaboration through shared components and documentation, and delivering measurable ROI as products scale.
- The Future of Design Systems: The Death of the Static Library and How AI is Rewriting - Ben argues that design systems will shift from static component libraries to AI-driven logic engines that generate interfaces, automate governance, reduce handoff friction, and keep systems adaptable as products scale.
FAQ's
Some common FAQ's to help you understand design systems.
What is a design system?
A design system is a shared set of components, styles, tokens, and rules that teams use to design and build consistent digital products.
It includes design assets and coded components.
It also includes the guidance that stops people using them in the wrong way.
What is the difference between a design system and a style guide?
A style guide focuses on visual rules like typography, colour, spacing, and logo use.
A design system includes those rules, plus components, patterns, code, documentation, and governance.
What is the difference between a design system and a UI kit?
A UI kit is usually a set of design components, often in Figma.
A design system adds usage rules, accessibility guidance, coded components, tokens, and a maintenance process.
What is the difference between a design system and a component library?
A component library is a collection of UI building blocks.
A design system includes the component library, plus patterns, content guidance, tokens, and decision-making rules.
What is the difference between a design system and a pattern library?
A pattern library focuses on reusable solutions like navigation, forms, and page layouts.
A design system includes patterns, plus components, tokens, principles, and governance.
What is the difference between a design system and a design language?
A design language is the visual and interaction style of a brand.
A design system is the practical implementation of that language in assets, components, and rules.
When should you start a design system?
Start when:
you see the same UI rebuilt in multiple places
you ship slower as the product grows
you argue about basics like spacing, states, and behaviour
new hires struggle to match the product UI
What problems does a design system solve?
It reduces:
inconsistent UI
duplicate design and build work
decision churn
drift between design and code
slow onboarding
What problems can a design system create?
It can create:
slow delivery if governance becomes a bottleneck
low adoption if documentation is poor
drift if design and code versions diverge
wasted effort if you build too much too early
What makes a design system successful?
It succeeds when:
teams use it daily
it stays in sync between design and code
it has clear ownership
it has simple contribution rules
it prioritises what teams need next
Why do design systems fail?
Common reasons:
nobody owns it
it ships once, then stops evolving
it focuses on visuals but ignores code realities
it lacks documentation and examples
teams cannot trust it to be up to date
How long does it take to build a design system?
A useful v1 can take weeks, not months.
A complete system never “finishes”.
It evolves with your product.
How much does a design system cost?
Cost depends on product size, team count, and how much already exists.
The bigger cost usually comes from not having one, through duplicated work and slower delivery.
What should a design system include?
Most systems include:
design tokens
typography and colour styles
layout and spacing rules
components and variants
accessibility guidance
usage rules and examples
coded components and release notes
What are design tokens?
Tokens are named variables for design decisions like colour, type scale, spacing, and radii.
They let you update a system once and have changes propagate everywhere.
Why are design tokens important?
They reduce manual updates.
They make themes easier.
They reduce drift between design and code.
Are design tokens only for developers?
No.
Designers rely on tokens to keep files consistent.
Developers rely on tokens to keep code consistent.
What is a token taxonomy?
A taxonomy is how you organise tokens, for example:
core tokens like raw colours
semantic tokens like “text default”
component tokens like “button background”
What is the difference between core tokens and semantic tokens?
Core tokens store raw values.
Semantic tokens map those values to meaning and usage.
Semantic tokens make theming and refactors safer.
Do I need tokens before components?
If you want a system that scales, yes.
Tokens reduce rework when you adjust colour, spacing, or typography later.
What are design principles in a design system?
Principles are short rules that guide decisions when components do not cover a case.
They stop debates from turning into opinion fights.
How many design principles should you have?
Aim for a small set.
Enough to guide decisions.
Not so many that nobody remembers them.
What is design system governance?
Governance is how you decide what gets added, updated, deprecated, and removed.
It also defines who can approve changes.
Who owns a design system?
Usually a small group.
Often a design system lead plus a dev lead.
Sometimes a dedicated team if the org is large.
Should product teams contribute to the design system?
Yes, if you make it easy.
Contributions improve adoption.
They also keep the system focused on real needs.
How do you manage contributions without chaos?
You need:
contribution guidelines
review roles
a clear release process
a definition of done for components
What is a design system backlog?
It is a prioritised list of fixes, additions, and improvements.
It helps you build the system based on demand, not guesses.
What is a design system roadmap?
It shows what you will tackle next and why.
It helps product teams plan and reduces surprise changes.
How do you measure design system success?
Measure:
adoption and usage
reduction in duplicate components
time saved on common UI
consistency in shipped UI
satisfaction from designers and developers
What metrics should you track?
Track things you can actually act on, like:
component usage
contribution volume
open issues and time to resolve
version drift between design and code
accessibility defects related to UI patterns
What is design drift?
Design drift is when the UI slowly diverges from the intended system.
It often happens when teams create one-offs under time pressure.
How do you prevent design drift?
You prevent drift when:
components cover common needs
documentation answers real questions
teams can request changes quickly
review checks system alignment
design and code stay in sync
What is the difference between Figma components and coded components?
Figma components define design intent.
Coded components define implementation.
A design system needs both, aligned to the same source of truth.
Should the design system live in Figma?
Part of it should, yes.
Designers need reliable components and styles.
But the coded system needs its own home too.
Where should coded components live?
Usually in a shared package, library, or monorepo.
It depends on your stack, but the key is versioning and easy consumption.
Should you use Storybook?
Storybook can work well for documenting components and states.
It helps teams test variants, edge cases, and behaviour.
Only use it if your team will maintain it.
Do design systems replace designers?
No.
A design system removes repeat work.
Designers focus more on problems, flows, and product decisions.
Do design systems replace developers?
No.
A design system removes repeat UI build work.
Developers focus more on application logic and performance.
Can a design system improve accessibility?
Yes, if you bake accessibility into components and patterns.
Accessible defaults reduce repeated fixes in every feature.
What accessibility guidance should the system include?
Include:
focus states and keyboard behaviour
colour contrast rules
error messaging patterns
form labels and hints
motion and reduced motion guidance
How do you handle dark mode in a design system?
Use tokens.
Map semantic tokens for light and dark themes.
Avoid hard-coded colours in components.
How do you handle multiple brands in one design system?
Use:
a shared foundation for spacing, grids, and component behaviour
brand tokens and theme layers for visuals
clear rules for what can vary and what must not
Should marketing use the design system?
If marketing builds landing pages or web UI, yes.
Shared components reduce mismatched brand expression.
Should content guidelines be part of a design system?
Yes, if content affects UX.
Add rules for:
labels
error messages
helper text
empty states
tone and reading level
What is a content design system?
It is the voice, patterns, and rules that shape content across a product.
It often sits alongside UI components.
What are UI patterns?
Patterns are repeatable solutions like:
sign-in flows
filtering and sorting
multi-step forms
navigation models
empty states
What is the difference between a component and a pattern?
A component is a building block like a button.
A pattern is how multiple components work together to solve a user task.
Should you document patterns as well as components?
Yes.
Patterns stop teams inventing new flows for the same job.
What should component documentation include?
Include:
when to use it
when not to use it
variants and states
accessibility behaviour
content guidelines
examples and edge cases
How do you document states properly?
Show:
default
hover
focus
active
disabled
loading
error
empty states where relevant
How do you decide what components to build first?
Start with what your product uses most.
Buttons, inputs, typography, spacing, and layout rules usually come early.
Should you start with atoms and molecules?
Only if that model helps your team.
Focus on shipping useful components, not following a framework for its own sake.
What is atomic design?
Atomic design is a way to structure components from small to large.
It can help organise libraries, but it is not required for success.
How do you handle legacy UI when starting a design system?
Audit what exists.
Identify the highest-usage screens.
Migrate gradually, starting with shared components that reduce the most repetition.
Should you refactor everything at once?
No.
Move in slices.
Ship improvements while you migrate.
How do you migrate without blocking product work?
Offer a path:
new work uses the system
old areas migrate when touched
high-traffic or high-change areas move first
How do you enforce usage without annoying teams?
Make the system the easiest option.
If using it feels slower, teams will avoid it.
What is a design system audit?
It is a review of your UI, components, and workflows to find:
duplication
inconsistency
missing states
accessibility gaps
drift between design and code
What should a UI audit output look like?
It should show:
what to standardise first
what to retire
what to consolidate
what to document
what to build next
What is a design system maturity model?
It is a way to describe how advanced your system is.
It can help you plan improvements without trying to “do everything”.
What is “single source of truth” in a design system?
It means teams trust one place for the correct answer on components, tokens, and rules.
If design and code disagree, you do not have a single source of truth.
How do you keep design and code in sync?
You need:
shared naming
versioning
release notes
review between design and engineering
a clear process for updates
Should you version a design system?
Yes.
Versioning prevents breaking changes from surprising teams.
It also makes adoption easier to manage.
What is a breaking change in a design system?
A change that forces product teams to update code or layouts.
Examples include removing props, renaming tokens, or changing component structure.
How do you deprecate components?
Mark them as deprecated.
Explain why.
Provide the replacement.
Give a timeline.
How do you name components and tokens?
Use names people will understand in six months.
Prefer clarity over cleverness.
Keep naming consistent between design and code.
What tools do you need for a design system?
Tools depend on your stack.
Most teams use:
Figma for design assets
a component library in code
documentation tooling
a place to track issues and requests
Can small teams benefit from a design system?
Yes, if you keep it lean.
You can start with tokens, typography, and a small set of components.
What does a “lean” design system look like?
It looks like:
a token set
typography and spacing rules
a small component library
short, practical documentation
clear ownership
Do I need a dedicated design systems team?
Not always.
If you have many squads or multiple products, a dedicated team helps.
If you are smaller, assign clear ownership and protect some time.
How do you get stakeholder buy-in?
Show the cost of inconsistency.
Show the repeated work.
Show how a system reduces risk and increases delivery speed.
How do you sell a design system internally?
Frame it as:
product quality
delivery efficiency
accessibility risk reduction
easier onboarding
lower maintenance cost
How do you avoid building a design system nobody uses?
Build what teams need now.
Document it well.
Make contribution easy.
Keep the system current.
How do you handle exceptions and one-offs?
Define a process.
Decide if it becomes a pattern, stays a one-off, or gets rejected.
Track decisions so the same debate does not repeat.
How do you handle data visualisation in a design system?
Define:
chart types you support
colour usage rules
accessibility requirements
responsive behaviour
formatting rules for numbers and labels
Do design systems help with QA?
Yes.
QA teams can test against consistent component behaviour and states.
It reduces “special case” UI bugs.
Do design systems help with performance?
They can.
Reusable components can reduce UI code duplication.
But only if you keep the system lightweight and avoid shipping unused bundles.
Are design systems the same as frameworks like Bootstrap?
No.
Bootstrap is a UI framework.
A design system is your organisation’s rules, components, and decisions, which may use a framework.
Should you build from scratch or adopt an existing system?
If you need speed, start from an existing base.
If you need brand specificity, customise.
Most teams do a hybrid approach.
Is Material Design a design system?
Yes.
It includes guidelines, components, and patterns.
It also provides coded implementations.
Is GOV.UK Design System a design system?
Yes.
It provides accessible components and patterns for government services.
What is the quickest way to start a design system?
Audit what you already ship.
Pick a small set of principles.
Define tokens.
Build a few high-usage components.
Document usage.
Assign ownership.
What should I do if my team already has three different UI libraries?
Choose one target.
Plan consolidation.
Create a migration path.
Avoid rebuilding the same components in parallel for too long.
How do you run a design system workshop?
Focus on:
what you are standardising
which problems you are solving first
what “done” looks like
how changes get approved
how teams will adopt it
What questions should you ask before starting?
Ask:
where do we waste time today
which UI patterns cause the most bugs
which parts of the UI do users touch most
what needs to stay consistent across products
who will own decisions
What should I include on a design system homepage?
Include:
what it is
who it is for
how to use it
how to contribute
latest changes
links to tokens, components, and patterns
How do you keep documentation up to date?
Tie documentation to the release process.
If the component changes, the docs change.
No exceptions.
What is the role of a design systems designer?
They define component behaviour, usage rules, and patterns.
They keep the system coherent.
They work closely with engineering to keep design and code aligned.
What is the role of a design systems engineer?
They build and maintain coded components.
They manage tokens, packaging, testing, and release.
They help product teams adopt and contribute.
What is the role of product managers in design systems?
They help prioritise system work based on product needs.
They align roadmaps.
They protect time for maintenance.
How do design systems help onboarding?
New hires get a shared language, ready components, and clear rules.
They ship faster with fewer corrections.
What is a design system request process?
It is how teams ask for new components, changes, or fixes.
A good process makes requests visible, trackable, and fast to resolve.
What is the difference between “brand consistency” and “UI consistency”?
Brand consistency is visual identity and tone.
UI consistency is behaviour and patterns across screens.
A design system should cover both.
What is “consistency” in a design system, really?
It is predictable behaviour.
It is repeatable patterns.
It is using the same solutions for the same problems.
Can a design system support mobile apps and web?
Yes.
Tokens and patterns can span platforms.
Components may differ by platform, but rules and naming should align.
How do you handle responsiveness in a design system?
Define breakpoints and layout rules.
Document how components behave at different sizes.
Avoid designing only for one viewport.
How do you handle localisation in a design system?
Plan for:
longer strings
right-to-left layouts
date, time, and number formats
truncation and wrapping rules
Do design systems help reduce bugs?
They can, because shared components reduce one-off implementations.
But only if teams stop forking components to “quick fix” things.
How do you keep a design system simple?
Prioritise what teams use most.
Avoid adding variants “just in case”.
Remove things that nobody uses.
When should you rebuild a design system?
Rebuild when:
it cannot support product needs
it lacks tokens or theming
the codebase makes changes risky
adoption is low because it is hard to use
When should you not build a design system?
Do not build one if:
you have no product stability at all
you cannot allocate ownership time
the biggest problem is unclear product strategy, not UI consistency
What is the first component every design system should have?
Buttons often come first because every interface uses them.
But inputs, typography, and spacing rules matter just as much.
What is a good sign your design system is working?
Teams stop asking “what do we do here”.
They just know.
They can ship without re-litigating basics.
What is a bad sign your design system is not working?
Teams clone components, tweak them, and never contribute back.
That is drift in real time.
How do I know if my organisation is ready?
You are ready if:
leaders will support time for maintenance
design and engineering can collaborate closely
you can agree on a small set of standards
you will measure adoption and usage
Can you help us build or fix a design system?
Yes.
If you tell me your product type, team size, and current tooling, I can recommend a starting plan and the first 5 components to prioritise.









