Building Your First Design System
Overview
Going from a brand to a working design system is a skill almost nobody actually has. Brand designers stop at the identity. UI engineers start from a Figma file someone else handed them. The translation work in the middle (turning a logo, a hero colour, and a couple of brand values into a usable, scalable token system) sits in a gap that most teams never staff. This article is about what that skill consists of and why it is rarer than it should be.
1.A brand is not a design system
Most brands ship with a logo, one or two hero colours, a typeface, and a few photographs that capture the mood. That is enough to make a poster, a business card, or a homepage hero. It is nowhere near enough to build a product. The moment you need a disabled state for a button, a hover colour for a link, or a background tint for a selected row, the brand guidelines have nothing to say. You are on your own.
A design system is the layer that sits between the brand and the product. It takes the brand's raw material (colour, type, shape, tone) and expands it into a complete set of tokens that cover every UI surface you will ever ship. Primary, secondary, success, warning, error. Borders at three intensities. Backgrounds at four elevations. Type at seven sizes with matching line heights. Spacing on a rhythm. None of that is in the brand. All of it has to be derived from it.
That derivation is the skill. It is not visible in the final design system, which is why almost nobody talks about it. The output looks like a list of colours and sizes. The work that produced them looks like nothing.
2.Why the skill is rare
Brand designers are trained to think about identity, narrative, and visual mood. They work in Illustrator and on print proofs and they think about a brand as a held object. UI engineers are trained to think about state, components, and edge cases. They work in code and they think about a brand as a CSS variable. These are different jobs done by different people who rarely sit next to each other.
The work of translating between them belongs to neither role cleanly. It needs a brand designer's intuition for what feels like the brand, an engineer's discipline about state and consistency, and a systems thinker's ability to hold the whole token graph in their head at once. People with all three are uncommon. Teams that recognise the skill exists at all are uncommon.
The usual result is that the translation happens by accident. A frontend developer picks a hover colour that looks roughly right. A designer in Figma chooses a shade of grey that happens to be available. Six months later the product has eighty-seven slightly different greys and nobody remembers which one is the real one. The brand and the product have drifted, and nobody can point to the moment it happened.
3.What the skill actually consists of
The skill breaks down into three layers, each with its own way of going wrong.
Perception. The ability to look at a brand and identify what it is actually doing. Is the hero blue carrying weight because it is saturated, because it is dark, or because it is paired with a particular off-white? Which decisions are load-bearing and which are decorative? Most brands have two or three real moves and a lot of surface detail. Knowing the difference is the first thing.
Abstraction. Turning the perceived essence into a token graph. A brand has one primary blue. A design system has primary-50 through primary-900, plus a hover state, an active state, a disabled state, and a focus ring. The ratios between those shades, the way they relate to neutrals, the way they perform against the brand's background. None of that is in the original brand. It has to be invented in a way that feels inevitable once you see it.
Systems thinking. Holding the whole thing together as a graph rather than a list. A change to the primary hue has to cascade to every semantic colour that derives from it. A new typeface has to fit the existing rhythm of sizes. A new component has to compose from existing tokens or earn its right to introduce new ones. This is the part that decides whether the system survives its second year.
4.The shortcut that does not exist
There is a recurring hope that this work can be skipped. Pull the colours off the homepage, run a tool, get a design system. Dembrandt itself plays a role here: it extracts the raw tokens that live on a public website in seconds. That is real and useful. It collapses a tedious manual step into a single command.
What it does not do is the abstraction layer above. Extracted tokens are a starting point, not a finished system. They tell you what is currently on the site. They do not tell you what should be in the system, which shades are missing, which semantic roles need to be invented, or how the hover state of a button you have not built yet should relate to the primary you already have. That work still needs a person who can think across all three layers at once.
The shortcut is not from brand to design system. It is from manual extraction to automated extraction, which gives the person doing the abstraction work more time to do it well. The skill in the middle does not get automated. It gets unblocked.
5.Where to start, if you have never done this
Start by looking at a brand you admire and trying to reverse-engineer it. Pull the primary, find or derive the full scale, work out what the semantic colours should be, decide what the type scale is and why those sizes were chosen. Do this without looking at the brand's actual design system if one exists. Then compare. The gap between your version and theirs is exactly the shape of the skill you are trying to build.
Then do it again. And again. The pattern recognition only comes from repetition. After ten brands you start to see the same five or six structural moves underneath what look like very different visual identities. After thirty you can do the abstraction in your head while you are still looking at the homepage. That is the point where the skill stops being mysterious and starts being usable.
The reason almost nobody can take a brand and turn it into a working design system is that the work is invisible from both ends. From the brand side it looks like engineering. From the engineering side it looks like brand work. It is neither and both, and the people who do it well are usually the ones who got bored of staying inside one of the two boxes.
The tooling around this is finally getting good. Token extraction is automated. Token formats are converging on DTCG. AI assistants can generate UI from structured tokens. The bottleneck is no longer the plumbing. It is the small number of people who can look at a brand and see the system that should grow out of it. That part is still human work, and it is the work worth getting good at.
Related
Brand to Design System
The same hierarchy diagram - brand, design guidelines, design system, component library - tells completely different stories depending on who is reading it. A consultant, a developer, a visual designer, and a marketing lead all see a different centre of gravity.
Design & DevelopmentDESIGN.md
DESIGN.md is a readable hint, not a token. It works for prototypes and solo projects. Real design systems need structured, machine-readable token schemas that survive across tools, platforms, and team sizes.
Explorer
Design tokens extracted from well-known brands using Dembrandt.