Consider a design system when your team repeatedly redecides buttons, inputs and error handling for the same tasks. Team size and screen count matter less than recurring decisions and the capacity to maintain shared rules. If user flows are still changing quickly, start with one core workflow rather than a complete library.
[01]How is a design system different from a Figma library?
A Figma library distributes reusable visual elements. Delivering the same behavior in a product also requires code, usage guidance, error and loading states, and a change process. IBM Carbon describes a system encompassing code, design resources, interface guidance and a community of contributors.
Your first deliverable need not be a large catalogue. Start by agreeing when an input component is appropriate, how to import it and how it communicates failure, so designers and engineers can explain the same rules.
[02]Should you invest now or wait?
The following is BOYD's suggested decision framework, not a mandatory team-size or screen-count threshold. Look at recent changes and identify problems that actually repeated.
| Situation | Suggested response |
|---|---|
| The same inputs or buttons behave differently across screens | Align recurring components, states and usage rules |
| Several contributors maintain separate versions of the same UI | Share code and name a change owner |
| The core user journey changes frequently | Standardize validated flows and keep experiments flexible |
| A one-off campaign has no continuing product work | Prioritize a compact style guide and acceptance checks |
[03]What belongs in the first version?
USWDS describes incremental adoption of principles, guidance and code. Design tokens name recurring values such as color, spacing and typography. For a small team, we suggest applying that approach to one recurring workflow and the minimum rules it needs.
- Foundations: name text, surface and error colors, type scales, spacing and radii by purpose; for example, color.text.error.
- Components: align design and code names for the buttons, fields and selection controls the chosen flow actually needs.
- States and rules: document applicable default, focus, error, loading and disabled states, plus when to use them.
- Maintenance: record where changes are requested, who reviews them, the version and the products using it.
[04]How do you apply it to one real flow?
Consider an illustrative quote-request form. Map the journey from entering a name, email and request to successful submission. Include missing required fields, invalid email, pending submission, server failure and retry. This is a hypothetical implementation example.
- Collect existing field variants and check which differences serve a real task. Standardize only unnecessary differences.
- Apply the shared input to one real form and update both design guidance and a working code example.
- Check whether users understand and correct errors, then resubmit. Test the flow using a keyboard as well.
- Record differences when applying it to another form. Decide whether each is a valid new requirement or already covered before expanding.
[05]Does visual consistency solve accessibility?
Visual consistency does not guarantee accessibility. W3C's guidance on consistent identification concerns recognizing components with the same functionality across pages. It focuses on predictable identification, rather than forcing every label to be identical.
Check keyboard navigation, visible focus, input labels, error communication and contrast in the actual product context. These checks alone do not establish full WCAG conformance. GOV.UK's contribution criteria likewise emphasize usefulness, usability, consistency, versatility and supporting evidence.
[06]Who maintains it, and what should they track?
A new component proposal should explain a recurring user problem, why existing components cannot solve it and where it will be used. An owner reviews the proposal and tracks adoption. Resolve divergence between working code and design resources before adding more elements.
Assess recurring rework and exception requests rather than library size alone. Track which screens use shared forms, why separate implementations remain and which issues recur after fixes. Use your team's change history to evaluate results instead of promising a percentage productivity gain.
[07]Five checks before you begin
- Have you identified a recurring problem and a first workflow?
- Are the owners of design resources and working code involved?
- Do acceptance checks cover errors, loading and keyboard use?
- Have you separated shared rules from ongoing experiments?
- Is someone responsible for change requests, review, release and adoption?
If these questions are hard to answer, collect current screens and recent change examples first. When planning a new product or website update, agree with engineering on reusable workflows and handover assets before replacing every screen.
- Design systems
- UX
- Components
