Style guide template

Most style guides are created once and used twice: the day they're written, and the day a new contractor joins and spends an hour hunting for the original. The format is usually the problem — a PDF in an email, or a Figma file nobody without a seat can open. A shared link with version history solves the distribution half. Anchored comments solve the feedback half — when a developer says "this font doesn't render on Android," that note lands on the typography rule, not in a Slack message nobody finds again.

Generate it with your agent

Paste this into Claude, Cursor, or any agent — it drafts the style guide and publishes it as a Drafty link your team can annotate inline:

See it on a real one

What goes in a style guide

Five sections. Two pages is a strong starting point; twenty pages is a reference manual. Start with what a designer needs to ship something correct on day one.

1. Logo — primary lockup, minimum size, clearspace, and what's never allowed (stretched, recolored, dropped on a busy background). Include the approved file formats and where to find them.
2. Color palette — primary and secondary colors with exact hex and RGB values. Note which combinations pass WCAG AA contrast. A designer guessing whether #E8D5FF is light enough on white costs you a revision.
3. Typography — headline and body typefaces, the size scale, and web fallback fonts. The most common omission: line-height and letter-spacing, which is what makes type feel right on screen.
4. Voice and tone — three to five adjectives, each with a concrete side-by-side. "Direct, not blunt" means nothing without: "We shipped v2" (direct) vs. "We are pleased to announce" (not). Examples are the section; adjectives are just the label.
5. Imagery — photography style (candid vs. posed, light vs. dark), illustration rules, icon library. A single mood board image is worth a paragraph of description.

The section most style guides get wrong

Voice and tone. It gets written as a list of adjectives — "bold, approachable, innovative" — with no examples, so every writer interprets it differently. The fix is one contrast pair per adjective: what it sounds like in practice, and what it's not. Two sentences. That's the whole section.

The other common miss: accessibility. Color contrast ratios for text on your primary backgrounds aren't optional — they belong in the color section, not in a separate a11y doc that nobody links to.

When to use a style guide vs. a design system

A style guide covers the rules — what your colors mean, how your brand sounds. A design system implements them in code and components. If you're a small team or a solo maker, start with a style guide. If engineers are shipping React components, you probably need both, and the style guide feeds the design system's tokens.

If you're choosing between Drafty and Figma: Figma's brand kit is genuinely better for component-level design tokens and live design handoff. Use Drafty when you need to share the guide with people who don't have Figma seats — a client, a copywriter, a contractor — and collect their feedback in one place.

FAQ

What should a style guide include?

At minimum: logo rules, color palette with exact values, typography (typefaces + size scale), and voice/tone with examples. Imagery and iconography guidelines come next. A five-section guide your team reads is worth more than a thirty-page document that lives in a Dropbox nobody bookmarks.

What's the difference between a style guide and brand guidelines?

They're often used interchangeably. Brand guidelines usually go further — covering strategy, positioning, and personality before the visual rules. A style guide is the visual and verbal ruleset alone. Start with a style guide for day-to-day reference; build out brand guidelines when you're onboarding agencies or licensing your identity.

How long should a style guide be?

As short as it can be while still answering "can I do this?" for the decisions that come up most often. Two to five pages covers most teams. Length creep happens when sections are written to be comprehensive rather than useful.

How do I share a style guide with my team so they actually use it?

A link beats a file attachment. A link that opens without a login beats one that doesn't. The guides that get used are pinned in Slack, linked in the repo README, shared as a URL — not buried in a Figma file or a Google Drive folder half the team can't open.

What's the difference between a style guide and a design system?

A style guide documents the rules. A design system implements them — your Tailwind config, your CSS variables, your component library. The doc that explains why you chose those values is the style guide; what enforces them in code is the design system. Teams that only have one usually wish they had both.

Can I use this template for a client handoff?

Yes. Fill in the sections with your agent, share the Drafty link with the client, and let them comment inline on the exact rule they want to revisit — rather than getting a PDF back with tracked changes and email threads. When the feedback is addressed, your agent pushes a new version to the same URL, so the client always has the current one.