Product Docs Voice and Tone

Product documentation follows DigitalOcean’s brand voice while applying standards specific to technical documentation.

Product Docs are written to help readers complete tasks, understand systems, and resolve issues efficiently. Voice determines how information is presented. Tone determines emotional posture. In Product Docs, both must support clarity, precision, and task completion without hype, urgency, or unnecessary emotion.

Voice and tone remain consistent across all documentation types.

Core Tone Principles

Product Docs maintain a calm, neutral, authoritative, and respectful tone.

Calm and Restrained

Tone must never compete with clarity.

• Use direct, measured language.
• Avoid expressive or personality-driven phrasing.
• Do not use motivational, encouraging, or reassuring language.

Emotionally Neutral

Documentation remains solution-focused and factual.

• Avoid urgency, alarm, or emotional emphasis.
• Avoid minimizing language such as “just,” “simple,” or “easy.”
• Do not imply fault or assign blame.
• Do not speculate about user experience or intent.

Non-Promotional

Product documentation is not marketing.

• Avoid hype or aspirational language.
• Do not promise outcomes.
• Do not describe features in promotional terms.

Voice Principles

Voice governs how information is structured and delivered.

Task-First

Lead with what the reader needs to do or understand.

• Begin with actions, outcomes, or clear explanations.
• Avoid narrative buildup or contextual framing that delays utility.
• Remove content that does not directly support task completion or comprehension.

Structurally Clear

Present information in the order readers need it.

• Sequence steps logically.
• State prerequisites before actions.
• Avoid forcing readers to infer dependencies.

Operationally Precise

Clarity takes precedence over expressiveness.

• Make system behavior explicit.
• Define requirements, constraints, and limits clearly.
• Avoid language that requires interpretation or guesswork.

Explicit About Responsibility

System behavior and user actions must be clear.

• Identify who or what performs an action.
• Avoid ambiguous constructions.
• Prefer clarity of responsibility over stylistic variation.

Resolution-Oriented

Documentation should move readers forward.

• Ensure errors, warnings, and notices point directly to resolution.
• Clearly state actions, prerequisites, and consequences.
• Avoid leaving next steps implied.

Under Pressure

Product Docs are often read when users are blocked or troubleshooting.

Regardless of context:

• Maintain a calm, factual register.
• Avoid reassurance, urgency, or emotional framing.
• Do not speculate about causes beyond verified system behavior.

Clarity and stability in language help reduce friction and support problem resolution.