Voice and tone

Table of contents

Voice

At Docker, we've been the customer. We're developers developing for developers. We speak with experience and knowledge and without arrogance or ego. We want to inform and empower people without being confusing or pushy.

We're not afraid to use a bit of cheeky humor to lighten the conversation (and because we don't take ourselves too seriously) but we're always respectful. We communicate with clarity, empathy, and wit; everything we say should inform and encourage.

We align our tone of voice and content with our virtues. The most important principles we follow when we write are the 4Cs:

  1. Correct
  2. Concise
  3. Complete
  4. Clear

We ensure the information is accurate, succinct, thorough, and easy to understand. We keep sentences as simple as possible, but include enough detail for the user to complete the intended task.

All of this means that when we write documentation and UI copy:

  1. We are honest. We give you all the facts and we don't use misdirection or make ambiguous statements. We don't always have all the answers, but we're doing our best to make life better for developers and we'll tell you how it's going.
  2. We are concise. We understand the industry of complex and detailed messaging our users live in because we come from the same world. Docker doesn't bulk up our communication with fluffy words or complex metaphors. We're clear and to the point.
  3. We are relaxed. Our demeanor is casual but not lazy, smart but not arrogant, and focused but not cold. Our voice should be welcoming and warm.
  4. We are inclusive. Developers are developers no matter how much code they've written. Every person is as much a part of our community as the next. We are accepting of all developers from all industries and experience levels.

Tone

Docker's tone is usually informal, but we believe it's always more important to be clear over comical. We're relaxed, but we're not inappropriate or unprofessional.

Friendly tone

Use a tone that's natural, friendly, and respectful without being overly colloquial or full of jargon. Write to inform and empower developers without being confusing or pushy. It’s OK to use contractions as long as the sentence doesn’t become too slangy or informal.

Avoid overdoing politeness. It is good to be friendly and polite, but using ‘please’ in technical documentation or UI copy might be overdoing the politeness.

Positive language

Use positive language. Instead of highlighting the limitations and what the users cannot do, emphasize the positive outcomes.

For example, instead of:

“Features such as Single Sign-on (SSO), Image Access Management, Registry Access Management are not available in Docker Team subscription.”

Use:

“Features such as Single Sign-on (SSO), Image Access Management, Registry Access Management are available in Docker Business subscription.”