Product Docs Tone

Our voice is consistent and reflects our core personality. Tone expresses the mood or feeling in the voice. Our tone varies depending on the context.

For in-product copy, we strive to maintain a concise, helpful, and professional tone. We want users to feel like there’s a supportive adult in the room keeping them safe, setting clear boundaries, and letting them know what to expect.

Here are some guidelines we use for our voice and tone.

Empathize with the reader

  • Don’t tell people how they feel. Words like “easy”, “simple”, or “just” don’t add much, especially for the user who doesn’t find it easy or when our product isn’t working as expected and it’s not possible at all.

  • Avoid assumptions about a user’s success. Statements like “Congratulations!” or “That’s it!” or “You did it!” provide more noise than signal, are irrelevant to users who are reading but not following along, and are especially unpleasant to users who did not succeed.

  • Keep the user’s emotional state in mind. Try asking yourself how a piece of writing would sound if you felt uncertain or insecure, or if your business were losing thousands of dollars per minute.

Here are some practical examples:

Prefer Avoid
Add the domain to your nginx configuration by editing /etc/nginx/nginx.conf. You can easily add a domain by just adding a line to the nginx configuration file.
When the local server starts, you can view the test page at http://localhost:8080. Finally, just start the server. Congratulations! You’re running your own website!

Be clear about who our audience is

  • Avoid bombastic fluff. Use understated, descriptive language instead. Showing users how our product is useful does more to convince our developer audience than marketing-focused language.

  • Remember that our customers are diverse. Avoid pop culture references, gender assumptions, holidays, hemisphere seasons, and other exclusionary language. Stick to the brand mascot name for example users and usernames (e.g. Sammy Shark, Gilly Glowfish). Otherwise, use non-homogeneous names (e.g. Priyanka, Kenji, and Isabella over Tom, John, and Harry).

  • Don’t use idioms, slang, colloquialisms, or phrasal verbs. They’re hard for non-native speakers and add little if anything for native speakers. Our audience is global, and we should use language that translates well outside of our founding culture.

Here are some practical examples:

Prefer Avoid
Spaces Object Storage is an S3-compatible object storage service that lets you store and serve large amounts of data. Make unstructured data storage and delivery easy, reliable, and affordable with our S3-compatible object storage.
The built-in Spaces CDN minimizes page load times and improves performance. The Spaces CDN “pushes out” objects to edge caches for lightning fast load times.

Be clear about who we are

  • Humanize our tone by using active voice. This promotes understanding of causality, minimizes spooky action at a distance, and lets us take responsibility for our recommendations and instructions.

  • Don’t speak in the first person. Use “you” or “your team” when we expect the reader to be taking an action or making a different choice than the example. Use “we” when talking about DigitalOcean as a company or making technical recommendations.

Here are some practical examples:

Prefer Avoid
To minimize latency, we recommend choosing a datacenter close to your users. It is recommended to choose a datacenter close to your users.
This example creates a Droplet in NYC3, but you can choose any supported datacenter. I used NYC3 to create the example Droplet in this tutorial.