Voice and Tone
Concept
A decided-in-advance standard covering the attitude a product always speaks with and how that attitude shifts by situation.
Why it exists
The words inside a product are not written by one person. The designer who built the screen writes the one word on the button, whoever owns the feature writes the error text, and in a rush a line an engineer typed as a placeholder ships as it is. Each person picks the best sentence for their own spot, and collected together it does not sound like one voice.
Pagedeck lived in that state for a while. The signup screen read "Please enter your member information." The confirmation before deleting a document said only "Really?" The screen for a failed payment carried a jokey line with exclamation marks and a cartoon face on it. A user who passed through all three met a stiff product and a flippant one in turn.
The problem did not stop at awkwardness. Someone whose payment just failed is usually in a hurry, and reading a joke at that moment feels like being mocked. Support messages spiked on that screen alone, and they were not about payment methods at all — they were about the company not seeming serious.
Deciding two things in advance, rather than making the same judgment call for every string, is what this standard is. What attitude the product speaks with, and how that attitude gets dialed down when the situation is bad.
How it works
Voice and tone point at different things. Voice is the attitude the product holds on every screen; tone is that attitude adjusted for the moment. A person's character stays the same while their manner of speaking differs at a funeral and at a birthday party.
Voice usually gets set like this.
- Pick three or four adjectives. Plain, free of padding, not self-congratulatory — adjectives of that kind, agreed on by the team.
- Attach a paired example to each adjective. Without this step the adjectives do nothing. "Plain" means writing "Saved" and not writing "Your file has been saved successfully!" — the pairing is what makes the next person land on the same decision.
- Write down what not to do as well. Never address the user as "valued customer," never use more than one exclamation mark on a screen.
Tone divides situations up and fixes an approach for each. What divides them is the state the user is in and whether the action can be undone. Four or five situations cover normal practice.
- Just starting out. An empty screen with nothing in it yet. Instead of explaining, name the one next thing to do.
- Going well. A save or a send just finished. Keep it short — one line.
- Waiting. Say what is happening and roughly how long it takes.
- Something failed. Strip out the jokes and the exclamation marks, and leave only what went wrong and what to do now.
- No way back. Put what disappears inside the sentence. A dialog saying three documents will be permanently deleted and a dialog asking only whether you are sure produce different clicks.
Written up as a document, a single table lasts longest: the situation in the left column, the approach for it in the middle, and a pair of sentences — one to write, one not to — on the right.
Where it shows up
The heaviest use is writing microcopy, the short strings scattered through a product. Error messages, which tell the user the problem and the fix, button labels, which say what pressing does, and empty state copy, the words left on a screen when a list has nothing in it, run into this standard most often.
The second place is design review. Without a standard, opinions about wording turn into a fight about taste. With one, you can say that a sentence conflicts with the approach agreed for a failure state, and from there the discussion is about something fixable.
The third is inside the design system. When a component like a button or a notification gets documented, example sentences for it go in alongside. Terminology consistency, the rule that one concept always gets the same word, sits next to it there. Terminology consistency settles what to call things; this standard settles how to speak.
The fourth is outside the product. Notification emails, support replies, and announcements all have to hold the same attitude for a user to feel they are dealing with one company. Tone and manner sets the attitude for the company as a whole, and this standard keeps it inside the product's screens.
Adding a language reopens it. Under localization, the work of reshaping expression for a language and culture, approach does not transfer unchanged. English sentences that are short and plain often read as rude when carried straight into Korean, so the degree of formality gets set again per language.
How it sounds at work
"The tone is off here. It's a failed-payment screen and there are two exclamation marks."
The sentence conflicts with the approach agreed for moments when the user is stuck.
"Can we get examples into the voice doc? Adjectives alone don't let me decide anything."
The standard hasn't come down to actual sentences, so it can't be used.
"Keep it short here. We settled success messages at one line."
Apply the rule already agreed for that situation.
At Pagedeck, Noa maintains the table. When a new screen gets built, the copy is written first and then checked against which row of the table it belongs to, which is a different order from fitting words into a space that already exists.
Mia uses it from the other side. When support messages cluster on one screen, she looks at the wording before the feature. Changing a single sentence on the failed-payment screen once cut that category of message, so she checks whether editing copy is the cheaper option before anything gets built.
What people get wrong
The most common belief is that writing warmly is the same as having a good voice. A product that talks to you feels better than a stiff one, so it reads that way. But warmth flips meaning depending on the moment. A light joke to someone stuck on a failed payment is not warmth, it is mockery. What has to be decided is not how much warmth but how light each situation allows you to get.
The second is that making the document finishes the job. It is a standard, so writing it down feels like enough — but the documents that actually get followed are the ones full of examples. Someone handed a page that says only "write plainly" writes their own idea of plain, and the tone still shifts from screen to screen with a document in place. Attaching two sentences, one to write and one to avoid, to each adjective earns more than five more pages of prose.
Where to go next
- UX Writing
see which activity this standard sits inside
- Terminology consistency
the rule that settles what to call things in the same spot
- Tone and manner
the outer layer setting the whole company's attitude
Last updated 2026-09-16