The conversation usually starts the same way. A technical founder shows us a Storybook instance, a Figma library with tokens linked to a Tailwind config, and says — with justifiable pride — “we already have a design system.”
What they have is a design system. What they do not have is a brand system. The first is real and useful. The second is what they actually need, and what is missing is hidden by the apparent completeness of the first.
What each system actually contains.
A design system is, at its core, a contract between designers and engineers. It contains: tokens (color, spacing, type scale) expressed as variables, components (buttons, cards, forms) implemented in code, accessibility rules, state specifications, and a documentation site that engineers reference while building.
A design system answers the question: given a decision about what to build, how do we build it consistently? It is downstream of strategy. It is excellent at preventing two engineers from picking different shades of blue. It is silent on the question of which blue, or whether the brand should be talking about blue at all.
A brand system, by contrast, contains: a strategic posture, a voice and lexicon, applications across non-product channels (signage, print, sales materials, event presence), governance apparatus (Council, Two-Gate, Audit), and a Master Book that documents all of the above. It answers a different question: what does this brand mean, and how does that meaning manifest everywhere it touches the world?
The design system is a subset of the brand system’s Visual chapter, rendered for engineering. It is the smallest of the brand system’s outputs. In most companies it is the only one that exists.
The handoff that breaks.
Even when both systems exist, the handoff between them is where most companies lose coherence.
The brand team ratifies a new tone descriptor at a Council. The design system has no place to put it. The token library does not include “tone.” Six weeks later, an engineer is writing copy for an empty state and the voice guidance is not in the place they look. They write what feels right. It drifts.
A design system is downstream of strategy. Tokens cannot tell you what your brand means — and most companies have stopped asking.
Or the reverse: the design system updates a button radius for accessibility reasons. The change ships in production. The brand book still references the old radius in its Components & Applications chapter. Sales decks built off the brand book are now off-standard. The two systems have diverged because no one owns the handshake between them.
The handshake is the Steward’s job. In a healthy installation, every design system change goes through Gate 2 if it touches anything in the brand-visible surface. Every brand-side ratification on visual rules gets reflected in tokens within one sprint. The two systems stay in lockstep because a single human pair owns the diff.
The org-chart problem.
The deeper reason the systems drift is structural. The design system is owned by Engineering or Design Engineering. The brand lives in Marketing, or the founder’s office, or nowhere. They are two different reporting lines, two different review cadences, two different vocabularies.
In tech-led companies the design system reports up; the brand reports nowhere. The CTO sponsors the design system because it has a clear engineering velocity case. The brand has no equivalent sponsor, because brand drift is invisible inside one fiscal year and the cost of fixing it doesn’t show up on an engineering metric.
The fix is not to merge the teams. It is to put the Brand Steward at the seam between them, with explicit authority over the brand-visible portion of the token library, and a reporting line to the Brand Owner — not to the design system maintainer.
How they connect when done right.
In a healthy two-system installation, three connections are written down explicitly.
Token sovereignty. The brand book is upstream of the token file. Color names, type roles, and spacing tokens are ratified at Brand Council and synced into the design system within one sprint. The design system is the implementation; the book is the specification.
Component compliance. Every new design system component is reviewed against the brand book’s Visual chapter at Gate 2 before it merges into the library. A component that violates voice or hierarchy never reaches production.
Cross-channel parity. The brand book’s Components & Applications chapter covers non-product channels (deck, signage, print) using the same tokens. A buyer who sees the website and then the sales deck experiences one brand because both surfaces drew from the same upstream specification.
Done this way, the two systems compound. Done the other way — design system without brand system upstream — the company ends up with the most beautifully implemented version of a brand it has not yet decided.
The brand system is what The Brand Operating System installs. The design system is one of its downstream outputs — not its replacement.
