Voice and tone
Stay organized with collections
Save and categorize content based on your preferences.
In your documents, aim for a voice and tone that's conversational, friendly,
and respectful without using slang or 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:
Some things to avoid where possible
- Buzzwords or
technical jargon.
- Being too cutesy.
- Ableist
language or figures of speech.
- Placeholder phrases like please note and at this time.
- Choppy or long-winded sentences.
- Starting all sentences with the same phrase (such as You can or To
do).
- Current pop-culture references.
- Exclamation marks, except in rare really exciting moments.
- Wackiness, zaniness, and goofiness.
- Mixing metaphors or taking a metaphor too far.
- Phrasing that denigrates or insults any group of people.
- Phrasing in terms of let's do something.
- Using phrases like simply, It's that simple, It's easy, or quickly in a
procedure.
- Internet slang, or other internet
abbreviations such as tl;dr or
ymmv.
Some techniques and approaches to consider
- 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.
- If you're uncertain about your phrasing or tone, ask a colleague to take a
look.
- 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.
- 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.)
- 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, 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. |
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-05-20 UTC.
[null,null,["Last updated 2025-05-20 UTC."],[[["\u003cp\u003eWrite in a conversational, friendly, and respectful tone that is approachable and easy to understand, avoiding slang and overly casual language.\u003c/p\u003e\n"],["\u003cp\u003ePrioritize clear and straightforward language, using simple and consistent writing to cater to a global audience with varying levels of English proficiency.\u003c/p\u003e\n"],["\u003cp\u003eAvoid jargon, clichés, and culturally specific references, focusing on delivering information concisely and directly to the reader.\u003c/p\u003e\n"],["\u003cp\u003eStrive for a natural and engaging tone, letting your personality shine through while keeping the primary focus on providing clear and useful information efficiently.\u003c/p\u003e\n"],["\u003cp\u003eEnsure politeness without overusing "please" in instructions, and focus on delivering information in a direct and helpful manner.\u003c/p\u003e\n"]]],["Aim for a conversational, friendly, and respectful tone in documents, avoiding slang, excessive formality, or overly entertaining language. Be clear, direct, and consider a global audience by avoiding jargon, cultural references, and overly complex language. Prioritize providing useful information efficiently. Refrain from using overly polite phrasing like \"please\" in instructions, and ensure sentences are varied and not repetitive. Review writing for natural flow by reading it aloud, and seek peer feedback.\n"],null,["In your documents, aim for a voice and tone that's conversational, friendly,\nand respectful without using slang or being overly colloquial or frivolous; a voice that's\ncasual and natural and approachable, not pedantic or pushy. Try to sound like a\nknowledgeable friend who understands what the developer wants to do.\n\nDon't try to write exactly the way you speak; you probably speak more\ncolloquially and verbosely than you should write, at least for developer\ndocumentation. But aim for a conversational tone rather than a formal one.\n\nDon't try to be super-entertaining, but also don't aim for super-dry. Be\nhuman, let your personality show, and be memorable. But remember that the\nprimary purpose of the document is to provide information to someone who's\nlooking for it and may be in a hurry.\n\nConsider that readers come from many different cultures and may have varying\nlevels of ability reading English. As much as possible, avoid culturally\nspecific references. Simple and consistent writing can also make it easier to\ntranslate documents into other languages. For more information, see\n[Writing for a global audience](/style/translation).\n\nFor other writing best practices, see the following resources:\n\n- [Write accessible documentation](/style/accessibility)\n- [Write inclusive documentation](/style/inclusive-documentation)\n\nSome things to avoid where possible\n\n- Buzzwords or [technical jargon](/style/jargon).\n- Being too cutesy.\n- [Ableist\n language](/style/inclusive-documentation#ableist-language) or figures of speech.\n- Placeholder phrases like *please note* and *at this time.*\n- Choppy or long-winded sentences.\n- Starting all sentences with the same phrase (such as *You can* or *To\n do*).\n- Current pop-culture references.\n- Exclamation marks, except in rare really exciting moments.\n- Wackiness, zaniness, and goofiness.\n- Mixing metaphors or taking a metaphor too far.\n- Phrasing that denigrates or insults any group of people.\n- Phrasing in terms of *let's* do something.\n- Using phrases like *simply* , *It's that simple* , *It's easy* , or *quickly* in a procedure.\n- Internet slang, or other [internet\n abbreviations](/style/abbreviations#dont-use) such as *[tl;dr](/style/word-list#tldr)* or *[ymmv](/style/word-list#ymmv)*.\n\nSome techniques and approaches to consider\n\n- 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.\n- If you're uncertain about your phrasing or tone, ask a colleague to take a look.\n- 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.\n- 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.)\n- 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.\n\nPoliteness and use of *please*\n\nIt's great to be polite, but using *please* in a set of instructions is\noverdoing the politeness.\n\nRecommended: To view the document, click\n**View**.\n\nNot recommended: To view the document,\nplease click **View**.\n\nRecommended: For more information, see\n\\[link to other document\\].\n\nNot recommended: For more information,\nplease see \\[link to other document\\].\n\nExamples\n\n| Too informal | Just about right | Too formal |\n|-----------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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. |\n| 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. |\n| Then---BOOM---just garbage-collect, 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. |"]]