A brandbook is not one document written in one pass — it's a checklist assembled from three inputs you cross-reference against each other: the brand assets that already exist in your codebase, the most mature example you already have somewhere in your own history, and an external industry-standard structure. Skip any one of the three and you'll ship something that's either incomplete (missing a section every other example has) or invented (a section nobody actually needed). Structure it as an escalating checklist with a one-page summary at the very top, not as a single essay — most people who touch it will only ever read the one-pager.
The seven sections almost every brandbook needs
Cross-referencing multiple structures (an external industry-standard breakdown, a generic guideline template, and the most complete internal example available) converges on the same seven building blocks, in this order:
- Brand foundation — problem, mission, vision, values, positioning. This is the "why" everything else derives from. Skip this and your color choices have no justification when someone asks "why blue."
- Logo system — concept, versions (icon/wordmark/favicon/app-icon), clear space, minimum sizes, approved backgrounds, explicit "don't" list.
- Color palette — primary + semantic + text colors, with hex/RGB, usage rules, and an accessibility table.
- Typography — font choices per platform/context, a real type scale (sizes, weights, line-heights), not just "we use Inter."
- Photography / imagery direction (or, if your product has no photography — an equivalent visual-style section: iconography, illustration, or in our case, UI component style).
- Voice & tone — persona, traits, a dictionary of preferred/avoided words, and side-by-side examples (wrong phrasing vs right phrasing) per context.
- Application rules — where the voice and visuals actually show up. This is the section most templates get generically wrong, because they assume every brand has the same channels (social media, print, email). Yours might not. Figure out your actual channels first, then document each one — don't copy a channel list from a template that assumes a different kind of product.
[Verified] — this seven-item skeleton is consistent across an external industry-standard source, a generic five-section template, and a fully-built internal example; the internal example additionally had two more sections (accessibility as its own space, and governance) that the generic sources didn't call out explicitly. Treat those as commonly-missing, not optional.
Don't trust one list — cross-reference at least two
The single biggest mistake to avoid: picking one structure (a template, or one good example you found) and copying its table of contents verbatim. A generic template and a real mature example will disagree on emphasis — a generic template treats accessibility as a bullet point inside the color section; a real example that actually shipped a product for an accessibility-sensitive audience treats it as its own numbered section with a dedicated contrast table. If you only read the generic template, you'd miss that accessibility deserves its own space. If you only copied the mature example, you might inherit sections that don't apply to your product (a component library section makes no sense if you don't ship UI at all).
The fix is mechanical: list the sections from every source you can find (at least one external structure, at least one internal example if you have one), put them side by side, and only remove a section if you can articulate why your specific product doesn't need it — not because it wasn't on the list you happened to read first.