Building a brand system you can actually reuse
- Brand System, Branding, Design, UI
Most brand guidelines die in a PDF.
You’ve probably seen one. Forty pages, a logo safe-zone diagram, three pages of “our tone of voice is bold yet approachable,” and a colour swatch page with hex codes nobody ever types correctly. It looks impressive in the kickoff meeting. Six months later the website, the pitch deck and the Instagram grid all look like they came from three different companies.
The problem isn’t that the guidelines were wrong. It’s that they were written to be read instead of used.
A brand system is different. It’s a small set of decisions, named in a way that makes them findable, that you and anyone else working on the brand can pick up and apply without asking permission. In 2026, with muted minimalism giving way to bolder, more expressive visual identities — saturated colour, distinctive type, repeatable signature UI patterns — having a system matters more, not less. Bold only works when it’s consistent. Otherwise it’s just loud.
Here’s how I build one. I’ll use QuickForge, my own studio, as the running example, because it’s the system I know best and the one I can show you honestly — including the parts that were awkward to solve.
Start with two colours, not twelve
QuickForge runs on exactly two colours that matter: #3eff8b, an aggressive electric green, and #050517, a near-black with a blue undertone. Everything else — white, #4d4d4d, #888888 — is supporting cast.
That ratio is deliberate. When people build a palette they tend to pick five or six colours they like and then discover in month two that they have no idea which one is the button. A system needs a hierarchy, not a mood board.
So the first pass isn’t “what colours do we like.” It’s:
- One role that means act now. Buttons, links, the thing your eye should land on. Note that this is a role, not a fixed swatch — which colour fills it depends on what the background needs for contrast. QuickForge uses the green on dark surfaces and the near-black on light ones. Readability outranks aesthetics: if the prettier option can’t be read, it isn’t the option.
- One colour that carries everything else. Backgrounds, body text, the substrate the brand sits on. That’s the near-black.
- A neutral ramp. Two or three greys for secondary text, borders and disabled states.
Two decisions. Then you check the maths, because a colour that fails contrast isn’t a brand decision, it’s a bug.
Green on near-black comes out at 15.3:1. White on near-black is 20.2:1. Both are comfortably past the WCAG AA threshold of 4.5:1 for body text. But green on white is 1.32:1 — effectively invisible. That’s a genuinely useful constraint to discover early rather than in QA: it means QuickForge’s green is a dark-mode colour. On light backgrounds it can only appear as a fill behind dark text, never as text itself.
That single finding shapes the whole system. It’s the difference between a palette and a set of rules.
Name things by intent, not appearance
This is the step most people skip, and it’s the one that determines whether the system survives contact with a second person.
The instinct is to name your colours after what they look like: green, dark-blue, grey-2. It works until the day you rebrand, or you add a dark mode, or a client says the green feels too aggressive on the pricing page. Now you have a variable called green that is orange, and everyone downstream is confused.
The current practice — and it’s become the default in serious design systems — is intent-based naming: roughly [context]-[subject]-[state]. You describe the job, not the pixel.
For QuickForge that looks like:
surface-base #050517
surface-raised lightened base
text-primary #ffffff
text-secondary #888888
action-primary #3eff8b on dark, #050517 on light
action-primary-hover one step down in saturation
border-subtle #4d4d4d
Now action-primary can become any colour on earth and nothing breaks. The name describes a role in the interface, and roles are stable even when taste isn’t. This is also the layer that lets a tool like Style Dictionary export the same source of truth to CSS variables, a Figma library and native app code without drift — but even if you never automate any of that, the naming alone pays for itself the first time someone else touches the file.
Practical tip: write the token list in a plain text file before you touch Figma. If you can’t name it in words, you don’t understand the decision yet.
Build a type scale, not a font list
“Headings are Inter Bold, body is Inter Regular” is not a type system. It tells you nothing about the relationship between a page title and a section title, which is the actual question you’ll face forty times a week.
A scale is a fixed set of steps, and you only ever use steps from the set. Pick a base size — 16px is sensible for body text — and a ratio. I use 1.25 (major third) for most work; it gives enough separation to be clear without the jumps getting cartoonish.
display 48px / 1.1 weight 700
h1 38px / 1.2 weight 700
h2 30px / 1.25 weight 600
h3 24px / 1.3 weight 600
body-lg 20px / 1.5 weight 400
body 16px / 1.6 weight 400
caption 13px / 1.4 weight 400
Seven steps. That’s the entire vocabulary. The value isn’t the specific numbers — it’s that when you’re designing a new page at 11pm and you need “something between a heading and body text,” the answer already exists and you don’t invent an off-scale 22px that nobody can reproduce.
Same logic for spacing. Pick a base unit — 4px or 8px — and only use multiples. QuickForge uses 8px: 8, 16, 24, 32, 48, 64, 96. Every gap, every padding value, every margin comes from that list. It sounds restrictive. In practice it removes about a hundred micro-decisions per project and the layouts come out visibly tighter.
Make three components, then stop
Here’s where most small teams over-invest. You do not need a component library. You need the three or four patterns that appear on every single page, built properly.
For a studio site or a product marketing site, that’s realistically:
- Button — primary, secondary, and a disabled state. Three variants, not twelve.
- Card — the container that holds a project, a service, a testimonial. One card, flexible contents.
- Section wrapper — the thing that controls max-width, vertical rhythm and background colour. Boring, invisible, and the single biggest driver of whether a site feels coherent.
Build those with your tokens wired in, and roughly eighty percent of any new page assembles itself. Everything beyond those three should be built when a real page needs it, not in advance. Speculative components are the design equivalent of dead code.
Write down the rules that aren't visual
The last piece is a short document — one page, not forty — covering the decisions that don’t show up in a Figma file:
- When do we use the accent colour, and when is it too much? (QuickForge rule: one primary action per screen. If everything is green, nothing is.)
- What’s our motion budget? (Under 200ms for state changes, no animation that blocks interaction.)
- What’s the fallback when an image doesn’t load, when text is three times longer than the mockup, when the user has reduced-motion enabled?
These are the questions that get answered inconsistently by whoever happens to be working that day. Answering them once, in writing, is what turns a set of files into a system.
The actual test
Here’s how you know it worked. Hand the system to someone who wasn’t in any of the meetings, and ask them to build a page you never designed.
If they can do it, and the result looks like it belongs, you have a brand system. If they have to ask you four questions first, you have a mood board with extra steps.
That’s the whole difference — and it’s the difference between a brand that scales with your business and one you have to rebuild every eighteen months.
I’m Jean-Luc Marengo, designer and co-founder at QuickForge Studio. We build brand and web design systems for companies that are tired of starting over.