Your product team ships a new checkout step, and three versions of the same button appear in the pull request. Designers point to Figma. Engineers point to the code that already exists. If you are working out how to make a design system, the question behind it is usually simple. How do you get design and engineering to build from the same parts without slowing delivery?
The answer starts with how teams already work. A system that engineers adopt is built from real product patterns, mapped to code, documented where developers look, and owned by people with time to maintain it. That approach is why design systems for SaaS support growth: they cut rework and give users a consistent experience across every screen.
Audit What Exists Before You Build
Start with an inventory of the UI you already ship. Your product already contains a design system. It is just scattered, duplicated, and undocumented.
Where Are Teams Recreating the Same UI?
Take screenshots of every core flow, including signup, dashboards, settings, and checkout. Group them by pattern in a shared Figma board. You will find buttons, form fields, modals, and tables rebuilt by different squads.
Then check the codebase. Search your React repo for components that do the same job with different names, like PrimaryBtn, CTAButton, and ActionButton. A structured audit turns this messy inventory into a clear map of duplication.
Which Inconsistencies Affect Users or Slow Delivery?
Not every mismatch deserves attention. Focus on four kinds of problems:
- User-facing friction: error messages that look different on each form, or buttons that move between steps.
- Delivery drag: patterns engineers rebuild every sprint because no shared version exists.
- Brand drift: colors and type that no longer match your brand consistency standards.
- Accessibility gaps: low-contrast text or missing focus states repeated across screens.
A UX audit helps you rank which of these hurt conversion. That ranking keeps your first release focused on what users feel.
How Should You Set Scope and Measure Success?
Pick one product area for version one, such as onboarding or account settings. Define baseline numbers before you build. Track time to build a new screen, count of duplicate components, and defects tied to UI.
Pair delivery numbers with UX metrics like task success and form completion. With scope and baselines set, you can decide what every team should share.
Define the Foundations Teams Will Share
Foundations are the rules every component inherits: principles, tokens, and accessibility standards. Get these right, and components become faster to build and easier to trust.
Turn Brand and UX Goals into Design Principles
Design principles guide decisions when the docs run out. Write three to five that fit your product, like “Show the next step clearly” or “Density over decoration for power users.” Each one should settle a real argument.
Pull them from your brand guidelines and user research. If your brand story promises clarity, your principles should too.
Create Scalable Design Tokens for Color, Type, and Spacing
Design tokens store your visual decisions as named values that design and code both use. Build them in layers. Raw values like blue-600 sit at the base, and semantic tokens like color-action-primary sit on top.
Naming conventions decide whether tokens scale. The Figma team recommends semantic token names that reflect purpose, such as “color-warning” for alerts, so designers and developers share one vocabulary. Agree on a naming case with engineering early.
Cover these token groups first:
- Color palette: brand, neutral, and status colors, mapped to semantic roles.
- Typography: a type scale with set sizes, weights, and line heights.
- Spacing and layout: a spacing scale, such as 4px steps, plus layout grids.
A tool like Style Dictionary transforms one set of source tokens into platform outputs, such as CSS variables or iOS and Android formats. Keeping Figma variables and code in step takes more. You need a configured integration between Figma and your token source, plus a build workflow that publishes each change to both sides.
Set Accessibility Rules Before Components Spread
Bake accessibility into tokens so every component starts from accessible foundations. WCAG 2.2 sets a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text at Level AA. Test each color pairing against those numbers before you approve it.
Add rules for focus states, touch target size, and motion. Accessible tokens are a head start, not a guarantee. Each component still needs keyboard, screen reader, and interaction testing, and a check in the context where it is used. Once foundations exist, you can build parts people will reuse.
Build Reusable Components Around Real Product Needs
Build the components your product uses most, in the order users encounter them. A component library earns trust when it solves this sprint’s problem.
Prioritize Components by Frequency and User Impact
Use your audit data to score each pattern. Rate how often it appears and how much it affects key tasks. Buttons, inputs, and form validation usually win both scores.
A date picker used on one admin page can wait. A checkout form field used in every transaction cannot. This scoring puts user impact first and polish later.
Specify States, Variants, and Component Properties
Every component needs a full list of states before anyone writes code. A button has default, hover, focus, pressed, disabled, and loading states. Missing one creates a guess in production.
Align property names across Figma and code. Designers think in visual variants like size and color. Engineers think in behavior, like onClick and aria-label. Agree that size=”small” in Figma maps to size=”sm” in React, or pick one name for both.
Test Patterns in a Pilot Project Before Expanding the Library
Choose a live feature as your pilot project, like a new settings page. Build it only with system components and tokens. Log every gap, workaround, and complaint.
Treat it like a prototype: build a small version, learn fast, then expand. Fold pilot feedback into the next sprint so the pattern is tested before you scale it. Next, those tested parts need documentation engineers will read.
Make Documentation Work for Engineering Handoff
Put documentation where engineers already work, and connect it to the code they ship. A beautiful style guide nobody opens will not change behavior.
How to Make a Design System Work Across Figma and Code
Treat Figma and code as two views of one system. Publish a shared Figma library for designers. Mirror each component in React with matching names and properties.
Figma’s Code Connect links design components to real code, so developers see the right snippet in Dev Mode. On the code side, Storybook generates automatic component docs from your stories. You can extend those pages with MDX for full usage guidelines.
Document Usage Rules, Behavior, and Accessibility
Good docs answer the question an engineer has at 4 p.m. before a deploy. For each component, include:
- When to use it and when to pick another component
- Props, defaults, and allowed values
- Keyboard behavior and screen reader labels
- Do and don’t examples from your real product
Keep writing short. Some teams use generative AI to draft first-pass docs, then have a designer review for accuracy.
Keep Design and Implemented Components in Sync
Drift happens when Figma updates and code does not, or the reverse. Add visual regression tests with a tool like Chromatic on every pull request. Version your library with semantic versioning, and post changelogs in Slack. Keeping all this in sync takes people, which is where governance begins.
Plan for Adoption and Ongoing Governance
Assign named owners and clear rules before launch. Systems without owners tend to decay.
Assign Ownership Across Design, Engineering, and Product
A design system team can start small. For a narrow version one, that might mean a designer, a front-end engineer, and a product manager with part of their time set aside. The right staffing depends on scope, how many products and teams consume the system, and how fast adoption grows. Product management sets priorities so the system serves the roadmap.
Larger companies often fold this work into a cross-functional UX function.
Set Rules for Contributions, Releases, and Exceptions
Design system governance best practices come down to clear paths. Define how anyone proposes a new component, who reviews it, and how fast. A GitHub issue template with fields for use case, screenshots, and affected flows keeps requests focused.
Allow exceptions, but log them. If a squad keeps detaching the same component, say three times in a month, that often signals a missing variant. Release on a steady schedule, like every two weeks, so teams can plan upgrades.
Track Adoption and the Cost of Maintaining the System
Measure adoption with data from both tools. Figma library analytics show component usage in designs. A script that scans your repo shows the share of UI built from system imports.
Weigh adoption against cost. Track hours spent on maintenance and support each month. These numbers reveal whether you run the system like a product or store it like a file.
Frequently Asked Questions
What should a first version of a design system include?
Version one should include color, type, and spacing tokens, plus a small set of high-use components, for example five to ten, like buttons, inputs, and modals. Add short usage docs and accessibility rules for each. Leave rare patterns for later releases.
Can we build a design system from scratch without a dedicated team?
Often, yes, but someone must own it with protected time each sprint. How much time depends on the system’s scope and how many teams rely on it, so revisit staffing as adoption grows. Without assigned time, updates stall and teams drift back to one-off UI.
Should we start with a design system template or our existing product UI?
Start with your existing product UI in most cases. Your real patterns reflect real user needs and code that already works. A template helps with structure and naming, but it should not replace your audit.
How do we know when a component belongs in the system?
A common starting point is to add a component when several teams need it (three is a typical threshold) or when it appears in a critical user flow. One-off patterns can live in feature code until reuse appears. Review detach logs to spot candidates.
How often should design and engineering review the system?
A short sync every two weeks, aligned with your release cycle, is a good starting point. Add a deeper quarterly review of adoption, maintenance hours, and open requests. That rhythm catches drift before it spreads.
Treat the System as a Product, Not a File
Your engineers are the users of your design system. Building a design system succeeds when you research those users, ship to them, and measure whether they come back. A Figma file with perfect components still fails if developers keep writing their own buttons.
That shift changes the questions you ask. Stop asking whether the library is complete. Ask which team skipped it last sprint and why. The real answer to how to make a design system is an ongoing loop of audit, build, document, and govern, tied to baselines you set on day one.
If engineers keep rebuilding components your library already has, start with one recent feature. We can trace where the handoff broke and what your system needs next. Book a discovery call with millermedia7 to get started.
