Building a Design System From Scratch

A design system is more than a colour palette and a logo. For a small team it needs to be usable, documented and light enough to actually maintain. The goal is not a beautiful library that sits in Figma. The goal is that every new page, screen or campaign looks like it belongs to the same brand, without anyone having to think too hard about it.

Here is how I approach building one from scratch, and the mistakes that make a system harder to use than having no system at all.

Start with decisions, not components

Before drawing a single button, make the big decisions and write them down:

• Personality. Three or four words that describe how the brand should feel. For my own site, that was “confident, technical, editorial, warm”.
• Colour strategy. How many colours, and what each is for. One accent colour used with discipline beats five colours used everywhere.
• Type pairing. A display face for headlines and a body face for reading. Two families is enough for almost any brand.
• Shape language. Sharp, soft or round corners. This one choice changes the feel of everything.

These decisions are what make a system distinctive. Components come later and inherit them.

Define tokens first

Tokens are the named values everything else is built from. Start with a small set:

Colour. A background, a surface for cards, a sunken surface, primary text, secondary text, muted text, one accent, an accent hover, and a border. Name them by role (--surface, --text-muted), not by appearance (--light-grey). Role-based names make dark mode possible later without renaming anything.

Typography. A type scale with clear steps: a display size, h1 to h4, body, small and an eyebrow style for labels. Set line heights and letter spacing per step, not per page.

Spacing. A scale based on a 4px or 8px unit: 4, 8, 12, 16, 24, 32, 48, 64, 96. Section padding should come from this scale, with explicit values for desktop, tablet and mobile.

Radius and shadow. Two or three radius values (for example 8px for inputs, 12px for cards, 20px for large panels) and two or three soft shadows. Keep them few.

Build the components that do the most work

For most teams, a handful of components cover the majority of screens:

1. Buttons, in primary, secondary and text variants, with hover, active and disabled states.
2. Form fields: input, textarea, select, with labels, help text and error states.
3. Cards for content, projects or products.
4. Badges and tags for status and categories.
5. Section headings: an eyebrow, a title and optional intro text.
6. Navigation: header, mobile menu and footer.

Get these right and consistent before adding anything else. Add new components only when a real page needs them, not because a design system “should” have tabs or tooltips.

Plan for dark mode from day one

If there is any chance you will want a dark theme, design your tokens for it now. Role-based colour names mean dark mode is mostly a matter of swapping values: the background becomes near-black, surfaces lift slightly, text inverts and the accent gets a touch brighter for contrast. Retrofitting dark mode onto hard-coded hex values is painful.

Document as you go

Documentation does not need to be long. For each token and component, write:

• What it is for.
• When to use it, and when not to.
• One good example.

A single page that says “use the accent colour only for primary actions, links and active states” will prevent more inconsistency than a hundred-page brand book nobody reads.

Connect it to how you build

A design system only matters if it shows up in the product. If you build in WordPress and Elementor, set the global colours and fonts in the site kit, define your spacing values, and use them everywhere instead of styling each widget by hand. If you build in code, put the tokens in CSS variables or a theme file that every component reads from.

When a brand colour changes, you should be able to change it in one place.

Mistakes to avoid

• Too many options. Six button styles and nine greys means people pick at random. Fewer choices, used consistently, look more premium.
• Building for an imaginary future. Design for the screens you actually have. Grow the system when real needs appear.
• No ownership. Someone needs to own the system and approve additions, or it fragments within months.
• Ignoring accessibility. Check colour contrast for text and buttons from the start. Fixing it later means touching every component.
• Desktop only. Define responsive behaviour for type and spacing, not just for layouts.

Start small, stay consistent

A good small-team design system can be built in days, not months. A clear set of decisions, a tight set of tokens, a handful of well-made components and a page of documentation will carry most teams a long way.

If you need a design system for your brand or product, or want your existing site brought in line with one, get in touch.