A style guide for help docs

Open five articles in most knowledge bases and you can usually tell they were written by five different people. One says “sign in,” the next says “log in,” a third says “authenticate.” One uses numbered steps, another buries the same steps in a paragraph. Customers feel that friction even when they can’t name it.

A documentation style guide is the fix. It’s a single reference that spells out how your team writes help content: the voice, the formatting, the words you use (and the ones you don’t), and how every article is put together. Think of it as the rulebook that lets ten writers sound like one, and a core part of learning how to build a knowledge base that holds up as you scale.

This matters more than it sounds, because people barely read to begin with. A classic Nielsen Norman Group study found that 79% of users scan a page rather than read it word for word (Nielsen Norman Group). Consistency is what makes scanning work: when every article follows the same patterns, readers stop decoding your formatting and start finding answers faster.

What is a documentation style guide?

A documentation style guide is a living document that defines the rules for writing and formatting your help content. It covers the decisions that would otherwise get made (differently) by every writer, every time: how formal to sound, when to use a bulleted list, whether it’s “email” or “e-mail,” how to title an article.

You don’t need to invent all of this from scratch. Many teams start from an established base like the Google developer documentation style guide or the Microsoft Writing Style Guide, then layer their own product terms and voice on top. The goal isn’t a 200-page tome nobody reads, it’s a reference your team actually opens when they’re unsure.

What to include in a help center style guide

A useful style guide covers five areas. You can build it in this order, and even a rough first pass at each beats having none.

1. Voice and tone

Voice is your consistent personality; tone flexes with the situation. Write down three or four adjectives for your voice (“friendly, plain-spoken, never condescending”) and give writers concrete guidance on tone. A billing error article should read calm and reassuring; a getting-started guide can be warmer and more encouraging.

Spell out the practical rules too: address the reader as “you,” prefer active voice, and keep sentences short. Nielsen Norman Group found that writing concisely, scannably, and objectively improved measured usability by 124% (Nielsen Norman Group).

2. Formatting rules

Formatting is what makes an article scannable at a glance. Decide once how you handle headings, lists, bold text, links, images, and code, then apply it everywhere. Cover the small stuff that quietly drifts: sentence case vs title case for headings, numbered lists for sequential steps vs bullets for options, and how you write UI elements (for example, bolding button names like Save).

3. Terminology and a word list

A shared word list is the highest-value page in most style guides. It settles the “sign in vs log in” debates and locks in how you spell product features, so search actually works. List your preferred term, the variants to avoid, and any tricky product-specific vocabulary.

This is also where you draw important distinctions. A knowledge base and a help desk are not the same thing, and a word list keeps writers from blurring them in customer-facing copy.

4. Structure

Structure rules keep every article shaped the same way so readers learn the rhythm once. Define your standard anatomy: a descriptive title, a short intro that states what the reader will accomplish, the steps or explanation, and a “what’s next” pointer. The fastest way to enforce this is a reusable help article template that bakes the structure in before anyone types.

5. Accessibility

Accessible docs are better docs for everyone, so make the rules non-negotiable. Require descriptive alt text on every image, meaningful link text (“see the billing guide,” never “click here”), proper heading order that never skips a level, and captions or transcripts for video. Simpler writing helps readers with cognitive disabilities and non-native speakers alike, so a plain-language rule belongs here too.

A quick style guide cheat sheet

Here’s a starter you can copy and adapt. The point isn’t these exact rules, it’s writing your version down so the whole team shares one answer.

How to enforce a documentation style guide

A style guide nobody follows is just a nicely formatted opinion. Enforcement turns it into consistency, and it doesn’t have to be heavy-handed.

• Make it easy to find. Link it from your templates, your onboarding docs, and your editing tool so it’s one click away mid-write.
• Build it into review. Add a light checklist to your publishing process (voice, formatting, terminology, accessibility) and make style part of every edit, not an afterthought.
• Automate the boring parts. Tools like Vale can lint your terminology and phrasing rules automatically, catching “log in” or “click here” before a human reviewer ever sees the draft.
• Assign an owner. One person (or a small group) should own the guide, field questions, and update it as your product and team evolve.

The bottom line

A documentation style guide is the difference between a knowledge base that feels like one considered product and one that feels like a shared drive. Start small with your voice, a formatting section, and a word list, then grow it as questions come up. When you’re ready to put it into practice, you can create your knowledge base and write your first articles against the guide from day one.