Voice is who we are — one consistent personality across every surface. Tone is how we say it in the moment — calmer in errors, warmer in empty states, tighter in menus. Both serve one goal: make the product feel like a capable teammate, not a vendor.
Three things the voice is, three things it isn't. These don't change — they're the personality, regardless of surface or situation.
We say what we mean. Short sentences, concrete nouns, active verbs. A user should understand the first time, without re-reading.
Even when things break, we don't panic. We don't shout. We name what happened, tell the user what to do next, and move on.
We assume competence. We don't apologize reflexively, or talk down, or crack jokes when someone is trying to get work done.
Voice holds steady; tone flexes by context. The default is neutral — warmer when onboarding, tighter when destructive, lighter only for genuine moments of celebration.
"Welcome back — 3 projects updated since Friday."
Onboarding, first-run, milestones. Never for routine moments.
"Workspaces hold projects and members. Create one to get started."
Empty states, coach marks, tooltips that teach.
"Workspace saved."
90% of UI copy — menus, buttons, confirmations, status.
"This will revoke access for 9 members. You can't undo this."
Destructive actions, warnings, billing changes.
"Couldn't save — network timed out. Your changes are still here."
Errors, outages, recovery moments.
Side-by-side rewrites. The same situation, said two ways — one on-voice, one drifting off it.
Emoji, exclamations, and "journey" language are doing the work the content should do. Also: five sentences for a job that needs two.
Names what's empty, explains the concept, tells the next step. No decoration.
Panics the user, dumps a raw error code, and puts recovery on them. "Immediately" is doing nothing useful.
Names what failed, reassures about data, offers two paths forward. No code unless the user asked for one.
"May have some effects" is vague enough to be wrong. Users deserve to know exactly what will happen.
Names the target. Names the consequences with numbers. Ends with the undo-status. The user makes a real decision.
Every error follows the same structure. If a message can't fit it, the error is probably the wrong shape — or it's a bug we should fix, not surface.
Specific, not generic. "Couldn't save the workspace" beats "Something went wrong".
Only when the cause is actionable. Skip stack traces and error codes unless debugging.
"Try again", "Reload", "Check your connection". A button beats a sentence.
The small rules that keep copy consistent: casing, punctuation, numbers, dates, and the words we always spell the same way.
| Rule | Use | Don't |
|---|---|---|
| Sentence case | Create workspace | Create Workspace |
| Title case only for product names | Akku · Design System | Akku design system |
| Oxford comma | projects, members, and settings | projects, members and settings |
| No end punctuation in UI labels | Workspace saved | Workspace saved. |
| Contractions are fine | you can't undo this | you cannot undo this |
| Numbers — digits from 1 | 9 members, 24 projects | nine members, twenty-four projects |
| Dates — abbreviated, no ordinals | Jan 14 · 2:30 PM | January 14th, 2:30pm |
| Relative time for recent | 2 min ago · Yesterday | 2 minutes and 14 seconds ago |
| Percentages use the symbol | 62% · 100% | 62 percent |
| Em dash — not hyphen | Your changes are still here — try again. | Your changes are still here - try again. |
| Avoid emoji in UI copy | Saved | Saved ✨🎉 |
| Never use "please" | Enter an email address. | Please enter an email address. |
When there are two ways to say the same thing, pick one and stay with it. These are ours.
