Google
Google

Google Voice and Tone

With its Voice and Tone style guide, Google equips developers with the tools to create technical documentation that is informative, friendly, and inclusive.

Given the technical audience, the guide emphasizes the importance of providing information efficiently, reminding developers to prioritize clear and direct communication of useful information above all else. It also offers valuable tips on what to avoid, such as technical jargon, excessive cutesiness, ableist language, and insulting phrasing. Instead, it suggests techniques to improve writing, including seeking clarity by asking oneself the purpose of each statement, seeking feedback from colleagues, and even reading sections aloud to assess their natural flow.

Armed with Google's Voice and Tone guide, developers can easily learn to communicate technical concepts to a wide audience more clearly and effectively.

Google Voice and Tone

In your documents, aim for a voice and tone that's conversational, friendly, and respectful without being overly colloquial or frivolous; a voice that's casual and natural and approachable, not pedantic or pushy. Try to sound like a knowledgeable friend who understands what the developer wants to do.

Don't try to write exactly the way you speak; you probably speak more colloquially and verbosely than you should write, at least for developer documentation. But aim for a conversational tone rather than a formal one.

Don't try to be super-entertaining, but also don't aim for super-dry. Be human, let your personality show, and be memorable. But remember that the primary purpose of the document is to provide information to someone who's looking for it and may be in a hurry.

Consider that readers come from many different cultures and may have varying levels of ability reading English. As much as possible, avoid culturally specific references. Simple and consistent writing can also make it easier to translate documents into other languages. For more information, see Writing for a global audience.

For other writing best practices, see the following resources:

  1. Write accessible documentation
  2. Write inclusive documentation

Some things to avoid where possible

  1. Buzzwords or technical jargon.
  2. Being too cutesy.
  3. Ableist language or figures of speech.
  4. Placeholder phrases like please note and at this time.
  5. Choppy or long-winded sentences.
  6. Starting all sentences with the same phrase (such as You can or To do).
  7. Current pop-culture references.
  8. Exclamation marks, except in rare really exciting moments.
  9. Wackiness, zaniness, and goofiness.
  10. Mixing metaphors or taking a metaphor too far.
  11. Phrasing that denigrates or insults any group of people.
  12. Phrasing in terms of let's do something.
  13. Using phrases like simplyIt's that simpleIt's easy, or quickly in a procedure.
  14. Internet slang, or other internet abbreviations such as tl;dr or ymmv.

Some techniques and approaches to consider

  1. If you're having trouble expressing something, step back and ask yourself, "What am I trying to say?" Often, the answer you give yourself reveals what you should be saying in the document.
  2. If you're uncertain about your phrasing or tone, ask a colleague to take a look.
  3. Try reading parts of your document out loud, or at least mouthing the words. Does it sound natural? Not every sentence has to sound natural when spoken; these are written documents. But if you come across a sentence that's awkward or confusing when spoken, consider whether you can make it more conversational.
  4. Use transitions between sentences. Phrases like Though or This way can make paragraphs less stilted. (Then again, sometimes transitions like However or Nonetheless can make paragraphs more stilted.)
  5. Even if you're having trouble hitting the right tone, make sure you're communicating useful information in a clear and direct way; that's the most important part.

Politeness and use of please

It's great to be polite, but using please in a set of instructions is overdoing the politeness.

Recommended: To view the document, click View.

Not recommended: To view the document, please click View.

Recommended: For more information, see [link to other document].

Not recommended: For more information, please see [link to other document].

Examples

Too informal
Just about right
Too formal
Dude! This API is totally awesome!
This API lets you collect data about what your users like.
The API documented by this page may enable the acquisition of information pertaining to user preferences.
Just like a certain pop star, this call gets your telephone number. The easy way to ask for someone's digits!
To get the user's phone number, call user.phoneNumber.get().
The telephone number can be retrieved by the developer via the simple expedient of using the get() method on the user object's phoneNumber property.
Then—BOOM—just garbage-collect (or collecter des garbáge, as they say in French), and you're golden.
To clean up, call the collectGarbage() method.
Please note that completion of the task requires the following prerequisite: executing an automated memory management function.


With its Voice and Tone style guide, Google equips developers with the tools to create technical documentation that is informative, friendly, and inclusive.

Given the technical audience, the guide emphasizes the importance of providing information efficiently, reminding developers to prioritize clear and direct communication of useful information above all else. It also offers valuable tips on what to avoid, such as technical jargon, excessive cutesiness, ableist language, and insulting phrasing. Instead, it suggests techniques to improve writing, including seeking clarity by asking oneself the purpose of each statement, seeking feedback from colleagues, and even reading sections aloud to assess their natural flow.

Armed with Google's Voice and Tone guide, developers can easily learn to communicate technical concepts to a wide audience more clearly and effectively.

Related examples in Writing Style Guides
WorkOS
WorkOS
Technical Content Style Guide
Help Scout
Help Scout
Content Style