Most brand guidelines are written for a marketing team and handed to an engineering team as an afterthought — a PDF full of Pantone codes, logo clear-space rules and a mood board, with no answer to the question an engineer actually has: what's the hex code for the disabled button state?
Design tokens, not just guidelines
A brand system that survives contact with a real product is expressed as design tokens from the start — named, structured values for colour, spacing, type and elevation that live in code as naturally as they live in a design file. When 'brand red' is a token, not a swatch someone eyeballs, it can't quietly drift across a dozen different screens built by a dozen different people over two years.
Design the states, not just the screens
- Hover, focus, active and disabled — for every interactive element, not just the primary button.
- Empty, loading and error states — the states a real product spends a surprising amount of its life in.
- Dark and light contexts, if either is even a possibility down the line.
- Responsive behaviour — how the identity holds up at 375px wide, not just on a 1440px mockup.
A brand identity that only exists at one breakpoint, in one state, isn't finished — it's a preview of the parts that are hardest to design and easiest to skip.
Build it as a shared system, not two silos
The brand identity and the product's component library should be the same system described twice, not two systems that get reconciled after the fact. When brand and product design happen in the same room — or on the same team — the identity ships with the constraints of the real interface already built in, instead of being redesigned around them six months after launch.
The test we use: hand the documentation to an engineer who wasn't in any of the brand meetings. If they can build a new screen that feels unmistakably on-brand without asking a designer a single question, the system is actually finished. If they can't, the brand book is still just a PDF.