In this guide 6 sections
A style guide fixes colours, type and tone. A UI kit adds drawn components in a design file. A design system adds coded components, states and rules for use. A platform with four modules and several developers needs the design system, started small with the dozen components used on every screen.
What a style guide fixes and what it leaves open
A style guide is a short document. It names the brand colours, the typeface, the heading sizes, the logo clearances and the tone for button labels and error messages. Nothing in it is clickable, and nothing in it is code.
It answers one question well: does this screen look like us? It cannot say how a date picker behaves when the field is empty, or what a disabled button should look like. Those gaps get filled by whoever is building that week. Hence the drift.
- Colour values with names, such as primary, danger and muted
- Typeface, weights and a size scale for headings and body text
- Logo placement and minimum size
- Voice rules for labels, empty states and error text
A UI kit gives designers parts to draw with
A UI kit is a library inside Figma or Sketch. It holds drawn buttons, inputs, tables, tabs and modals, each as a reusable component with variants. Designers drag them onto a frame instead of redrawing a dropdown every time.
The catch is that drawings are not software. A developer still has to build each part, and nothing forces the built version to match the drawn one, so the two slide apart. Six months on, the kit shows a six pixel corner radius while the product ships with four.
A kit suits a small team with one designer and one front end developer sitting close together. Then a second squad joins. The kit starts to fail.
What a design system adds on top
A design system keeps the style guide and the UI kit, then adds the coded components. A Button in Figma maps to a Button in the React or Angular library, with the same name, props and states, published as a package that every module installs.
It also records rules. When to use a modal and when a side panel. How a table behaves with five thousand rows. Which icon means delete, and what the confirmation text says. Short rules, written beside a live example.
- Coded components with hover, focus, disabled, loading and error states
- Design tokens for colour, spacing and type, shared by the design file and the code
- Usage notes that say when to use a part and when not to
- Accessibility notes such as focus order and contrast
- A change log and a named owner who approves additions
Which one a platform with four modules needs
Take a platform with orders, inventory, billing and reporting, each built by a different person under a different deadline, with its own copy of the stylesheet. You already have four button styles and three date formats. A style guide alone will not fix that. The problem lives in the code.
You need a design system, but a thin one. Start with the pieces used on every screen: button, text input, select, date picker, table, tab, modal, toast, badge, form row, page header and empty state. Ship those as a package before adding anything rare. Rare can wait.
Treat the style guide and the UI kit as the first two layers of that work, not separate projects. They cost little, and the tokens carry straight into code.
How to start without a long programme
Print the main screen of each module and pin them side by side. Circle every difference in button, spacing and wording. That wall of circles is your business case. It takes an afternoon.
Pick one module as the source of truth, rebuild its components in the library, then move the other three over one release at a time. Do not restyle everything at once. Nobody can test that.
This week, print one screen from each module and circle the differences.
Component audit sheet
A worksheet, one row per component. Columns cover module, screenshot, number of variants found, chosen standard, owner and the release that migrates it. A second tab lists tokens for colour, spacing, type size and corner radius, with the value in the design file beside the value in code.
Open a blank worksheet to printQuestions owners ask
Can we have a design system without a UI kit?
Yes, but designers then redraw parts from scratch, and drift returns on the design side. Most teams keep both. The kit is the drawn mirror of the coded library, and the two share the same tokens.
Who should own a design system?
One named person, usually a front end lead or a product designer, who approves additions and retires duplicates. Without an owner, the library gathers near copies of every component and stops being trusted.
Is a design system too heavy for a small product?
A full one is. A thin one is not. Twelve shared components, a token file and a one page usage note cost little and prevent the mismatch that appears when a second developer joins.