Starting a design system from scratch: where to begin
A design system does not start with a library of 80 components. It starts with an honest inventory of what exists, a few decisions, and a first component that is actually used. Here is the order that works, from startups to large companies.
Do you need a design system?
Not necessarily right away. A design system takes time to build and maintain. It pays off when the same interface is built by several people, across several products, or over a long time.
- Several designers or development teams work on the same product.
- You have several products, or a website and an app, that should look alike.
- Every new page takes time because of decisions already made elsewhere.
- A rebrand is coming, and you already know it will take months to spread.
Start with an audit
Before designing anything, inventory what exists: screenshots of the buttons, fields, cards, colours and radii actually in use. On this site, the audit found thirteen different corner radii and twenty hand-written colours.
The audit does two things: it tells you what to keep, and it convinces. A board with fifteen different buttons does more for a design system budget than a slide deck.
Foundations before components
Foundations are design tokens: colours, typography, spacing, radii, shadows, motion. They make components consistent with each other. Organise them in three tiers (reference, system, component) from day one: it is what lets you add a dark theme or a second brand without starting over.
The first components
- The button: variants, sizes, states. The most used component, and the one that reveals the most drift.
- The form field: label, help, error, disabled.
- Card, badge, link: the building blocks of most pages.
- Layout: grid, containers, vertical rhythm.
Clear naming from the start avoids painful renames. BEM (block, element, modifier) works well in code: .ds-button, .ds-button__icon, .ds-button--primary.
Document as you go
Documentation is not a final phase. Every released component comes with what it is for, when not to use it, and a live example. A changelog tells everyone what changed.
Minimal governance
- Who decides: one person or a small team, even if everyone can propose.
- How to contribute: a short written process.
- How to release: numbered versions, a changelog, and a rule for breaking changes.
Measure, even a little
Three numbers are enough: the share of screens using the system, the number of components rebuilt by hand, and designer and developer satisfaction. Measured each quarter, they tell you where to put the effort.
Costly mistakes
- Building in isolation for six months, then “launching” a system nobody asked for.
- Copying a big company’s design system instead of starting from your own needs.
- Building in Figma without wiring it to code, or the other way round.
- Planning nobody to maintain it after launch.
I build design systems and get them adopted, from audit to governance. If you want to know where to start in your team, a scoping call is enough.