What each one is
A UI kit is a collection of interface pieces in a design tool: buttons, form fields, cards, icons, colors and type styles. Designers assemble screens from it, so that screens match. It lives in the design file and stops there.
A design system is the kit plus everything needed to keep design and product in agreement over time. The same components exist in code. Shared values such as colors and spacing are defined once and used by both design and development. Written guidance says when to use each piece, and a named person or team decides how it changes.
The two at a glance
| UI kit | Design system | |
|---|---|---|
| Contains | Components and styles in a design file | Design components, coded components, shared values, guidance and a process for change |
| Used by | Designers | Designers, developers, writers and testers |
| Keeps consistent | The designs | The designs and the shipped product |
| When something changes | The file is updated. Code is changed by hand, screen by screen | The component is updated once, and every screen that uses it follows |
| Accessibility | Depends on each screen's implementation | Built into the components and inherited everywhere |
| Owner | Whoever made the file | A named person or team, with time set aside |
| Cost | Low. Days to assemble or adapt | Significant to build, and continuing to maintain |
| Pays off when | One team, one product, near-term delivery | Several teams or products, or a long product life |
When each one fits
A UI kit is enough when
- One small team designs and builds one product
- You are making a first version and speed matters most
- The same people carry the conventions in their heads
- The interface has a limited number of screen types
- Nobody could be spared to maintain a system
A design system pays when
- Several teams or agencies work on the same product
- You run more than one product under one brand
- The built product no longer matches the designs
- The same button or form has been coded several times, differently
- Accessibility or rebranding must be applied everywhere at once
What a system adds to a kit
- Shared values. Colors, type sizes, spacing and radii are named once and referenced by design files and code alike, so a brand change is one edit.
- Coded components. Each element in the kit has a tested counterpart in the codebase, with the same names and options.
- Guidance. Short notes on when to use a component, when not to, and how it behaves on small screens and with assistive technology.
- Versioning. Changes are released in numbered versions, so teams know what changed and can adopt it deliberately.
- An owner. Someone reviews requests, decides what enters the system and retires what is no longer used.
The last item is the one most often missing. A system without an owner becomes a kit again within a year, only larger and less trusted.
Growing from a kit into a system
Few teams should begin with a full system. The practical route is to let it grow out of the product.
- 01
Start with a kit
Build the first version of the product from it.
- 02
Name the shared values
Move colors, type and spacing into variables used by both design and code.
- 03
Code the components once
As screens repeat, extract buttons, inputs and layouts into a shared library.
- 04
Write down the decisions
A paragraph per component, added when a question comes up twice.
- 05
Appoint an owner
When a second team or product arrives, give someone the job.
Open-source component libraries can supply the coded foundation, styled to your brand, which saves building every element from nothing. Our design systems development page covers how we approach it.
A worked example
A startup and an insurance company
Both companies are invented.
- The startupThree people are building the first version of a scheduling product. One designer, two developers, one web app.
- Its decisionA UI kit, with colors and spacing defined as variables from the start. A system would cost more than the confusion it prevents.
- The insurance companyRuns a customer portal, a broker portal and a mobile app, built by two internal teams and an agency. Each has its own buttons, forms and error messages.
- Its decisionA design system with a small owning team. A rebrand and an accessibility program were both planned, and each would otherwise be done three times.
The startup's consistency lives in three heads. The insurer's has to live in something everyone can use.
A checklist to decide
Tick what is true. With only the first three ticked, stay with a kit. Each tick among the last five strengthens the case for a system.
Kit or system
0 of 8 checkedWhat to do next
Open your product and count how many different buttons it contains. If the answer is the number you designed, a kit is serving you. If it is several times that, the cost of not having a system is already being paid in every release. Tell us what you find and we will suggest the smallest step that would fix it.
Common questions
Can we buy a design system instead of building one?
You can start from one. Open-source systems and component libraries provide well-tested, accessible components in code, and many have matching design files. Adapting one to your brand is far quicker than building from nothing. What you cannot buy is the part that makes it yours: the decisions about how your product behaves, and the ownership that keeps the system current.
Is a design system only for large companies?
It is for products with more than one team, more than one surface or a long life ahead, which often means larger companies but not always. A small company with a web app and a mobile app built by different people can benefit early. A large company with a single simple product may not need one. Count the teams and surfaces, not the employees.
Who should own a design system?
Someone with authority over both design and front-end code, and with time reserved for the job. In small organizations that can be one designer and one developer sharing it. In larger ones it is a dedicated team. Ownership by a committee that meets occasionally does not work, because requests wait and teams go around the system.
How do we know our UI kit is no longer enough?
The signs are practical. Developers ask which of several similar components is the right one. A color change takes days because it is hard-coded in many places. New screens look slightly different from old ones. Accessibility fixes have to be repeated screen by screen. When two or three of these are true, the time lost each month exceeds what a system would cost.
