Brand guidelines document

Why the document exists

Most brand guidelines are decks. A team files them in a shared drive after the launch meeting and never opens them again. Six months in, someone rebuilds the deck header because they cannot find the file, someone else picks a color from memory, and the identity drifts.

A working brand guidelines document is a reference, not a deliverable. It sits open on a second monitor. Designers, developers, marketers, and vendors all reach for it during production. This page is the template and methodology I use when a team asks for a guide that will still be in use twelve months after launch.

What separates a used guide from a shelf guide

Three properties do most of the work.

Everything a builder needs is one search away. Hex codes, RGB values, print codes, minimum sizes, clearspace values, font stacks, real SVG downloads. If a designer has to email someone for a hex code, the guide has failed.

The rules are shown, not narrated. A do-and-don't row is worth two paragraphs of principle. Every section carries a rendered example.

The guide reflects how the brand actually gets built. That means naming ratios and grids in the same units the team's tooling uses: rem in Tailwind projects, dp in Android, pt in native iOS, mm in print. A guide that specifies "8px baseline" for a team that builds in Figma auto-layout dies on contact.

The structure I ship

Seven sections in this order:

1. Mark. The logo, its clearspace, minimum sizes, approved variants, misuse examples.
2. Color. The palette in hex, RGB, HSL, CMYK, Pantone, plus contrast pairs.
3. Type. The ladder from display down to caption, with fallbacks and weights.
4. Layout. Grid, spacing scale, radius scale, elevation scale.
5. Voice. Descriptors, sample sentences, editing rules.
6. Application. Buttons, forms, cards, email header, social avatar, favicon, business card, invoice.
7. Governance. File locations, version history, how to request an update.

Sections one through four are the ones a designer opens. Five and seven are the ones a marketing lead opens. Six is where the two worlds meet.

Mark spec

Every mark section shows three things on one page: the clearspace envelope, the minimum sizes for the surfaces the brand actually ships to, and the approved color variants. Misuse examples live on the facing page. Every mark file lives in one canonical folder with SVG, PDF, PNG at three densities, and EPS for print vendors.

Color

The palette section names six to nine colors, no more. Each color has a full record: hex, RGB, HSL, CMYK for uncoated and coated stock, and the nearest Pantone. Contrast pairs live on the same page so a designer can see which foreground colors clear WCAG AA against each background without opening a separate tool.

Type

The type ladder is where guides most often over-engineer. Five to seven roles is enough: display, headline, subhead, body, small, caption. Every role names a family, weight, size, line height, and letter spacing. Fallbacks are listed in order. The web fallback is loaded before the primary in the CSS to avoid layout shift.

Layout

Layout sits between mark and application. The section names four scales, and everything downstream traces back to them.

• Grid. The number of columns at each breakpoint, the gutter width, the outer margin. Every layout in the wild traces back to this one grid.
• Spacing. A geometric progression from 4 up to 96, named in tokens (space-1 through space-9). Every padding, margin, and gap uses one of these values.
• Radius. Three or four values, named (radius-sm, radius-md, radius-lg, radius-full). Nothing uses a one-off radius.
• Elevation. Four shadow depths, each with the box-shadow value pre-tokenized. Buttons sit at elevation-1, cards at elevation-2, dialogs at elevation-3, floating menus at elevation-4.

Once the layout scales are named, arguments about "should this padding be 12 or 14" stop happening. There are only tokens.

Application rules

Application is where guides most often break down. A team ships eight rules for the logo and none for buttons, cards, or empty states. The guide I write covers each of these with a rendered example, the spec, and the file location of the source asset.

• Buttons. Primary, secondary, ghost, destructive, disabled. Padding, radius, focus ring.
• Forms. Field height, label position, error color, help text style.
• Cards. Shadow depth, radius, hover state, content padding.
• Email. Header lockup, footer legal, dark-mode variant.
• Social. Avatar safe zone, cover image dimensions per platform, story frame.
• Print collateral. Business card grid, letterhead margins, invoice header.

A brand guide that stops at the logo is a logo guide.

Every application page carries a do-and-don't row. Two rendered examples side by side, the correct one on the left with a green tick, the incorrect one on the right with a red cross and a one-line explanation of what went wrong. These rows do more teaching per square inch than any principle statement. Vendors and freelancers pattern-match against them without reading a single paragraph of guidance.

Voice

Voice is the section teams skip most often and lose most consistency around. I write it as three artifacts:

• Descriptors. Five to seven adjectives that name what the brand sounds like. Every descriptor is paired with what it does not mean. Warm does not mean casual. Precise does not mean clinical.
• Editing rules. Concrete constraints: sentence length ceilings, banned words, punctuation preferences, capitalization style, whether the brand uses em-dashes, whether it uses Oxford commas, how it treats numbers.
• Sample sentences. Twenty lines of copy already written in the voice, covering headers, product descriptions, error messages, transactional emails, and social captions.

Editors and vendors reach for the sample sentences first. That is why they live at the top of the section.

Governance

Every guide lives somewhere and dies somewhere. I ship:

• One canonical URL, versioned.
• A change log with dates and rationale for every visible change.
• A named owner. The person who approves changes and answers "can we use this like ___" questions.
• A quarterly review calendar entry.

Without governance, the guide gets forked. With it, drift shows up in a diff.

The named owner is the most important line in the section. Most guides die because nobody is willing to say no to a well-intentioned exception. The person named in this section is the one who says no, or who folds the exception into the next revision. Either outcome is fine. The failure mode is silence.