CentercodeDitto
DittoPorygonAPI

Voice & Tone

How we communicate across the platform

Overview

Our voice defines who we are. These guidelines ensure consistent, thoughtful communication that respects users and travels well across cultures.

Why Voice Matters

  • Builds trust - consistent tone creates reliability
  • Shows empathy - users feel understood, not processed
  • Enables humor - delight lives in the details
  • Supports global reach - clear language translates better

Our Voice

Who we are when we communicate

Credible

We know our domain. We speak with authority but never arrogance. Users trust us because we're consistent and honest.

Plain-spoken

We use simple, direct language. No jargon unless necessary. No corporate fluff. We say what we mean.

Self-aware

We acknowledge when things break. We can laugh at ourselves. We don't pretend software is magic—it's made by humans.

Empathetic

We understand user frustration. We validate feelings. We guide, never blame. Errors are our fault, not theirs.

Inclusive

Our words welcome everyone. We avoid idioms, cultural assumptions, and ableist language. We design for a global, diverse audience.

Global

We write for translation. Short, literal sentences. No sports metaphors or regional slang. Clarity over cleverness.

Tone by Context

Our voice stays consistent, but tone adapts to the situation

ContextToneExample
SuccessCelebratory but brief“Project created! Ready to add your first participants?”
ErrorHelpful, never blaming“We couldn't save your changes. Check your connection and try again.”
Empty stateEncouraging, show next steps“No feedback yet. Share your project link to start collecting responses.”
OnboardingWelcoming, educational“Welcome! Let's set up your first testing program.”
LoadingPatient, informative“Loading your dashboard...”
Destructive actionSerious, clear consequences“Delete this program? All projects and data will be permanently removed.”

Where Humor Lives

Delight is intentional. Know when to be playful and when to be serious.

Humor Zones

Green light

Empty states, success messages, tooltips, easter eggs, loading states, 404 pages

Yellow light

Onboarding, settings descriptions, confirmation dialogs

Red light

Errors, destructive confirmations, security/auth, anything blocking workflow

Humor Style

Our brand of funny

  • Clever over loud — a raised eyebrow, not a punchline
  • Nostalgic winks — 80s/90s/00s pop culture, retro tech
  • Industry inside jokes — beta tester humor, QA war stories
  • Self-deprecating — we can laugh at software, UX tropes, even ourselves
  • Unexpected placement — delight lives in the margins

Not our style

  • Forced puns
  • Meme-speak or internet slang
  • Anything that requires explanation
  • Humor at the user's expense
  • Sarcasm that could read as dismissive

Writing for Everyone

Our words should include, not exclude.

Accessibility

  • Describe actions, not abilities ("Select" not "Click")
  • Don't rely on color alone ("the error message" not "the red text")
  • Keep sentences scannable — screen readers exist

Global considerations

  • Idioms rot in translation — prefer literal clarity
  • Sports metaphors are regional landmines
  • Shorter is kinder to translators

Inclusive defaults

  • Gender-neutral unless specifically relevant
  • No "simple" or "easy" — what's easy for you isn't for everyone
  • Avoid ableist language ("blind to," "falling on deaf ears")
  • "Users" or "people," not "guys"

The Gut Check

Before shipping copy, ask yourself:

  1. Would I say this to a colleague I respect?
  2. Does this assume the user is smart and capable?
  3. If this is a joke, would it land without explanation?
  4. Can someone skim this and still understand it?
  5. Could this make someone feel excluded?
  6. Would this translate well to another language?