Design systems: why teams stop redrawing buttons
A growing payments startup has three designers and eight developers. Nobody planned it, but after two years the app has fourteen slightly different buttons, six greens, three ways of showing an error, and two different icons for "back".
Every new screen starts with the same questions: "Which button do we use here?" "What's the right spacing?" "Is it 'Transfer' or 'Send money'?" Developers rebuild the same components again and again. When the company decides to update its brand colour, it takes four months, and some screens still have the old green.
Their competitor, with a smaller team, ships new features faster. The difference is a design system. This lesson explains what one is, why teams build them, and how the work you've already done in this course is the beginning of your own.
Words in this lesson
| Word | What it means, in plain English |
|---|---|
| Design system | A complete set of standards, reusable components and patterns for designing and building a product at scale. |
| Style guide | Written guidance on things like brand, colour, typography, and tone of voice. |
| Component library | A collection of reusable interface elements, like buttons and text fields, with guidance for using them. |
| Pattern library | Reusable groups of components or layouts, like a sign-in form or a page template. |
| Governance | The agreed way decisions about the system are made, changed and shared. |
| Single source of truth | One agreed place where the official version of something lives. |
What a design system is
Nielsen Norman Group define a design system as:
A complete set of standards intended to manage design at scale using reusable components and patterns.
NN/g explain that a design system has two important parts:
- The design repository: the standards and components themselves.
- The people who manage it.
That second part is often forgotten. A folder of components nobody maintains isn't a system. It's a graveyard.
Why teams use them
NN/g list the benefits:
| Benefit | What it means in practice |
|---|---|
| Work can be created and replicated quickly, at scale | Teams reuse ready-made components instead of reinventing them |
| Designers can focus on harder problems | Less time adjusting buttons, more time on workflows and information priorities |
| A shared language across teams | Everyone means the same thing by "dropdown" or "primary button" |
| Visual consistency across products and departments | Screens look and behave like part of one product, and rebrands can be managed through the system |
| A reference for newer designers and content writers | Written guidance helps people learn the standards |
Why some teams don't
NN/g are honest about the costs:
- Creating and maintaining a design system is time-intensive and needs a dedicated team. It's never finished: good systems keep evolving based on feedback.
- It takes time to teach people to use it. Even a system adapted from an existing one needs instructions, or it'll be applied inconsistently.
- Some teams see their projects as one-off creations that don't need reusable parts.
For a student or a small startup, the lesson isn't "build a huge system". It's start small and reuse what already works.
What's inside a design system
NN/g describe the repository as usually containing three things:
1. Style guide
Guidelines and principles for things like brand (colours, typography, logos), content (tone of voice and language, like Module 7) and visual and interaction standards.
2. Component library
Reusable interface elements. NN/g say good component library entries include:
| Part | Example: primary button |
|---|---|
| Component name | Button / Primary, a unique name so designers and developers don't miscommunicate |
| Description | "The main action on a screen. Use once per screen." With do's and don'ts |
| Attributes | Size, label, icon, full-width or not |
| States | Enabled, pressed, focused, disabled, loading (lesson 8.1) |
| Code snippets | The code developers use to build it |
| Frameworks | The technology it's built for |
3. Pattern library
NN/g explain the difference: components are individual elements, while patterns are groups of elements or layouts, like a page header template, a sign-in form, or an error summary.
Learn from public design systems
Many organisations publish their design systems, and they're some of the best free UX education available. NN/g mention examples including:
- Google's Material Design, with a component library including implementation guidelines, code, and design do's and don'ts
- IBM's Carbon design system, with usage, style, code and accessibility guidance
- The US Web Design System, which specifies page templates, principles, components and code
You've also used the GOV.UK Design System throughout this course, for buttons, error messages and more.
When you study one, notice how each component explains when to use it, when not to, and why, backed by research. That's the standard to aim for.
You've already started building one
Look at what you've made in this course:
| Module | What you built | Design system part |
|---|---|---|
| 3 | Components and variants | Component library |
| 4 | A word list | Content style guide |
| 5 | A text field component with states | Component library |
| 6 | Spacing scale, type scale, palette, variables and styles | Style guide and tokens |
| 7 | Voice, tone and writing rules | Content style guide |
| 8 | State variants, snackbar rules, a motion spec | Components and patterns |
This module turns those pieces into something a team, and a developer, can actually use.
Document a component properly
Drawing a component isn't enough. Write down how to use it. A simple template:
| Section | What to write |
|---|---|
| Name | Snackbar |
| Use it for | Short, low-priority updates about something the app did, with at most one action |
| Don't use it for | Errors that block progress; important results like payments (use a result screen, lesson 8.2) |
| Anatomy | Container, text (up to 2 lines on phones), optional action |
| Variants | Without action; with action (e.g. Undo) |
| States and behaviour | Without action: disappears after a set time. With action: stays until acted on or dismissed |
| Content rules | Plain language; no icons or links; sentence case (lessons 7.2 and 8.2) |
| Accessibility | Announced as a status message; also show inline feedback where needed (WCAG 4.1.3) |
| Tokens used | color/surface/inverse, space/m, text/body |
| Code name | The name developers use, agreed with them |
Organise it in Figma, within your plan
From Module 6: on Figma's free Starter plan, you can create components, styles and variables, but publishing them to a team library needs an Education or paid plan.
So on Starter:
- Keep a dedicated Design system page in your project file, with your variables, text styles and documented components.
- Put a documentation frame beside each component, using the template above.
- Figma's help centre notes you can copy and paste variables into collections in another file, if you need them elsewhere.
On a paid or Education plan, teams usually keep the system in its own file and publish it as a library that other files use.
Governance: who can change what
Even a tiny system needs simple rules:
- Who can change a component or token.
- How to request a new component, like a comment or a short form.
- How changes are announced, like a short changelog: "15 Sept 2026: Primary button height changed from 44 to 48 to meet touch target guidance."
- When to create something new: only when an existing component genuinely can't do the job.
Common mistakes
| Mistake | Better |
|---|---|
| Treating a design system as a one-off project | Plan who maintains it, and keep improving it |
| Components with no written guidance | Document use, don't-use, states, content and accessibility |
| Creating a new component for every small difference | Reuse and extend existing components |
| A design-only system developers never see | Agree names and code with developers |
| Copying a public design system without adapting it | Learn from it, then adapt it to your users and product |
| No record of changes | A simple changelog |
| Building a huge system for a small product | Start with what you use most |
The short version
- NN/g: a design system is a complete set of standards to manage design at scale using reusable components and patterns, plus the people who manage it.
- Benefits: speed and scale, focus on harder problems, shared language, consistency, education. Costs: time, a dedicated team, and teaching.
- Parts: style guide, component library (name, description, attributes, states, code), pattern library.
- Learn from public systems like Material Design, Carbon, USWDS and GOV.UK.
- On Starter, keep your system on a Design system page in your file; publishing libraries needs an Education or paid plan. Add simple governance and a changelog.
Try it yourself
- Explore one public design system from this lesson. Pick one component, and write down how it explains when to use it, when not to, and why.
- Audit your project: count the different button styles, greys and spacing values actually used across your screens.
- Create a Design system page in your Figma file. Move your variables, text styles and components there.
- Document three components using the template in this lesson: a button, a text field and one more you use often.
- Document one pattern, such as your payment review screen or empty state.
- Write your system's governance rules in five lines or fewer, and start a changelog.
- Show your documented button to a developer or classmate, and ask: "Could you build this without asking me anything?" Fix whatever they ask about.
You'll know you've got it when anyone designing a new screen for your product could find the right component, know when to use it, and build a screen that looks like it belongs, without asking you.
More free previews
- ▶UX, UI, and why confusing them costs you20 min
- ▶Assumptions are not research: know what you actually know20 min
- ▶Set up Figma and draw your first screen20 min
- ▶Information architecture: why some apps feel obvious20 min
- ▶Design for the phone people actually own20 min
- ▶Spacing and the 8-point grid, used properly20 min
- ▶Why the words decide whether people finish15 min
- ▶Every screen has more than one state20 min
- ▶Why five users find most of the problems15 min
- ▶Choose a problem worth designing for20 min