A Design System for Your Website

What a design system is

A design system is a single source of truth for how your website looks and behaves — from the colour of a button to the logic of spacing and the behaviour of forms. The simplest way to picture it is as three connected layers — tokens, components and patterns — that describe an interface in a language both designers and developers understand.

It is worth separating a design system from a style guide or a UI kit. A style guide is a document of recommendations that quickly goes stale. A UI kit is a library of mockups in Figma. A design system connects those mockups to real code: the same definition of a colour or a button lives in both design and markup, so the gap between how something was drawn and how it was built shrinks dramatically.

Tokens, components and patterns

The three layers work like nesting dolls — from the smallest decisions to the largest.

• Tokens are named design values: colours, font sizes, spacing, corner radii, shadows, animation durations. Instead of a raw value like 'blue #1A6DFF', the team uses a token such as color-primary. Change the token in one place and the whole site updates.
• Components are interface building blocks assembled from tokens: buttons, input fields, cards, modals, navigation. Every component has states (default, hover, focus, disabled, error) and variants (primary, secondary, destructive).
• Patterns are stable ways to solve recurring tasks: how a sign-up form looks, how a product card is structured, how errors and empty states appear. Patterns are built from components and give predictable behaviour across every page.

On top of these layers there is always documentation: usage rules, do and do-not examples, and an explanation of why a particular decision was made.

Why it matters for business

A design system addresses four interconnected business needs.

• Consistency. The same element looks and behaves identically on every page. Users learn the site faster, and the brand feels coherent and trustworthy.
• Speed. A new page or section is assembled from ready components instead of being drawn and coded from scratch. What used to take a week starts taking days.
• Scale. When several designers and developers work on a project, the system keeps their styles from drifting apart. A new team member relies on documented rules rather than guessing.
• Cheaper changes. A rebrand, a new accent colour, updated typography — all of it is edited at the token level and rolls out across the whole site automatically, with no manual rework of hundreds of screens.

That last point is usually where the investment pays off: the longer a product lives, the more expensive every one-off change becomes without a system.

When you need one, when it is overkill

A design system is a tool, not a goal in itself. It does not always pay off, and an honest partner will say so directly.

A full design system is justified when the site is large and still growing; when several people work on it; when regular updates and new sections are planned; when there are several products or subdomains that must look unified; or when a rebrand or redesign is coming.

It is overkill when the project is a single landing page or a small brochure site of five to seven pages; when it is a one-off that will not evolve; or when budget and deadlines are tight and the goal is simply to get online quickly. In those cases a light set of styles and a few reusable blocks is enough — that is still a systematic approach, just in miniature.

The good news is that a system can be grown gradually: start with tokens and core components, then expand it as the project grows, without rebuilding everything at once.

What is inside a finished system

A finished design system is not one file but a set of artefacts kept in sync with each other.

• A library in a design tool. Usually Figma with variables, styles and components from which designers assemble new screens.
• A code component library. The same buttons and cards implemented in markup — in plain HTML/CSS or in whatever framework the project uses.
• A token file. A single source of values that feeds both design and code, ideally automatically.
• Documentation. Live component examples, usage rules, accessibility principles and the tone of the visual language.
• Accessibility rules. Contrast, tap-target sizes and keyboard behaviour — built into components rather than checked by hand every time.

The key word here is synchronisation. A system only pays off when design and code stay one whole rather than drifting apart a couple of months after launch.

How Ostohlo builds design systems

At Ostohlo we build design systems for the specific project rather than from a template. The process usually runs in several steps.

1. Audit. We review existing screens and find every repeated element and every inconsistency in colours, fonts and spacing. Often this step alone shows where the site is leaking.
2. Tokens and foundations. We define the palette, typography and the scale of spacing and radii, then formalise them as tokens.
3. Components. We build the core set — buttons, fields, cards, navigation — with all their states and variants.
4. Patterns and pages. We assemble typical screens from components and confirm the system covers real scenarios.
5. Documentation and handover. We describe the rules and train the client's team so the system lives on after launch.

We tie this process to our broader approach to interface design — more on it in the article on the UX/UI design process. If the system is needed to update an existing site, it is important not to lose ground — we covered that in our piece on redesigning without losing traffic.

Upkeep and common mistakes

A design system is easier to create than to maintain. We see a few typical mistakes that undo its value.

• A system in a vacuum. A beautiful component library nobody uses because it is detached from the product's real tasks.
• Design and code drift apart. One thing in Figma, another in the markup. Without a single token source this is almost inevitable.
• Excessive complexity. Dozens of button variants the team itself gets lost in. A good system is minimal and covers real, not hypothetical, cases.
• No owner. A system nobody is responsible for goes stale within a few months.

That is why we always build in update rules and agree on who makes changes and how. A design system is a living product, not a one-off artefact on a drive.

Where to start

If you are not sure whether your project needs a full design system or just a tidy set of styles, that is a fair question — and one best answered with concrete numbers and tasks rather than in the abstract.

Take a look at our services to see how we work, then get in touch — we will discuss your project, estimate the scope and propose a solution sized to the task, with no forced over-engineering.

FAQ