Style Guide Development

Everyone talks about “brand voice,” but few teams actually document it. That’s why I wrote a full guide on how to create a content style guide that actually works, including examples from 16 companies that nailed it. From Mailchimp to Intuit to Monzo, you’ll see how the best brands standardize their voice, tone, and microcopy patterns so every message feels aligned — even across thousands of writers, designers, and marketers. In the article, I explain what a content style guide really is (and what it’s not), the common mistakes that kill consistency, and four practical tips for creating a guide your whole organization will actually use. You’ll also find 16 of the best examples from tech, finance, and government to help you build your own. If you’re building or updating your brand’s content system this quarter, this one’s a must-read. Link to the full guide in the comments.

Your style guide is an essential part of your content toolkit. I’d like to see more style guide owners and creators think about the usability of this document. Many favour the A to Z format. This makes sense if you’re looking up a word (like ‘focused’ - is it one s or two?). But it doesn’t really make sense for something like ‘dangling participle’. Or words to avoid. Style guide users won’t be looking for these things in an A to Z. If they already know about dangling participles, they’ll already know to avoid them. And if there are certain words your organisation likes to avoid, people won’t know this until they’ve found it in the style guide. What about common questions like Oxford commas, dates and en rules? For me, the A to Z format doesn’t really work here either. Do I look under O for ‘Oxford comma’, C for ‘comma’ or P for ‘punctuation’? OK, you can cross-reference. But this is adding cognitive load for the user. Here’s the format I prefer. 1. Summarise the main style guidelines. Have categories for: - spelling and hyphenation - punctuation - capitalisation - numbers - references (if relevant) The goal here is a brief summary of the main style rules, such as ‘No Oxford comma’ or ‘Headings take sentence case’. Someone can scan over this list and quickly get the overall gist of your house style. 2. List separately your words to avoid. People won’t look up a word if they don’t already know it’s something to avoid! So l keep a separate list. Then someone can scan over the list and quickly get a sense of the words they need to approach with caution when writing for your organisation. 3. A to Z word list. This is the reference part of your style guide. People can look up ‘yoghurt/yogurt’, ‘focused/focussed’, industry-specific terms and names of schemes, organisations or people you write about a lot. Reserve the A to Z format for things that people might actually look up. What do you think? #EditorialStyle #Editing #StyleGuideUsability #HouseStyle #ContentEditing

𝗧𝗵𝗲 𝗯𝗶𝗴𝗴𝗲𝘀𝘁 𝘄𝗮𝘀𝘁𝗲 𝗼𝗳 𝗯𝘂𝗱𝗴𝗲𝘁 𝗳𝗼𝗿 𝗮 𝗧𝗲𝗰𝗵 𝗗𝗼𝗰𝘀 𝘁𝗲𝗮𝗺? Trying to build a Style Guide from scratch. I see Managers burn months in meetings arguing about the Oxford Comma, capitalization in headings, and "allowlist" vs "whitelist." Meanwhile, the backlog grows. The devs get frustrated. Docs ship late. 𝗦𝘁𝗼𝗽 𝗿𝗲𝗶𝗻𝘃𝗲𝗻𝘁𝗶𝗻𝗴 𝘁𝗵𝗲 𝘄𝗵𝗲𝗲𝗹. The tech giants have already spent millions doing the research. If you want speed, consistency, and happy writers, adopt (and slightly adapt) one of these "Big 3." Here are the only style guides you actually need to know: 𝟭. 𝗧𝗵𝗲 𝗚𝗼𝗼𝗴𝗹𝗲 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 𝗗𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗦𝘁𝘆𝗹𝗲 𝗚𝘂𝗶𝗱𝗲 𝗕𝗲𝘀𝘁 𝗳𝗼𝗿: API docs, SDKs, and developer-focused content. Google changed the game by moving away from stiff, academic writing. They treat developers like humans, not compilers. 𝗪𝗵𝘆 𝗶𝘁 𝘄𝗶𝗻𝘀: 𝗧𝗼𝗻𝗲: It champions a "conversational" style. It gives you permission to be clear rather than "professional." 𝗙𝗼𝗿𝗺𝗮𝘁𝘁𝗶𝗻𝗴: Their guidelines on code blocks and command-line syntax are the gold standard. 𝗧𝗵𝗲 "𝗚𝗹𝗼𝗯𝗮𝗹" 𝗺𝗶𝗻𝗱𝘀𝗲𝘁: It is explicitly written to make translation and localization easier. 𝗦𝘁𝗲𝗮𝗹 𝘁𝗵𝗶𝘀 𝗿𝘂𝗹𝗲: Use the second person ("you"). It pulls the user into the story. 𝟮. 𝗧𝗵𝗲 𝗠𝗶𝗰𝗿𝗼𝘀𝗼𝗳𝘁 𝗪𝗿𝗶𝘁𝗶𝗻𝗴 𝗦𝘁𝘆𝗹𝗲 𝗚𝘂𝗶𝗱𝗲 𝗕𝗲𝘀𝘁 𝗳𝗼𝗿: SaaS, GUI-heavy products, and general user adoption. If Google is for the back-end, Microsoft owns the front-end. This is the bible for UI text, error messages, and onboarding flows. 𝗪𝗵𝘆 𝗶𝘁 𝘄𝗶𝗻𝘀: 𝗔𝗰𝗰𝗲𝘀𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆: Microsoft is the undisputed king of inclusive design. Their guide teaches you how to write for everyone (screen readers, cognitive differences, etc.). 𝗩𝗼𝗶𝗰𝗲: It teaches "Warm and Relaxed" vs. "Crisp and Clear." 𝗕𝗼𝘁-𝗿𝗲𝗮𝗱𝘆: Excellent guidelines for writing for chatbots and AI interfaces. 𝗦𝘁𝗲𝗮𝗹 𝘁𝗵𝗶𝘀 𝗿𝘂𝗹𝗲: Focus on the user's goal, not the product's features. 𝟯. 𝗧𝗵𝗲 𝗥𝗲𝗱 𝗛𝗮𝘁 𝗦𝘁𝘆𝗹𝗲 𝗚𝘂𝗶𝗱𝗲 𝗕𝗲𝘀𝘁 𝗳𝗼𝗿: Enterprise software, Open Source projects, and complex modular docs. If you are documenting heavy machinery (Kubernetes, Linux, heavy enterprise stacks), fluffy language doesn't work. You need precision. 𝗪𝗵𝘆 𝗶𝘁 𝘄𝗶𝗻𝘀: 𝗠𝗼𝗱𝘂𝗹𝗮𝗿𝗶𝘁𝘆: Red Hat understands topic-based authoring better than anyone. 𝗚𝗿𝗮𝗺𝗺𝗮𝗿 𝗣𝗿𝗲𝗰𝗶𝘀𝗶𝗼𝗻: It is stricter than Google. If your audience is highly technical system architects, this is your safety net. 𝗢𝗽𝗲𝗻 𝗦𝗼𝘂𝗿𝗰𝗲 𝗙𝗶𝗿𝘀𝘁: It’s built for community contribution. 𝗦𝘁𝗲𝗮𝗹 𝘁𝗵𝗶𝘀 𝗿𝘂𝗹𝗲: Keep it modular. If a sentence works in three different contexts, you’ve won. ---- 𝗜’𝗺 𝗰𝘂𝗿𝗶𝗼𝘂𝘀—𝘄𝗵𝗶𝗰𝗵 𝗰𝗮𝗺𝗽 𝗮𝗿𝗲 𝘆𝗼𝘂 𝗶𝗻? Team Google, Team Microsoft, or are you brave enough to stick with Chicago Manual of Style? 👇

If you're building or maintaining an editorial style guide, you need to hear this: The point of a style guide is to be useful. And a document with thousands of picky individual rules is NOT useful. In fact, it's intimidating and impenetrable. And it will lead both editors and writers to inaction. In other words, your team will ignore your style guide if it's too long and detailed. Here's how to avoid that problem: First, don't add everything to the style guide. Instead, pick a base style guide. (I like Associated Press.) Then, add a rule to your style guide that says something like this: "For all style questions not answered in this guide, refer to [base style guide]." (Make sure your team has access to the base style guide you choose.) Then, in your style guide, cover the broad concepts: – Structure – Voice and tone – SEO conventions – Brand positioning/approach – Etc. It's OK to have a section for some picky style rules. But keep it brief. And try to agree with your base style guide wherever possible. There will still be editorial and style questions. And neither your in-house guide nor your base guide will answer all of them. They'll be somewhat rare. And some will — rarely — warrant making a change to your style guide. But others will not be worth adding. They'll be so inconsequential that, while interesting to consider, they won't be worth adding another potential barrier for writers and editors. And that's OK! You'll end up with a truly useful style guide. Rather than an endless list of editorial preferences that no one will read — much less remember. #writing #editing #style #editingtips #writingtips

Every time you start a documentation project, how much time do you spend re-litigating the same decisions? Which words are on the avoid list? How are procedures structured? What is the callout hierarchy? When do you use 'log in' or 'login'? What colors, fonts, or structures do you use? A technical writing design system solves this. One reference that captures your voice and tone rules, content patterns, formatting standards, and word decisions. And it is structured enough that another writer or an AI tool could produce work that fits in with you and your existing documents. Design system is a UX term — Figma, tokens, component libraries. But the concept transfers directly to documentation. And it matters more now: when AI helps you draft or review, it defaults to general conventions. Your design system is how you govern that output. I built one recently using Claude, starting from my own website. The post below walks through exactly what to include, how to prompt for it, and how to use it immediately. It took resources and documents that already existed and created the design system and style guide elements. https://lnkd.in/emsA_2gz