Microsoft Voice and Tone: Warm, Crisp, and Ready to Help
Microsoft Voice and Tone: Warm, Crisp, and Ready to Help
Create content that sounds human, empowers customers, and includes everyone
Table of Contents
Introduction
Voice defines how your content sounds. Tone adjusts that voice for specific situations. Together, they determine whether readers perceive your documentation as helpful, cold, confusing, or empowering.
Microsoft’s voice is distinctive and intentional—warmer than most technology documentation, more conversational than academic writing, yet professional enough for enterprise contexts.
This article covers:
- Three voice principles — The pillars of Microsoft’s content personality
- Contractions mandate — Why “it’s” isn’t just acceptable but required
- Person usage — When to use “you,” “we,” and “I”
- Bias-free communication — Writing that includes everyone
- Accessible language — Content that works for all abilities
Prerequisites: Microsoft Writing Style Guide Overview provides foundational context.
Related: Writing Style and Voice Principles covers general voice concepts across multiple style guides.
The Three Voice Principles
Microsoft’s voice rests on three interconnected principles that together create a distinctive, human-centered tone.
Principle 1: Warm and Relaxed
“We’re natural. Less formal, more grounded in real, everyday conversations. Occasionally, we’re fun.”
What “warm and relaxed” means:
- Write as you’d speak to a colleague you respect
- Use conversational structures and phrasing
- Allow appropriate humor when it doesn’t distract
- Avoid stiff, overly formal constructions
Warm and relaxed in practice:
| Cold/Formal | Warm/Relaxed |
|---|---|
| “It is necessary to configure the settings prior to deployment.” | “Configure your settings before you deploy.” |
| “Users should be aware that…” | “Keep in mind that…” |
| “The functionality has been deprecated.” | “This feature is going away. Here’s what to use instead.” |
| “An error has occurred.” | “Something went wrong. Let’s fix it.” |
Boundaries: Warm doesn’t mean unprofessional. Avoid:
- Excessive exclamation points!!!
- Forced humor that distracts
- Overly casual language (“gonna,” “wanna”)
- Slang that excludes non-native speakers
Principle 2: Crisp and Clear
“We’re to the point. We write for scanning first, reading second. We make it simple above all.”
What “crisp and clear” means:
- Lead with the essential information
- Cut every unnecessary word
- Use simple sentence structures
- Optimize for scanners, not deep readers
Crisp and clear in practice:
| Verbose | Crisp |
|---|---|
| “In order to accomplish this task, you will need to…” | “To do this:” |
| “It is important to note that the system requires…” | “The system requires…” |
| “There are several options available for you to choose from.” | “Choose an option:” |
| “At this point in time, we are currently working on…” | “We’re working on…” |
The scanning-first principle:
Most users scan documentation rather than read it. Microsoft optimizes for this reality:
- Front-load keywords — Put important terms at the start of sentences
- Use descriptive headings — Readers should understand content from headings alone
- Break long paragraphs — Walls of text discourage scanning
- Use lists and tables — Structured formats are faster to scan
Principle 3: Ready to Lend a Hand
“We show customers we’re on their side. We anticipate their real needs and offer great information at just the right time.”
What “ready to lend a hand” means:
- Anticipate what users need next
- Provide context and next steps
- Write from the user’s perspective
- Show empathy in error situations
Ready to lend a hand in practice:
| Unhelpful | Helpful |
|---|---|
| “Error: Invalid input.” | “That input isn’t valid. Try a number between 1 and 100.” |
| “See documentation for details.” | “For details, see Configuring authentication.” |
| “Operation completed.” | “Your file is saved. Open it in Word to continue editing.” |
| “Access denied.” | “You don’t have access to this folder. Ask the owner to share it with you.” |
The empathy principle:
When things go wrong, Microsoft’s voice becomes especially important:
- Avoid blame — Use passive voice if needed to avoid “you broke it”
- Offer solutions — Don’t just describe the problem
- Provide escape routes — Give users a path forward
- Acknowledge frustration — “We know this is frustrating”
Contractions: Required, Not Optional
Microsoft takes a strong stance on contractions: they’re not just permitted—they’re required.
Why Contractions Matter
Contractions create conversational warmth:
| Without Contractions | With Contractions |
|---|---|
| “It is not possible to undo this action.” | “You can’t undo this action.” |
| “We are working to resolve the issue.” | “We’re working to resolve the issue.” |
| “You will need to restart.” | “You’ll need to restart.” |
| “That is the recommended approach.” | “That’s the recommended approach.” |
Common Contractions to Use
| Full Form | Contraction | Example |
|---|---|---|
| it is, it has | it’s | “It’s ready to use.” |
| you are | you’re | “You’re all set.” |
| you will | you’ll | “You’ll see a confirmation.” |
| you have | you’ve | “You’ve completed setup.” |
| we are | we’re | “We’re here to help.” |
| we will | we’ll | “We’ll fix this soon.” |
| do not | don’t | “Don’t close this window.” |
| cannot | can’t | “You can’t undo this.” |
| will not | won’t | “This won’t affect your data.” |
| let us | let’s | “Let’s get started.” |
When to Avoid Contractions
Even Microsoft makes exceptions:
- Legal text — Contracts, terms of service
- Emphasis — “Do NOT delete this file” (for critical warnings)
- Negative contractions that could be missed — Consider “do not” for critical actions
- Formal announcements — Some executive communications
Contractions vs. Other Style Guides
| Guide | Contractions Stance |
|---|---|
| Microsoft | Required — use them consistently |
| Permitted — “use them or don’t” | |
| Apple | Permitted — context-dependent |
| AP Style | Permitted in informal contexts |
| Wikipedia | Generally avoided — encyclopedic tone |
| Academic | Usually avoided — formal register |
Person and Perspective
The grammatical person you use shapes the reader’s experience. Microsoft has clear preferences.
Second Person (You): The Default
Microsoft strongly prefers second person (you/your) for most content:
“Address the reader directly. Use ‘you’ to speak to the reader.”
Why “you” works:
- Creates direct connection with reader
- Makes instructions clearer (“you do X”)
- Focuses on reader’s goals, not product features
- Feels more personal and engaging
Second person in action:
✅ Preferred: > “You can customize your dashboard by adding widgets.” > “Save your work before you close the app.” > “Your data is encrypted automatically.”
First Person (We/I): Use Sparingly
Microsoft is cautious about first person:
“We” — Use only when Microsoft (the organization) is speaking:
- “We’re committed to your privacy.”
- “We’ll notify you when the update is ready.”
- “We’re working to resolve this issue.”
Avoid “we” in instructional content:
❌ Avoid: “We recommend configuring two-factor authentication.” ✅ Prefer: “Configure two-factor authentication for better security.”
“I/My” — Use only for user choices in UI:
- ✅ Checkbox: “I agree to the terms of service”
- ✅ Toggle: “Remember my preferences”
- ✅ Option: “My account”
Never use “I” in documentation prose.
Third Person: For Descriptions
Use third person when describing systems or features objectively:
- “The app syncs data every hour.”
- “Windows Update downloads patches automatically.”
- “Azure Functions scale based on demand.”
Person Summary
| Person | When to Use | Example |
|---|---|---|
| You/Your | Instructions, guidance, addressing reader | “Save your file before closing.” |
| We/Our | Microsoft as speaker, company commitments | “We’re committed to accessibility.” |
| I/My | UI elements representing user choice | “☑ Remember my login” |
| Third person | Describing systems, features | “The service processes requests.” |
Bias-Free Communication
Microsoft emphasizes inclusive language that respects all readers regardless of gender, ability, ethnicity, age, or background.
Gender-Neutral Language
Avoid gendered generics:
| Gendered | Gender-Neutral |
|---|---|
| mankind | humanity, people, humankind |
| manpower | workforce, staff, personnel |
| chairman | chair, chairperson |
| he/she (generic) | they, the user, you |
| fireman | firefighter |
| stewardess | flight attendant |
Rewrite to avoid gendered pronouns:
❌ Avoid: “When a user logs in, he sees his dashboard.”
✅ Better options:
- “When you log in, you see your dashboard.” (second person)
- “When users log in, they see their dashboards.” (plural)
- “When a user logs in, they see their dashboard.” (singular they)
Microsoft explicitly endorses singular “they”:
“It’s OK to use they as a singular pronoun.”
Disability and Accessibility Language
Use people-first language:
| Avoid | Prefer |
|---|---|
| “the disabled” | “people with disabilities” |
| “blind users” | “users who are blind” |
| “wheelchair-bound” | “uses a wheelchair” |
| “suffers from autism” | “is autistic” or “has autism” |
| “normal users” | “users without disabilities” |
Focus on the action, not the ability:
❌ Avoid: “For users who can’t see the screen…” ✅ Prefer: “For screen reader users…”
Don’t mention disability unless relevant:
❌ Unnecessary: “A blind engineer developed this feature.” ✅ If relevant: “Screen reader testing helped shape this feature.”
Problematic Terms to Replace
Microsoft identifies specific terms to avoid:
| Avoid | Replace With | Reason |
|---|---|---|
| master/slave | primary/replica, main/subordinate | Historical associations |
| whitelist/blacklist | allowlist/blocklist | Racial associations |
| dummy value | placeholder, sample value | Ableist connotation |
| sanity check | quick check, validation | Mental health stigma |
| crazy, insane | surprising, unexpected | Mental health stigma |
| crippled | disabled, limited | Ableist language |
Age-Inclusive Language
- Don’t assume technical ability based on age
- Avoid “digital natives” vs. “digital immigrants”
- Don’t use “elderly” or “senior” as limiting descriptors
Cultural Awareness
- Avoid idioms that don’t translate (“hit it out of the park”)
- Don’t reference specific holidays as universal
- Use examples that work globally
- Avoid culture-specific humor
Accessible Language
Beyond bias-free communication, Microsoft emphasizes writing that works with assistive technologies.
Screen Reader Considerations
Spell out special characters:
Screen readers may misread symbols:
| Avoid | Use Instead |
|---|---|
| “Retry +” | “Retry and add” |
| “See details ~” | “See details, approximately” |
| “A & B” | “A and B” |
| “50%” (alone) | “50 percent” (in prose) |
Make link text descriptive:
❌ Avoid: “Click here to learn more.” ✅ Prefer: “Learn more about configuring authentication.”
Screen readers often list links out of context. “Here” and “click here” are meaningless in a link list.
Use semantic heading structure:
- Don’t skip heading levels (H1 → H3)
- Headings provide navigation landmarks
- Use heading hierarchy, not just bold text
Cognitive Accessibility
Write for scanners:
- Short paragraphs (3-5 sentences)
- Descriptive headings
- Bulleted lists for multiple points
- Tables for comparisons
Reduce cognitive load:
- One idea per sentence
- Define terms on first use
- Provide context before action
- Consistent terminology throughout
Don’t Rely on Visual Cues Alone
❌ Avoid: “Click the red button.” ✅ Prefer: “Click Delete” (or “Click the Delete button”)
❌ Avoid: “See the options above.” ✅ Prefer: “See Authentication options.”
Related: Accessibility in Technical Writing provides comprehensive accessibility guidance.
Tone Variations by Context
While voice remains consistent, tone adjusts to the situation:
Instructional Content
Tone: Direct, confident, efficient
“Open Settings. Select Privacy. Choose the options that work for you.”
Error Messages
Tone: Empathetic, helpful, non-blaming
“We couldn’t save your file. Check your internet connection and try again.”
Marketing Content
Tone: Enthusiastic, inspiring, benefit-focused
“Build apps faster than ever. Azure takes care of the infrastructure so you can focus on code.”
Legal/Compliance Content
Tone: Clear, precise, complete
“Your data is stored in datacenters located in the region you selected during setup.”
Celebration/Success
Tone: Warm, congratulatory, forward-looking
“Nice work! Your app is deployed. Share it with your team or keep building.”
Common Voice Pitfalls
Pitfall 1: Stiff, Robotic Language
❌ “It is necessary to perform a restart of the application.” ✅ “Restart the app.”
Pitfall 2: Hiding Behind Passive Voice
❌ “Mistakes were made in the configuration.” ✅ “Check your configuration settings.”
Pitfall 3: Blaming the User
❌ “You entered an invalid email address.” ✅ “That email address isn’t valid. Check for typos.”
Pitfall 4: Overusing “Please”
❌ “Please click the button. Please enter your name. Please confirm.” ✅ “Click the button. Enter your name. Confirm.”
(One “please” is friendly. Multiple “pleases” sound desperate or passive-aggressive.)
Pitfall 5: Jargon Without Context
❌ “Leverage the SDK to bootstrap your microservices architecture.” ✅ “Use the SDK to start building your services.”
Pitfall 6: Unnecessary Words
| Wordy | Crisp |
|---|---|
| “In order to” | “To” |
| “Due to the fact that” | “Because” |
| “At this point in time” | “Now” |
| “In the event that” | “If” |
| “For the purpose of” | “To” or “For” |
References
📘 Official Sources
Microsoft Brand Voice 📘 [Official]
Complete guidance on Microsoft’s voice principles.Bias-free Communication 📘 [Official]
Microsoft’s inclusive language guidelines.Accessibility Guidelines 📘 [Official]
Writing for users of all abilities.Grammar and Parts of Speech 📘 [Official]
Person usage, verb tense, and more.
📗 Related Repository Articles
Writing Style and Voice Principles 📗 [Repository]
General voice concepts comparing multiple style guides.Accessibility in Technical Writing 📗 [Repository]
Comprehensive accessibility guidance.