Microcopywriting: tone in interface texts
Voice versus tone: where the boundary lies and why violating it costs money
Voice is the personality that never changes: it is written once in the brand book and lives in all company texts. Tone is the mood of this personality at the moment, and it must change with the context. If the brand voice is defined as 'friendly', the tone on the successful payment screen can be joyful, and on the error screen — calm and collected. The personality remains recognizable: it is the same voice, just in a different mood.
| Parameter | Voice | Tone |
|---|---|---|
| Does it change | No, fixed in the guideline | Yes, depends on the screen and situation |
| Level | The entire brand | A specific scenario, screen, letter |
| Apple example | Simple, elegant, minimalist | Calm in settings, concise in errors |
| Slack example | Informal, team-oriented | Playful in onboarding, neutral in billing |
| Mailchimp example | Friendly, without condescension | Warm in greeting, professional in payment errors |
The mistake of most teams is to write texts 'to suit the author's mood', not to suit the fixed voice. As a result, in the application there are phrases with jokes about kittens and a dry office formulation 'an unexpected error occurred'. This is not a difference of tone — this is a voice rupture, and the user perceives it as unprofessionalism.
Tone matrix: a system instead of manual word selection
Tone map is a table that links three variables: scenario, user's emotional state at that moment, and the acceptable tone range. Without it, each copywriter and product manager solves the issue intuitively, and after six months, the product ends up with five different 'characters'.
- Write down all typical interface scenarios: onboarding, successful action, error, empty state, deletion, payment, support.
- For each scenario, determine the probable user emotional state — not the type of action, but the feeling itself: rush, frustration, uncertainty, pride.
- Define the tone boundaries: what level of humor, formality, and exclamation is acceptable.
- Attach one standard example of microcopy for each cell.
- Add a 'forbidden techniques' column — specific words and signs that cannot be used in this scenario.
| Scenario | User emotion | Acceptable tone | Prohibited |
|---|---|---|---|
| Successful payment | Relief, pride | Warm, short, congratulatory | Excessive enthusiasm, sarcasm |
| File upload error | Irritation | Calm, specific, with a solution | Exclamation marks, humor |
| Account deletion | Alarm, uncertainty | Serious, respectful | Emoji, puns |
| Onboarding | Curiosity, light vigilance | Friendly, supportive | Bureaucratese, terminology overload |
Such a matrix covers what article competitors hardly offer: it turns tone choice from a matter of taste into a verifiable rule that can be passed on to a new author in an hour, not half a year of immersion in the brand.
Critical moments: where one wrong phrase kills conversion
Errors, data deletion, and payments are high-risk points because the user is already on edge at this moment, and any dissonance between their state and the text tone is perceived as disrespect or, worse, as a sign of an unreliable service. A strict rule applies here: the higher the cost of error for the user, the lower the expressiveness of the text should be.
A good error message structure consists of three parts: what happened, why it happened, and what to do next. Example from Nielsen Norman Group practice: «File not uploaded. Size 12 MB, limit 5 MB. Try compressing to CSV». No drama, no «oops», but the user gets everything needed to act.
- Never use exclamation marks in error messages — it increases anxiety rather than alleviating it.
- Never use emojis in enterprise products — trust is built on predictability, not friendliness.
- Never joke in scenarios related to money or data access — humor in moments of risk is perceived as a lack of seriousness about the company.
Buttons are a separate sore topic. The formula 'verb + user outcome' always works, whereas the formula 'verb + system action' almost never does. 'Send form' leaves the question unanswered: what happens next? 'Get quote' answers immediately — I will know the price. The difference of just one word sometimes leads to a difference in conversion percentages because a button is the final point before a decision, and it should speak in terms of benefit, not process.
One tone against the contrast: application, emails, support
There are two approaches to consistency, and both fail in extremity. The first is a rigid unified template of phrases for all channels: it saves time, but sounds like a robot in live chat support and like Captain Obvious in a push notification. The second is complete freedom for each team: marketing writes vividly, support writes dryly, product writes neutrally — and the user encounters three different 'personalities' of the company across three screens.
The working variant is the third: the voice is fixed by a single document, and the tone is adapted via a channel through the same tone matrix, but with an added column labeled 'channel'. In an application, the tone is compact because the screen is small and attention is scattered. In email, the tone can be more elaborate because the message is read in a calm context. In support, the tone becomes the warmest and most human, because there is already a live dialogue and high emotional engagement from the user, often at the brink of patience.
Consistency checking is simple: gather ten real messages from different channels within one day—notification, email, support response, error text—and read them aloud in sequence. If it seems as though they were written by different companies, the tone system is not working.
Diagnosis: how to identify a broken tone in a finished interface
Auditing tone does not require design review—just trace the user path and write down every phrase that causes even the slightest irritation or confusion. Red flags are easy to enumerate.
- Systemic language instead of human: "Error 404", "Transaction not completed", "Invalid data entry".
- Accusatory tone: "You entered the wrong password" instead of "Password does not match, try again".
- False cheerfulness on serious screens: exclamation marks on errors, weeeh on account deletion.
- Different register of address—sometimes "you", sometimes "you"—in adjacent screens of one flow.
- System parasites: "please try again later", not explaining what happened in general.
| Was | Problem | Became |
|---|---|---|
| "Error! Try again!" | Exclamation, no reason or solution | "Could not save. Check internet connection and try again" |
| "Submit form" | Focus on the system, not the user | "Get quote" |
| "Are you sure you want to delete your account?? 😢" | Emoji and emotional manipulation at a serious step | "Deleting an account is an action without the possibility of cancellation. Continue?" |
Every word in the interface either helps the user perform an action or hinders it — there is no middle ground. The success metric for microcopy is not literary merit or wit, but the fact that the person clicked the correct button. If a phrase can be removed without losing meaning or action — it should be removed.
Tone for the script versus tone for the emotion
Most guides stop at associating tone with the type of action: onboarding is cheerful, error is serious, success is joyful. This works in half the cases, but fails where the same type of action is accompanied by different emotions for different users. An error during the first use of a product causes uncertainty — the person thinks they broke something. The same error for an experienced user on their hundredth session causes irritation — they simply want to quickly bypass it.
Practical outcome — to determine not only the scenario, but also the probable emotional state based on context: time in the product, number of attempts, speed of actions. A user who has clicked the same button three times in a row is either in a hurry or in frustration, and the tone at that moment should be as brief and functional as possible, without a single unnecessary word. A user who is reading the help section for the first time is uncertain, and the tone can afford more explanations and gentleness. A tone tied only to the screen, and not to the person's state on that screen, is half the system. The second half emerges when the team agrees to read not only 'what the user sees,' but also 'what he probably feels right now.'
Voice versus tone: where the boundary lies and why violating it costs money
Voice is the personality that never changes: it is written once in the brand book and lives in all company texts. Tone is the mood of this personality at the moment, and it must change with the context. If the brand voice is defined as 'friendly', the tone on the successful payment screen can be joyful, and on the error screen — calm and collected. The personality remains recognizable: it is the same voice, just in a different mood.
| Parameter | Voice | Tone |
|---|---|---|
| Does it change | No, fixed in the guideline | Yes, depends on the screen and situation |
| Level | The entire brand | A specific scenario, screen, letter |
| Apple example | Simple, elegant, minimalist | Calm in settings, concise in errors |
| Slack example | Informal, team-oriented | Playful in onboarding, neutral in billing |
| Mailchimp example | Friendly, without condescension | Warm in greeting, professional in payment errors |
The mistake of most teams is to write texts 'to suit the author's mood', not to suit the fixed voice. As a result, in the application there are phrases with jokes about kittens and a dry office formulation 'an unexpected error occurred'. This is not a difference of tone — this is a voice rupture, and the user perceives it as unprofessionalism.
Tone matrix: a system instead of manual word selection
Tone map is a table that links three variables: scenario, user's emotional state at that moment, and the acceptable tone range. Without it, each copywriter and product manager solves the issue intuitively, and after six months, the product ends up with five different 'characters'.
- Write down all typical interface scenarios: onboarding, successful action, error, empty state, deletion, payment, support.
- For each scenario, determine the probable user emotional state — not the type of action, but the feeling itself: rush, frustration, uncertainty, pride.
- Define the tone boundaries: what level of humor, formality, and exclamation is acceptable.
- Attach one standard example of microcopy for each cell.
- Add a 'forbidden techniques' column — specific words and signs that cannot be used in this scenario.
| Scenario | User emotion | Acceptable tone | Prohibited |
|---|---|---|---|
| Successful payment | Relief, pride | Warm, short, congratulatory | Excessive enthusiasm, sarcasm |
| File upload error | Irritation | Calm, specific, with a solution | Exclamation marks, humor |
| Account deletion | Alarm, uncertainty | Serious, respectful | Emoji, puns |
| Onboarding | Curiosity, light vigilance | Friendly, supportive | Bureaucratese, terminology overload |
Such a matrix covers what article competitors hardly offer: it turns tone choice from a matter of taste into a verifiable rule that can be passed on to a new author in an hour, not half a year of immersion in the brand.
Critical moments: where one wrong phrase kills conversion
Errors, data deletion, and payments are high-risk points because the user is already on edge at this moment, and any dissonance between their state and the text tone is perceived as disrespect or, worse, as a sign of an unreliable service. A strict rule applies here: the higher the cost of error for the user, the lower the expressiveness of the text should be.
A good error message structure consists of three parts: what happened, why it happened, and what to do next. Example from Nielsen Norman Group practice: «File not uploaded. Size 12 MB, limit 5 MB. Try compressing to CSV». No drama, no «oops», but the user gets everything needed to act.
- Never use exclamation marks in error messages — it increases anxiety rather than alleviating it.
- Never use emojis in enterprise products — trust is built on predictability, not friendliness.
- Never joke in scenarios related to money or data access — humor in moments of risk is perceived as a lack of seriousness about the company.
Buttons are a separate sore topic. The formula 'verb + user outcome' always works, whereas the formula 'verb + system action' almost never does. 'Send form' leaves the question unanswered: what happens next? 'Get quote' answers immediately — I will know the price. The difference of just one word sometimes leads to a difference in conversion percentages because a button is the final point before a decision, and it should speak in terms of benefit, not process.
One tone against the contrast: application, emails, support
There are two approaches to consistency, and both fail in extremity. The first is a rigid unified template of phrases for all channels: it saves time, but sounds like a robot in live chat support and like Captain Obvious in a push notification. The second is complete freedom for each team: marketing writes vividly, support writes dryly, product writes neutrally — and the user encounters three different 'personalities' of the company across three screens.
The working variant is the third: the voice is fixed by a single document, and the tone is adapted via a channel through the same tone matrix, but with an added column labeled 'channel'. In an application, the tone is compact because the screen is small and attention is scattered. In email, the tone can be more elaborate because the message is read in a calm context. In support, the tone becomes the warmest and most human, because there is already a live dialogue and high emotional engagement from the user, often at the brink of patience.
Consistency checking is simple: gather ten real messages from different channels within one day—notification, email, support response, error text—and read them aloud in sequence. If it seems as though they were written by different companies, the tone system is not working.
Diagnosis: how to identify a broken tone in a finished interface
Auditing tone does not require design review—just trace the user path and write down every phrase that causes even the slightest irritation or confusion. Red flags are easy to enumerate.
- Systemic language instead of human: "Error 404", "Transaction not completed", "Invalid data entry".
- Accusatory tone: "You entered the wrong password" instead of "Password does not match, try again".
- False cheerfulness on serious screens: exclamation marks on errors, weeeh on account deletion.
- Different register of address—sometimes "you", sometimes "you"—in adjacent screens of one flow.
- System parasites: "please try again later", not explaining what happened in general.
| Was | Problem | Became |
|---|---|---|
| "Error! Try again!" | Exclamation, no reason or solution | "Could not save. Check internet connection and try again" |
| "Submit form" | Focus on the system, not the user | "Get quote" |
| "Are you sure you want to delete your account?? 😢" | Emoji and emotional manipulation at a serious step | "Deleting an account is an action without the possibility of cancellation. Continue?" |
Every word in the interface either helps the user perform an action or hinders it — there is no middle ground. The success metric for microcopy is not literary merit or wit, but the fact that the person clicked the correct button. If a phrase can be removed without losing meaning or action — it should be removed.
Tone for the script versus tone for the emotion
Most guides stop at associating tone with the type of action: onboarding is cheerful, error is serious, success is joyful. This works in half the cases, but fails where the same type of action is accompanied by different emotions for different users. An error during the first use of a product causes uncertainty — the person thinks they broke something. The same error for an experienced user on their hundredth session causes irritation — they simply want to quickly bypass it.
Practical outcome — to determine not only the scenario, but also the probable emotional state based on context: time in the product, number of attempts, speed of actions. A user who has clicked the same button three times in a row is either in a hurry or in frustration, and the tone at that moment should be as brief and functional as possible, without a single unnecessary word. A user who is reading the help section for the first time is uncertain, and the tone can afford more explanations and gentleness. A tone tied only to the screen, and not to the person's state on that screen, is half the system. The second half emerges when the team agrees to read not only 'what the user sees,' but also 'what he probably feels right now.'
Recent articles
MegaFon, BMW, VTB and more 240+ companies. See how it looks in the showcase reel:
Our branding agency is approached to order:
Branding agency services
