Source: Content design, UX writing, voice and tone
Status: source note, first research pass on 29 September 2026 by a research agent. Every URL was fetched on that date unless marked. Evidence class: practitioner books and public style guides, with NN/g studies named where they exist. The voice and tone template, the microcopy checklist and the AI drafting rules distilled from this note live in the copy review playbook; this note keeps the sources.
In short
Rules it backs: plain words, grade 7 to 9 for general readers (principle 14); interface text is copy (22); voice is constant, tone flexes (23); one German address form per product (25). Principles holds where this note differs.
Buttons, errors, empty states, forms, confirmations, email: 4. Microcopy patterns; the checklist to apply is the playbook's microcopy checklist.
A product's voice: How to build a voice chart; the form to fill is the playbook's voice and tone template.
German copy: 6. German-language specifics. AI-drafted copy: Avoiding generic AI slop. All rules on one page: 25 working rules.
1. Books
Content Design
Author / year: Sarah Richards (now Sarah Winters). First edition, Content Design London, 2017 (ISBN 9781527209183). Second edition with Rachel Edwards, May 2024 (ISBN 9781304640390: https://www.booktopia.com.au/content-design-second-edition-rachel-edwards/book/9781304640390.html , read 29 October 2026); it adds updated case studies and a journey-mapping chapter.
Summary: Richards was Head of Content Design at the Government Digital Service and explained how content design is used on GOV.UK (GDS, 14 March 2014, read 29 October 2026). She defined content design as deciding what content meets a need (text, table, tool, video, or nothing), not only how to word it.
Principles:
Start from a validated user need, written as a user story or job story, before writing a word.
Use data (search logs, support tickets, analytics) to learn the words users actually use, then use those words.
Pair writing: a content designer and a subject expert write together, which replaces sign-off ping-pong.
Crits: review drafts as a group against the need, not against personal taste.
Map the journey first. The right content at the wrong point is still wrong.
Strategic Writing for UX
Author / year: Torrey Podmajersky. O'Reilly, 1st ed. June 2019 (ISBN 9781492049395); 2nd ed. O'Reilly 2025 (ISBN 9781098174330), which adds content design for LLMs (author's page, read 29 October 2026).
URL: https://www.oreilly.com/library/view/strategic-writing-for/9781492049388/ (returns 403 to scripts; confirmed through O'Reilly search results) and https://www.torreypodmajersky.com/content-design-book
Summary: It treats UX text as a system of reusable patterns tied to product goals, with metrics.
Principles:
UX text must be purposeful, concise, conversational and clear (the book's four tests).
Derive voice from the product's principles, so voice is a product decision, not a copywriter's mood.
Content-first design: write the conversation between product and user before drawing screens.
Use a pattern per text type (titles, buttons, errors, empty states, notifications), so no new screen starts from a blank page.
Measure text: tie copy changes to conversion, engagement, retention or support volume.
Microcopy: The Complete Guide
Author / year: Kinneret Yifrah. 1st ed. 2017 (DailyJessie); 2nd ed. 2019 (Nemala), translated by Jacqui Licht.
Summary: The pattern catalogue for small interface text (forms, errors, empty states, success messages, buttons), with hundreds of real screenshots.
Principles:
Write microcopy as one side of a conversation with a specific person at a specific moment.
Every field, button and error is a chance to reduce anxiety (why we ask, what happens next).
Error messages say what happened, why, and how to fix it, without blame.
Empty states and success messages are chances to show voice, but usefulness comes first.
Write microcopy with the designer from the start, not as a last fill-in.
Nicely Said: Writing for the Web with Style and Purpose
Author / year: Nicole Fenton and Kate Kiefer Lee. New Riders (Voices That Matter), 2014.
Summary: Kiefer Lee built Mailchimp's voice and tone work. The book covers interface flows, emails, legal policies, and the internal style documents behind them.
Principles:
Write like you talk, then edit.
Know your reader and their goal before you choose a tone.
Build internal documents (voice guide, style guide, word list) so the whole team sounds like one company.
Clarity and honesty build trust. Cleverness is optional.
Treat legal and policy text as product copy that people deserve to understand.
Conversational Design
Author / year: Erika Hall. A Book Apart, 6 March 2018.
Summary: Argues that human conversation is the right model for every interface, not only chatbots. Chapters: The Human Interface, Principles of Conversational Design, The Principles in Practice, The Power of Personality, Getting it Done.
Principles:
Design the interaction as a dialogue: what would a helpful person say at this step?
Words are design material. Bring them in from the start, not after layout.
A casual tone painted over a hostile process is worse than a plain tone on a good one.
Personality must serve the user's goal, not the brand's ego.
Don't Make Me Think, Revisited
Author / year: Steve Krug. 1st ed. 2000; 3rd ed. "Revisited", New Riders, 2014 (adds mobile).
Summary: The usability classic behind most copy rules: people scan, satisfice and muddle through.
Principles:
Every question that forms in a user's head adds cognitive load. Remove them.
Users scan and pick the first reasonable option, so labels must be obvious at a glance.
"Omit needless words": cut half the words on a page, then half of what is left (Krug's third law).
Happy talk (welcome filler) and instructions nobody reads must go. Make the UI explain itself.
Test with real users. You cannot see your own copy fresh.
Letting Go of the Words: Writing Web Content that Works
Author / year: Janice (Ginny) Redish. 2nd ed. Morgan Kaufmann, 2012.
Summary: Research-grounded web writing. It frames content as a conversation that the reader starts.
Principles:
People come to grab information and act. Write for that, not for reading.
Plan with personas and the conversations they start.
Put the key message first (inverted pyramid).
Write headings as the questions, statements or action phrases the reader would use.
Use meaningful link text; test and revise.
Content Strategy for the Web
Author / year: Kristina Halvorson and Melissa Rach. 2nd ed. New Riders, 2012.
Summary: Content problems are usually organizational. The book introduces Brain Traffic's content strategy quad.
Principles:
The quad: substance (what), structure (how it is organized), workflow (how it is made), governance (who decides and who maintains).
Audit what exists before creating more.
Write a core strategy statement that says what content you will and will not make.
Every piece of content needs an owner and a review date.
Cultivating Content Design
Author / year: Beth Dunn. A Book Apart, 13 April 2021.
Summary: How to grow a content practice inside a company with the tools and team you already have. Dunn built HubSpot's content design team.
Principles:
"Full-stack content design": strategy, research and systems, not only grammar and style.
Change minds with small shifts in thinking rather than mandates.
Seed content-first thinking across product, engineering and support.
Build lasting support (rituals, docs, allies) so the practice survives turnover.
On Writing Well
Author / year: William Zinsser. First published 1976; 30th anniversary ed. HarperCollins, 2006.
Summary: Zinsser's case against clutter: "Clutter is the disease of American writing."
Principles:
Strip every sentence to its cleanest components.
Prefer short, plain words and active verbs.
Cut qualifiers ("a bit", "sort of", "rather").
Know what you think before you write. Unclear writing is unclear thinking.
Rewrite. Clear prose is almost always revised prose.
The Elements of Style, and its critique
Author / year: William Strunk Jr. (privately printed 1918), expanded by E. B. White (Macmillan 1959); 4th ed. 1999.
Critique: Geoffrey K. Pullum, "50 Years of Stupid Grammar Advice", The Chronicle Review, issue dated 17 April 2009: https://pullum.ppls.ed.ac.uk/50years.pdf
Summary: Its style maxims still anchor most guides. Pullum shows that its grammar rules are often wrong (three of its four "passive" examples are not passives). He also argues that "Omit needless words" only helps writers who already know which words are needless.
Principles to keep:
Omit needless words. This means "make every word tell", not "make every sentence short".
Put statements in positive form ("Sign in to continue", not "You cannot continue without signing in").
Use specific, concrete language.
Principles to drop: blanket bans on the passive, and treating usage superstitions as grammar. Use the passive when the actor is unknown or irrelevant ("Your file was saved"), which Google's style guide also allows.
The Sense of Style
Author / year: Steven Pinker. Viking/Penguin, 2014. Won the Plain English Campaign International Award 2014.
Summary: A cognitive-science basis for style. Pinker adopts "classic style" from Francis-Noël Thomas and Mark Turner, Clear and Simple as the Truth (Princeton UP, 2nd ed. 2011, https://press.princeton.edu/books/paperback/9780691147437/clear-and-simple-as-the-truth). In classic style the writer has seen something and directs the reader's gaze to it, and writer and reader are equals.
Principles:
Show the thing, not your process of writing about it. Cut metadiscourse ("In this section we will...").
Hedge only where real uncertainty exists.
Replace nominalizations ("zombie nouns") and abstractions with concrete actors and verbs.
Fight the curse of knowledge: you cannot remember not knowing your own jargon, so test on outsiders.
Use the passive deliberately, to keep the reader's attention on the right thing.
Style: Lessons in Clarity and Grace
Author / year: Joseph M. Williams (1933 to 2008), later with Gregory Colomb and Joseph Bizup. 1st ed. 1981 as Style: Ten Lessons in Clarity and Grace; 12th ed. Pearson 2016; 13th ed. Pearson 2021.
URL: https://en.wikipedia.org/wiki/Style:_Lessons_in_Clarity_and_Grace and https://www.pearson.com/en-us/subject-catalog/p/style-lessons-in-clarity-and-grace/P200000002140 (13th ed., read 29 October 2026)
Summary: A method for diagnosing and fixing unclear sentences.
Principles:
Make the main characters the subjects.
Express the crucial actions as verbs, not nouns.
Old information before new: begin sentences with what the reader already knows.
Put the most important new information at the end of the sentence (the stress position).
Clarity is an ethical duty to the reader.
2. Public style guides worth copying
| Guide | Owner | URL | Best for |
|---|---|---|---|
| Writing to GOV.UK standards (content design + A to Z style guide) | UK Government Digital Service | https://guidance.publishing.service.gov.uk/writing-to-gov-uk-standards/writing-guidelines/ and https://guidance.publishing.service.gov.uk/writing-to-gov-uk-standards/style-guides/a-to-z-style-guide/ | The evidence base for plain language and user-need-first content. The old gov.uk/guidance/content-design and style-guide URLs now redirect (301) here. |
| GOV.UK Design System | GDS | https://design-system.service.gov.uk/components/error-message/ , /components/button/ , /patterns/question-pages/ | Exact wording patterns for forms, errors and buttons. |
| Mailchimp Content Style Guide | Mailchimp (Intuit) | https://styleguide.mailchimp.com/ (CC BY-NC 4.0; source: https://github.com/mailchimp/content-style-guide) | Voice vs tone; a structure a small company can fork for its own guide; sections on accessibility and translation. |
| Microsoft Writing Style Guide | Microsoft | https://learn.microsoft.com/en-us/style-guide/welcome/ | Software UI terminology (click vs select), top 10 tips, brand voice. Also per-language localization guides, including German: https://aka.ms/german-styleguide |
| Google developer documentation style guide | https://developers.google.com/style | Developer docs, API references, word list, tone for technical readers. | |
| Shopify content guidelines (Polaris) | Shopify | https://shopify.dev/docs/apps/design/content | Copy for a merchant-facing SaaS admin; grade 7 reading level; CTAs that start with a verb. Old polaris.shopify.com content links redirect to the Polaris component reference on shopify.dev, not to this page (checked 29 October 2026). |
| Atlassian Design System: voice and tone | Atlassian | https://atlassian.design/foundations/content/voice-tone | B2B collaboration tools; message types (error, success, warning, info). |
| Apple Human Interface Guidelines: Writing | Apple | https://developer.apple.com/design/human-interface-guidelines/writing | Short UI text on small screens; buttons, empty states, the right verb for each device. |
| 18F Content Guide | 18F (GSA), dissolved 1 March 2025 | Source: https://github.com/18F/guides/tree/main/content/content-guide (guides.18f.gov did not resolve on the research date) | Plain-language word lists, technical and interface writing, questions for finding your own voice. |
| Intuit Content Design | Intuit | https://contentdesign.intuit.com/ | A voice system for several brands (QuickBooks, TurboTax, Mailchimp) and voice guidance for AI features. |
| Material Design 3: Content design | https://m3.material.io/foundations/content-design/overview and /style-guide/ux-writing-best-practices , /global-writing/overview | Sentence case, writing for a global audience, accessibility text. These pages render with JavaScript, so their content was confirmed from search snippets, not a full fetch. |
What each guide says (checked against the fetched pages):
GOV.UK: Plain English is mandatory. 1 in 6 adults in England have very poor literacy. Split sentences over 25 words, and keep paragraphs to 5 sentences or fewer. Prefer "buy" to "purchase" and "help" to "assist". 80% of people prefer clear English even on complex topics, and higher literacy goes with a stronger preference. Front-load: "Put the most important information first." People read only 20 to 28% of the text on a page. Tone: "brisk, but not terse", and usually no "please" or "please note". Content design "starts by taking a user need and meeting it on GOV.UK in the best way possible."
GOV.UK Design System, errors: "Describe what has happened and tell them how to fix it." Avoid "please", "sorry", "valid", "invalid", "oops", "forbidden" and "illegal". Patterns: "Enter your first name", "Date you started the course must be after 31 August 2017", "Name must be 35 characters or less". GOV.UK uses an instruction for an empty field and a description for an entry that breaks a rule, such as one that is too long, and asks for consistency (https://design-system.service.gov.uk/components/error-message/ , read 29 October 2026). Keep what the user typed. Buttons: verbs in sentence case, such as "Start now", "Save and continue", "Continue" (not "Next") and "Add another address". Question pages: one question per page; write "(optional)" on optional fields instead of marking required ones with asterisks.
Mailchimp: "You have the same voice all the time, but your tone changes." Voice: plainspoken, genuine, translators, dry humor ("weird but not inappropriate, smart but not snobbish"; "We prefer winking to shouting"). Tone: "consider the reader's state of mind." "Forced humor can be worse than none at all."
Microsoft: The voice stays constant while tone adapts "from serious to empathetic to lighthearted". Voice: warm and relaxed; crisp and clear ("We write for scanning first, reading second"); ready to lend a hand. Top tips: bigger ideas, fewer words ("Ready to buy? Contact us."); write like you speak ("Invalid ID" becomes "You need an ID that looks like this: someone@example.com"); use contractions; use sentence case; start statements with a verb; cut "you can" and "there is".
Google developer style: Sound like "a knowledgeable friend". Avoid "please", "simply", "it's easy", "quickly", exclamation marks, "please note", pop culture, idioms, and anything "cutesy, wacky, or zany". Use active voice; the passive is fine when the actor is irrelevant. Sentence-case headings; put conditions before instructions.
Shopify: US grade 7 reading level. One term per concept, no synonyms. CTAs start with a verb ("Create template"). Errors take a more direct tone.
Atlassian: Bold, optimistic, practical with a wink. "Delight means little flourishes, not humor or being cheeky." Use the wink only when users feel success or relief.
Apple HIG: Match tone to context (a payment error vs a fitness goal). Prefer "Send" to "Let's do it!". No "Click here". Avoid "we" in errors: "Unable to load content" beats "We're having trouble loading this content." Keep labels consistent across multi-step flows (Get Started, Continue/Next, Done). "Favorites" beats "Your Favorites". Say "tap" on touch devices. Empty states give a next step and a button.
18F: Words to avoid include "leverage", "facilitate", "empower", "impactful", "in order to", "key" (unless it unlocks something) and "deploy" (unless it is software). Use positive language: "Sign in to continue" instead of "You cannot continue without signing in". Name UI labels exactly as they appear on screen.
Intuit: "Talk to your friends." Be clear and precise. Ending a sentence with a preposition is fine. Use "you" for the customer and "we" for the company. Think globally. Use active voice, contractions and simple verb tenses (they translate better).
3. Voice and tone
NN/g: The Four Dimensions of Tone of Voice
Kate Moran, Nielsen Norman Group, 17 July 2016: https://www.nngroup.com/articles/tone-of-voice-dimensions/
The four dimensions: formal vs casual, serious vs funny, respectful vs irreverent, matter-of-fact vs enthusiastic.
Changing tone changes users' impressions measurably but modestly (about 0.5 to 1 point on 5-point scales).
Companion study: "The Impact of Tone of Voice on Users' Brand Perception", Moran, 7 August 2016, https://www.nngroup.com/articles/tone-voice-users/ . Trustworthiness explained 52% of the variance in desirability; friendliness added only 8% more. Casual-but-serious copy beat formal copy. Funny insurance copy was rated friendlier but less trustworthy. For SaaS this means: aim for casual, serious and respectful copy with moderate enthusiasm, and use humor rarely.
Voice is constant, tone changes
Mailchimp (above), Microsoft's brand voice page (https://learn.microsoft.com/en-us/style-guide/brand-voice-above-all-simple-human), Apple HIG and Atlassian all describe the same model. 18F defines voice as personality and tone as attitude, "the emotional context of a piece".
How to build a voice chart (drawn from 18F, Mailchimp, Podmajersky and NN/g)
Values first. 18F: "Crafting a voice before you've determined your organization's values can be dangerous." Write 3 to 4 product principles.
Audience: who reads, what they know, and what state they are in (18F; Mailchimp's "reader's state of mind").
Pick 3 to 4 voice attributes, each with a "but not" guardrail (the pattern of Mailchimp's "weird but not inappropriate, smart but not snobbish").
Fill the same rows for each attribute: what it means; what it does not mean; words we use; words we avoid; sentence length and wordiness; grammar habits (contractions, "you" and "we"); punctuation (exclamation marks, emoji); capitalization; one "this, not that" example pair. These rows follow Podmajersky's approach of turning product principles into concrete text decisions.
Mark your default position on NN/g's four dimensions, then write a tone map for each situation (the template lives in the copy review playbook).
Test. NN/g recommends Likert ratings or product-reaction tests to check that users hear the tone you intended.
4. Microcopy patterns
Buttons and links (verb + object)
Lead with a verb that says what happens, in 2 to 4 words. Give the same command the same label everywhere. Label the state the command leads to ("Pause" while a video plays). NN/g, Anna Kaley, "UI Copy: UX Guidelines for Command Names and Keyboard Shortcuts", 3 March 2019: https://www.nngroup.com/articles/ui-copy/
"Get Started" misleads when it actually starts a signup or sales flow. Say what happens instead ("Take the style quiz"). "A link is a promise." Harley and Flaherty, 20 August 2017: https://www.nngroup.com/articles/get-started/
Replace a bare "Learn more" with words about the destination ("Learn more about pricing"). This helps scanning and screen readers. Katie Sherwin, 13 December 2015: https://www.nngroup.com/articles/learn-more-links/
GOV.UK uses "Save and continue" vs "Continue" to tell users whether their data was saved.
Error messages
NN/g, Tim Neusesser and Evan Sunwall, "Error-Message Guidelines", 14 May 2023: https://www.nngroup.com/articles/error-message-guidelines/
Visibility: show errors next to their source; use redundant, accessible indicators; match the treatment to the severity; do not show errors too early (validating a field before the user has finished feels hostile).
Communication: plain language; describe the problem precisely; offer a remedy; do not blame the user.
Efficiency: prevent likely errors; keep the user's input; suggest fixes; link to short explanations.
These build on Nielsen's heuristic 9: help users recognize, diagnose and recover from errors.
Pattern: what happened + how to fix it, in the words of the field's label ("Enter an email address like name@example.com"). Avoid "invalid", "error occurred", "oops" and "we" (GOV.UK, Microsoft, Apple).
Pick the right channel: a validation message for input errors, a notification for system events, an indicator for passive status. Kim Flaherty, 17 January 2024: https://www.nngroup.com/articles/indicators-validations-notifications/
Empty states
NN/g, Kate Kaplan, 19 September 2021: https://www.nngroup.com/articles/empty-state-interface-design/ . Say what state the system is in (loading, nothing yet, error, no results); add a short cue that teaches the feature; give a direct path (a button) to fill the space.
Apple: empty states are temporary, so never put essential information only there.
Onboarding
NN/g, Alita Kendrick, "Mobile-App Onboarding", 21 June 2020: https://www.nngroup.com/articles/mobile-app-onboarding/ . NN/g does not recommend deck-of-cards tutorials, and tutorials do not reliably improve performance. Prefer help in context, at the moment it is needed. Onboard only to collect setup data, to personalize, or when an interaction is genuinely new. Test without onboarding first.
Confirmation dialogs
NN/g, Jakob Nielsen, 18 February 2018: https://www.nngroup.com/articles/confirmation-dialog/ . Confirm only serious, irreversible actions: "if you warn people too much, they stop paying attention". Be specific about the consequence. Label buttons with the action ("Delete file" / "Keep file") instead of Yes/No. Set no default on destructive choices. For the most dangerous actions, require something unusual, such as typing DELETE.
Undo is better than confirmation.
Pricing page copy
Show prices. "Prospective customers want to know the price as their #1 info need on any website, including B2B sites." Where exact prices are impossible, give sample prices, ranges or typical scenarios. Hoa Loranger, 1 December 2013: https://www.nngroup.com/articles/show-price/
Plan comparison tables: "The biggest problem with most comparison tables isn't design, it's content." List the same attributes for every plan, and only attributes users care about. Translate units into meaning (NN/g's example is battery capacity shown as "1.2 iPhone charges"; for SaaS, "about 200 documents" rather than "5 GB"). Compare 5 plans or fewer, keep headers sticky, and switch to tabs on mobile. Moran and Dykes, 9 February 2024: https://www.nngroup.com/articles/comparison-tables/
The button rules apply here too: "Start free trial" or "Upgrade to Pro", not "Get started".
Forms and labels
Put visible labels outside the field. Using placeholder text as the label hurts memory, review, error correction and keyboard users. Katie Sherwin, 11 May 2014: https://www.nngroup.com/articles/form-design-placeholders/
GOV.UK: one question per page for complex flows; mark optional fields "(optional)"; add hint text only where most users need it; error messages reuse the label's wording.
Mailchimp accessibility: label every input, mark required fields plainly, and keep the number of fields low.
Notifications and email
Push notifications: earn trust before asking for permission; say what the notifications will contain; batch them instead of sending bursts; send only what matters to that person; offer preferences inside the app. Alita Kendrick, 18 November 2018: https://www.nngroup.com/articles/push-notification/
Subject lines and titles are microcontent. Put keywords first so truncation does not hide the meaning, say what the email is about in the user's terms, and choose clarity over cleverness. Page titles: 40 to 60 characters. Loranger and Nielsen, 29 January 2017: https://www.nngroup.com/articles/microcontent-how-to-write-headlines-page-titles-and-subject-lines/
5. Plain language and readability
US federal plain language guidance
plainlanguage.gov has been archived and now redirects to Digital.gov's guide: https://digital.gov/guides/plain-language . The full archive, including the Federal Plain Language Guidelines, is at https://github.com/GSA/plainlanguage.gov/tree/main/_pages/guidelines . The legal basis is the Plain Writing Act of 2010.
Principles: know the audience; short words and short sections; active voice ("Not 'It must be done,' but 'You must do it'"); present tense; no hidden verbs ("analyze", not "conduct an analysis"); test with real readers.
Evidence that plain language is not "dumbing down"
NN/g, Hoa Loranger, 8 October 2017: https://www.nngroup.com/articles/plain-language-experts/ . Domain experts (IT managers, professors, a nurse practitioner with a doctorate) preferred short text they could scan.
NN/g, Jakob Nielsen, "How Users Read on the Web", 30 September 1997: https://www.nngroup.com/articles/how-users-read-on-the-web/ . 79% of test users scanned and only 16% read word by word. Writing that was concise, scannable and objective improved measured usability by 124%.
Readability formulas and their limits
Flesch Reading Ease: Rudolf Flesch, "A new readability yardstick", Journal of Applied Psychology 32(3), 221 to 233, 1948 (https://pubmed.ncbi.nlm.nih.gov/18867058/). It uses only words per sentence and syllables per word. Scores run from 0 to 100; higher is easier.
German: Toni Amstad's 1978 adaptation, FRE(de) = 180 minus ASL minus (58.5 × ASW), where ASL is average sentence length and ASW is average syllables per word; the constants change because German words are longer. There is also the Wiener Sachtextformel (school grades 4 to 15). https://de.wikipedia.org/wiki/Lesbarkeitsindex
Hemingway Editor: the default target is grade 9. Hard sentences are highlighted yellow and very hard ones red, and the tool says highlights are guides, not rules. https://hemingwayapp.com/help/docs/readability
Targets: NN/g recommends grade 8 for consumer audiences and grade 12 for educated B2B readers (Nielsen, 15 November 2015, https://www.nngroup.com/articles/legibility-readability-comprehension/). Shopify uses grade 7.
Limits: the formulas count length, not meaning. Nielsen calls them "only an approximation of what really matters". They miss short jargon, ambiguous pronouns, bad ordering and missing steps. German compounds skew syllable counts, and automated syllable counting is error-prone (de.wikipedia). Treat the scores as a smoke alarm, then test with people.
6. German-language specifics
du vs Sie
Etiquette baseline: Duden says Sie is the correct first choice in business and with new contacts, and du is offered by the higher-ranking side. https://www.duden.de/sprachwissen/sprachratgeber/Duzen-oder-Siezen
Spelling: Sie and Ihr (polite forms) are always capitalized (§ 65 of the official rules). du, dein, ihr, euer are generally lowercase (§ 66). Duden rules D83 to D85: https://www.duden.de/sprachwissen/rechtschreibregeln/Gro%C3%9F-%20und%20Kleinschreibung
Industry practice (checked on the research date): Microsoft's German localization style guide uses Sie in all its UI examples ("Das Kennwort ist falsch. Versuchen Sie es noch einmal.") and still allows short casual lines ("Jetzt kann's losgehen."): https://aka.ms/german-styleguide . Apple Germany uses du on apple.com/de ("Übertrage deine Daten in wenigen Schritten"): https://www.apple.com/de/iphone/ , read 29 October 2026.
Decision rule for a SaaS product: choose once per product line, write it into the voice guide, and apply it everywhere, including emails, legal pages and support macros. Mixing the two forms is the real mistake. Du suits consumer, developer and startup tools with a young or peer audience. Sie suits finance, health, the public sector, enterprise buyers and older audiences. A warm tone works with Sie (Microsoft shows this), and a serious tone works with du. If in doubt for B2B, Sie is the safe default; developer tools commonly use du.
Sidestep it where you can: imperatives and infinitives work with either form ("Datei hochladen", "Passwort eingeben"), and German buttons conventionally use the infinitive.
Gender-inclusive language (Gendern): where things stand, and practical options
Rat für deutsche Rechtschreibung (Council for German Orthography): recommendations of 26 March 2021 and an explanation of 15 December 2023. Its criteria say gender-fair texts should be factually correct, understandable and readable, readable aloud, legally certain, transferable to other languages, allow a focus on the essentials, and not make learning written German harder. The Council does not include the asterisk, colon or underscore in the official rules. Since 1 July 2024 the official rules carry a supplementary passage, decided on 14 July 2023, that names these characters and says they "gehören nicht zum Kernbestand der deutschen Orthografie" (are not part of the core of German orthography): https://www.rechtschreibrat.com/DOX/RfdR_Amtliches-Regelwerk_2024_UeberblickAenderungen.pdf and https://www.rechtschreibrat.com/amtliches-regelwerk-der-deutschen-rechtschreibung-ergaenzungspassus-sonderzeichen/ , read 29 October 2026. The 15 December 2023 text explains the decision. https://www.rechtschreibrat.com/geschlechtergerechte-schreibung-erlaeuterungen-begruendung-und-kriterien-vom-15-12-2023/ and https://www.rechtschreibrat.com/geschlechtergerechte-schreibung-empfehlungen-vom-26-03-2021/
Public-sector bans: Saxony (schools since 2021, extended to the schools' partner organizations in July 2023: https://www.evangelisch.de/inhalte/218529/12-07-2023/keine-sonderzeichen-sachsen-weitet-genderverbot-aus ), Bavaria (authorities, schools and universities, in force 1 April 2024: https://www.verkuendung-bayern.de/gvbl/2024-56/ ), Hesse (state administration by a directive of the Minister-President in March 2024: https://taz.de/Genderverbot-in-der-Verwaltung/!6001199/ ; schools by a ministry letter of 22 April 2024: https://sts-ghrf-darmstadt.bildung.hessen.de/aktuelle-informationen/schreiben-vom-22.-april-2024-1.pdf ), all read 29 October 2026; overview in https://en.wikipedia.org/wiki/Gender_star . These bind public bodies, not private companies, but they show how polarized reactions are.
genderleicht.de (run by the Journalistinnenbund, launched 2019, federally funded): "Gendergerecht schreiben in sieben Schritten" (Christine Olderdissen, 10 October 2021). The seven steps: gender from the first word; avoid the generic masculine; write gender-neutrally; describe activities, not persons; make women visible; write for all genders (asterisk); do a final gender check. https://www.genderleicht.de/gendergerecht-schreiben-in-sieben-schritten/
Duden: Gabriele Diewald and Anja Steinhauer, Richtig gendern: Wie Sie angemessen und verständlich schreiben, Dudenverlag 2017 (ISBN 978-3-411-74357-5). The same authors also wrote Handbuch geschlechtergerechte Sprache (Duden 2020).
geschicktgendern.de: Johanna Usinger's Genderwörterbuch, with thousands of neutral alternatives: https://geschicktgendern.de/
Microsoft's German guide (industry practice): reduce the generic masculine rather than eliminate it. Prefer neutral nouns, plurals, suffixes such as -kraft, -personal and -team, rephrasing, and leaving the term out. It says special characters "can compromise readability and usability", and that gendered pronouns should not be used generically.
A practical ladder for UI copy (least to most visible):
Address the user directly (du/Sie), so no gendered noun is needed ("Du hast 3 neue Nachrichten").
Rephrase around actions ("Wer hat Zugriff?" instead of "Welche Nutzer haben Zugriff?").
Use neutral nouns and participles ("Mitglieder", "Team", "Teilnehmende", "Person").
Use pair forms in longer text ("Kundinnen und Kunden").
Use typographic forms (asterisk or colon) only if your audience expects them. They conflict with the Council's criteria, are less clear in screen readers, and break some translation memories. Record the choice in the style guide. For product UI, levels 1 to 3 cover almost everything and keep you out of the debate.
Leichte Sprache vs Einfache Sprache
Leichte Sprache (Easy Language, about CEFR level A1 to A2) has strict rules and requires review by the target group (people with learning disabilities). The rules come from Netzwerk Leichte Sprache e.V. (founded 2006): familiar words, short sentences, large clear type, images, many paragraphs and headings, and review by two or more people from the target group. https://www.netzwerk-leichte-sprache.de/ls/das-netzwerk-und-die-leichte-sprache/regeln
DIN SPEC 33429:2025-03, "Empfehlungen für Deutsche Leichte Sprache", is free from DIN Media and replaces the April 2023 draft (draft page, read 29 October 2026): https://www.dinmedia.de/de/technische-regel/din-spec-33429/387728031
Einfache Sprache (Plain Language, about B1) is simplified standard German for the general public. It has no single binding rulebook and allows longer sentences and subordinate clauses. Definition: Gudrun Kellermann, bpb APuZ 2014: https://www.bpb.de/shop/zeitschriften/apuz/179341/leichte-und-einfache-sprache-versuch-einer-definition/
For a SaaS product: write the UI in Einfache Sprache by default. Leichte Sprache is a separate, tested translation for specific audiences or legal duties.
Legal context: the Barrierefreiheitsstärkungsgesetz (BFSG, which implements EU Directive 2019/882) applies to consumer services provided after 28 June 2025, including "Dienstleistungen im elektronischen Geschäftsverkehr" (e-commerce services) (§ 1(3)). Micro-enterprises that provide services are exempt from the accessibility duty in § 3(1) by § 3(3); § 2 No. 17 defines them: fewer than 10 staff, and annual turnover or balance sheet total of at most EUR 2 million. https://www.gesetze-im-internet.de/bfsg/ . Understandable text is part of accessibility. Last checked: 29 October 2026, against §§ 1, 2 and 3 BFSG on gesetze-im-internet.de.
Length expansion
W3C Internationalization, "Text size in translation", citing IBM's guidelines. Translated length as a percentage of the English length (W3C's "average expansion"), by source length: up to 10 characters, 200 to 300%; 11 to 20, 180 to 200%; 21 to 30, 160 to 180%; 31 to 50, 140 to 160%; 51 to 70, 151 to 170%; over 70, about 130%. German compounds ("Eingabeverarbeitungsfunktionen") may not wrap. https://www.w3.org/International/articles/article-text-size
Microsoft's pseudolocalization guidance: lengthen English by 40% as a rule of thumb; short strings can grow 200 to 400%. https://learn.microsoft.com/en-us/globalization/methodology/pseudolocalization
So the common claim that German is about 30% longer holds for running text. Buttons and labels need far more room. Design for it, and turn on CSS hyphenation (
hyphens: autowithlang="de").
Localization engineering basics
Externalize every string: use keys and resource files, never hardcoded text (Lokalise, "What is i18n", Ilya Krukowski, updated 29 May 2025: https://lokalise.com/blog/what-is-i18n/ ). Format numbers, dates and currency by locale (1.234,56 € in German).
Never concatenate sentence fragments. Use whole messages with named placeholders so translators can reorder them. ICU advice: write full sentences in sub-messages, put
selectoutside andpluralinside, and always includeother. https://unicode-org.github.io/icu/userguide/format_parse/messages/W3C, "Working with composite messages": prefer a topic-comment layout ("Drucker: aktiviert") to sentence templates with variables. Give each placeholder a unique identifier (%1$s, %2$s), and give translators context. https://www.w3.org/International/articles/composite-messages/
Plurals and gender: the number of CLDR plural categories differs by language (English has 2, Arabic 6). Phrase guide by Mohammad Ashour, updated 31 July 2025: https://phrase.com/blog/posts/guide-to-the-icu-message-format/ ; Lokalise: https://lokalise.com/blog/complete-guide-to-icu-message-format/
MessageFormat 2 (Unicode): the successor syntax. It is built into ICU4C and ICU4J: https://messageformat.unicode.org/ . Native JavaScript support (Intl.MessageFormat) is a TC39 Stage 1 proposal (https://github.com/tc39/proposal-intl-messageformat ), and its champion wrote in March 2024 that it is "currently stuck, and unlikely to advance for some number of years" (https://github.com/tc39/proposal-intl-messageformat/issues/49 ), both read 29 October 2026.
Write for translation: no idioms or ambiguity; keep a glossary and style guide; set conditions at the sentence level, not the word level; give translators context notes and screenshots; never bake text into images. Phrase, "10 best practice tips...", Pamela Ghosal, updated 11 March 2026: https://phrase.com/blog/posts/writing-10-best-practice-tips-on-how-to-write-global-ready-content-for-localization/
Pseudolocalize in CI: accented characters, 40% padding and delimiters expose hardcoded strings, truncation and concatenation before any translator is involved (Microsoft, above; ICU pseudo-locales en-XA and en-XB).
Write German natively where it matters. A German-first product should write its German copy directly rather than translate from English, because tone and the du/Sie choice do not survive machine translation.
7. AI-era writing
Avoiding generic "AI slop"
Wikipedia: Signs of AI writing (WikiProject AI Cleanup): https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing
Content: inflated significance ("pivotal moment", "indelible mark", "broader trends"); promotional words ("vibrant", "nestled", "groundbreaking", "rich heritage"); shallow analysis tacked on with -ing phrases; weasel attributions ("experts argue"); formulaic "Despite its... faces several challenges" sections.
Vocabulary: "additionally", "crucial", "intricate", "pivotal", "underscore", "tapestry", "delve", "showcase", "enhance".
Syntax: avoiding "is" ("serves as", "features"); negative parallelisms ("not just X, but Y"); lists padded to three items; too much bold and too many em dashes; emoji as bullets; Title Case headings. The page files em dash overuse under historical indicators (2022 to September 2026) and lists "Y rather than X" framings as a current sign (read 29 October 2026).
The page's own caveat: these are "potential signs of a problem, not the problem itself". Detectors make real errors, and humans are near chance at telling AI text from human text. Fix the underlying vagueness, not only the words.
Evidence of the vocabulary shift: Kobak, González-Márquez, Horvát and Lause, "Delving into LLM-assisted writing in biomedical publications through excess vocabulary", Science Advances, 2 July 2025 (arXiv 2406.07016). At least 13.5% of 2024 PubMed abstracts were processed with LLMs, and up to 40% in some subgroups, detected through an excess of typical style words. https://arxiv.org/abs/2406.07016
How to use LLMs for copy without slop (practice, not tested findings):
Put your voice chart, word list and 5 "this, not that" pairs in the prompt. Ask for 5 variants, pick one, then edit it yourself.
Give the model the facts (the user need, the current state, what happens next). Models invent benefits when facts are missing.
Ban the Wikipedia list plus "seamless", "effortless", "unlock", "elevate", "empower" and "leverage", both in the prompt and in a lint check. ("Empower" and "leverage" are also on 18F's words-to-avoid list.)
Run every AI draft through the same tests as human copy: does it say what happens, in the user's words, in the fewest words?
Read it aloud (GOV.UK, Google and Apple all recommend this).
The voice of AI features themselves: Intuit's AI voice guidance casts the AI as a guide: "The best guides never steal the spotlight." Other rules: "Be conversational but not verbose. Be straightforward but not blunt." "Share what you know and be up front about what you don't." Keep a neutral, professional tone on money topics. https://contentdesign.intuit.com/ai/voice-tone/
Writing for AI agents and LLM readers
llms.txt: proposed by Jeremy Howard (Answer.AI) on 3 September 2024, later updated for v2. It is a markdown file at
/llms.txt. The H1 with the site or project name is the only required part. After it come an optional blockquote summary, optional prose, then H2 sections of[name](url): notelink lists. By convention, an "Optional" section lists links an agent can skip. The proposal also asks sites to serve clean.mdversions of their pages. https://llmstxt.org/Practical rules for LLM readers, which are the same plain-language rules again: descriptive, front-loaded headings, with body text that still makes sense with the headings removed (GOV.UK: https://guidance.publishing.service.gov.uk/writing-to-gov-uk-standards/writing-guidelines/clear-structure/ , read 29 October 2026); one term per concept (Shopify); conditions stated before instructions (Google); no meaning carried only by layout or images (Mailchimp accessibility); descriptive link text (NN/g). Content that works for a screen reader and a translator usually works for an agent.
(a) 25 working rules for product and UX copy
This list condenses the sources above. Principles owns the canonical rules; where the two differ, Principles holds.
Start with the user need and the moment. Before writing, name who reads this, what they are trying to do, and how they feel. (Richards; GOV.UK "Start with user needs"; Mailchimp "reader's state of mind")
Decide what content is needed, including none. The best microcopy is often a clearer control. (Richards; Krug "instructions must die"; NN/g onboarding)
Front-load. Put the most important word first in sentences, headings, buttons and subject lines. (GOV.UK clear structure; Microsoft "Get to the point fast"; NN/g microcontent)
Write like you talk, then cut. Read it aloud. (Fenton and Kiefer Lee; Microsoft; Google; GOV.UK Design System)
Cut needless words, not needed ones. "Make every word tell"; go shorter only when nothing is lost. (Strunk; Zinsser; Krug; Pullum's critique)
Plain words over formal ones: buy, help, about, start, use. Ban the buzzword list. (GOV.UK; 18F; plainlanguage/Digital.gov)
Keep sentences to 25 words or fewer and paragraphs to 5 sentences or fewer, and make UI strings as short as the meaning allows. (GOV.UK)
Make actors the subjects and actions the verbs: "You must do it"; "Analyze", not "conduct an analysis". (Williams; Pinker; Digital.gov)
Default to active voice, and use the passive on purpose when the actor is irrelevant ("Your changes were saved"). (Google; Pinker; Pullum)
Use positive form: say what to do, not what is forbidden ("Sign in to continue"). (18F; Strunk and White)
Buttons are verb + object and predict the result: "Save and continue", "Delete 3 files", "Start free trial". Never "OK", "Yes", "Submit" or a bare "Get started". (NN/g UI copy; NN/g Get Started; GOV.UK buttons; Apple)
One term per concept, everywhere. Keep a word list; same command, same label, same place. (Shopify; NN/g UI copy; Apple "build language patterns")
Errors say what happened and how to fix it, next to the problem, without blame, and keep the user's input. No "invalid", "oops" or "error occurred". (NN/g error guidelines; GOV.UK Design System)
Confirm only the irreversible, and name the consequence on the buttons. Prefer undo. (NN/g confirmation dialogs)
Every empty state says what state the system is in and offers the next action. (NN/g empty states; Apple)
Teach in context, not in tours. (NN/g onboarding)
Put labels above fields, never only in placeholders; mark optional fields, not required ones. Mailchimp says to label required fields clearly instead. (NN/g placeholders; GOV.UK question pages; Mailchimp accessibility)
Links and CTAs describe their destination. No "click here" or lone "Learn more". (NN/g Learn More; Apple)
Voice stays constant; tone flexes. Default to casual, serious and respectful, with moderate enthusiasm; drop jokes in errors, payments and data loss. (Mailchimp; Microsoft; NN/g four dimensions and tone study; Atlassian)
Trust beats charm. Trustworthiness explained far more of desirability than friendliness did. No hype adjectives, no "simply" or "easy". (NN/g tone study; Google tone; GOV.UK "avoid emotional language")
Show prices, and translate plan limits into user terms. (NN/g show price; NN/g comparison tables)
Notifications and emails must earn their interruption: relevant, batched, controllable, with the subject line front-loaded. (NN/g push notifications; NN/g microcontent)
Write for translation from day one: externalized strings, full-sentence ICU messages with named placeholders, no concatenation, and room for 40% or more expansion (much more for short labels). (ICU; W3C composite messages and text size; Microsoft pseudolocalization; Phrase)
In German, pick du or Sie once and enforce it; handle gender with direct address and neutral wording first. (Duden; Microsoft German style guide; Rat für deutsche Rechtschreibung 2023; genderleicht.de; geschicktgendern.de)
Test copy with people, and treat readability scores only as a smoke alarm. Aim for grade 7 to 9 for general readers (Shopify uses grade 7, Hemingway's default is grade 9) and no higher than about grade 12 for specialists. AI drafts go through the same tests plus a lint for AI tells. (Nielsen readability; Shopify; Hemingway; Krug; Wikipedia Signs of AI writing)
Verification notes
Fetched and confirmed: all NN/g articles (authors and dates as listed), the GOV.UK guidance and Design System pages, Mailchimp, Microsoft (style guide pages plus the German style guide PDF), Google developer style, the Shopify content page, Atlassian, Apple HIG (through Apple's JSON endpoint), 18F (GitHub source), Intuit, Digital.gov, W3C, ICU, MessageFormat 2, Microsoft pseudolocalization, Phrase, Lokalise, Duden, Rat für deutsche Rechtschreibung, genderleicht.de, geschicktgendern.de, Netzwerk Leichte Sprache, DIN Media, bpb, BFSG (gesetze-im-internet.de), Wikipedia (Signs of AI writing, Gender star, Lesbarkeitsindex, The Elements of Style, Style, The Sense of Style, Don't Make Me Think), arXiv, llmstxt.org, Pullum's PDF, and the publisher and book pages.
URL changes found: gov.uk/guidance/content-design and the GOV.UK style guide now redirect (301) to guidance.publishing.service.gov.uk. plainlanguage.gov redirects to digital.gov/guides/plain-language. The polaris.shopify.com content pages redirect to the Polaris component reference on shopify.dev. 18F was dissolved on 1 March 2025 and guides.18f.gov did not resolve, so the GitHub source is cited instead. readabilityguidelines.co.uk now redirects to the Content Design London home page.
Partly verified:
Material Design 3 pages render only with JavaScript, so their titles and URLs come from search results.
I could not check the exact rows of Podmajersky's voice chart (the O'Reilly page returned 403). The rows in section 3 are my synthesis, not a quotation.
I could not find a verifiable list of named principles for Erika Hall's book. The principles listed are drawn from verified descriptions of it.
The date of the Winters and Edwards second edition rests on a bookseller listing, because the publisher page gives no year.
Taken from the books, not from a fetched page: the principle lists for the classic books are condensed from their well-known chapters. This covers Krug's "happy talk" and third law, Pinker's curse of knowledge, Williams's old-before-new and stress position, Zinsser on qualifiers, and Strunk's "positive form". I verified their publication details but did not re-fetch the wording of those principles.
Not covered: the session's web search budget ran out partway through the research. As a result I could not check ISO 24495-1:2023, the plain language standard (iso.org also returned 403), and I found no German-language UX writing article on du vs Sie. The du/Sie guidance rests on Duden and on what Microsoft and Apple actually do.