What a design system actually is
Beyond a style guide and a component library, a design system records every decision about how a product or brand looks and behaves, so each is made once: which blue, how much space, what a disabled button does, how a headline scales from a phone to a billboard.
Systems usually have three layers:
- Foundations. Colour, type scale, spacing, grid, corner radius, shadow and motion timing, stored as named values (design tokens) so “primary” means the same thing in Figma, in code and in a campaign template.
- Components. Buttons, inputs, cards, navigation, modals, tables and charts, built from the foundations, with every size and state defined.
- Patterns and guidance. How components combine into forms, pages and flows, with rules for accessibility, writing and choosing between patterns.
What we build
Our Figma systems are complete enough to build from, a higher bar than looking good in a presentation. A typical one includes:
- A type system with sizes, weights, line heights and responsive behaviour, from display headlines to form labels.
- Buttons and controls in every size, variant and state: default, hover, focus, pressed, disabled, loading and destructive.
- Form elements with validation and error states, because forms are where products quietly break.
- Layout grids and spacing rules for phone, tablet and desktop.
- A colour system with contrast checked for accessibility, interactive states, and dark mode where needed.
- Iconography, illustration and image guidance.
- Data display: tables, charts, empty states and loading states.
- Marketing templates: campaign layouts, social formats, presentations and reports.
Components use variants and auto layout, and foundations are Figma variables, so the Figma system behaves like the code. App developers, platform teams and campaign designers should all find what they need without asking.
One source for design and code
A design system only earns its keep if what’s in Figma matches what ships. We map tokens and components to code, so designers and developers share one set of definitions and a colour changed once changes everywhere.
We document components in terms both sides use: the variants a designer picks, the properties a developer passes, the rules both follow. That shared vocabulary shortens reviews and ends a whole category of “that’s not what the design showed” conversations.
Design systems for AI tools
AI tools like Claude and Codex now write a growing share of front-end code and content. Where a system is silent, they invent: a slightly different blue, a new button style, spacing that drifts from screen to screen. With a team using AI daily, consistency can go in weeks.
So we build design systems for AI as well as people:
- Tokens exported in machine-readable formats coding tools can consume directly.
- Component documentation written as instructions: what each component is for, which properties it takes, and when not to use it.
- Constraints stated plainly, so a model chooses from approved options instead of guessing.
- Skills and project context files that point Claude, Codex and similar tools at the system, so generated code reaches for your components first.
This is what we mean by design is the spec: in an AI-assisted build, the design system is the standing instruction behind every screen. A clear one produces consistent work quickly; a vague one, drift.
How we build one
- Audit what exists: brand guidelines, the live product, marketing materials, and where they disagree. Organizations often have a system in pieces already; the job is separating real decisions from accidental ones.
- Build foundations first, then the components the product uses most, tested early in real screens where the awkward cases show up.
- Plan for who looks after it: an owner, a simple way to propose changes, and a version history. Without those, a system drifts back into one-offs.
We’d rather deliver a system that covers everyday cases than a perfect one that never gets finished. It grows as the product does.
When you need one
A single campaign or a small site can run happily on a style guide. A design system pays off when:
- Several people or teams build on the same product.
- The product will keep growing for years.
- Marketing and product need to look like one organization.
- AI tools produce a meaningful share of the work.
The more of these apply, the more a missing system costs in rework and slower teams.
