Style and Tone
User interface (UI) text is among the most influential contributors to the user experience. Users' success or failure, especially with unfamiliar tasks, is impacted by the meaning, amount, and the tone of the language provided.
Tone in writing is the attitude that the writer conveys to the reader. It's designed to create a specific response or emotion in the reader.
New in Windows Vista®
The Windows Tone
- Inspire confidence by communicating to users on a personal level by being accurate, encouraging, insightful, objective, and user-focused.
- Don't be distracting, condescending (example: "Just do this."), or arrogant.
- Avoid the extremes of the "machine" voice (where the speaker is removed from the language) and the "sales rep" voice (where the writing tries to sell us something, to cajole us, to cheer us up, to gloss over everything as "simple.")
Why are these changes important?
UI text tone helps create the personality of Windows programs and the overall user experience. It can instill confidence and a sense of accomplishment in users, or if incorrectly applied, it can confuse users, make them feel less empowered and without control.
How to write for Windows Vista
Use Windows tone
Tone in your application should be:
- Accurate. Users should feel reassured that the information is technically accurate. If the information isn't accurate, the user's experience with that specific task is spoiled, and he loses faith in any other assistance he reads from that source.
- Encouraging. Use language that conveys that the software empowers users to do things, rather than allows them to do things. For example, use the phrase you can rather than Windows lets you or this feature allows you. (Exception: it's okay to use allow when referring to features—such as security features—that permit or deny an action.)
- Insightful. Users should believe that you (and by extension your application) know when a certain task is complicated and that you will guide them through it. At the same time, treat users as intelligent people who happen to need help with a particular problem.
- Objective. Sometimes users want a richer explanation; often they want to know just what they need to move on. This requires objectivity—to recognize that the goal (productivity, curiosity, enjoyment) is the user's goal, not the writer's. It also requires that you shed any predisposed notions about the user.
- User-focused. Write from the user's perspective and preferably from the perspective of what you can do for the user. Users should feel that they will find information that is relevant and accessible to them.
Use real-world language
- Use everyday words when you can, and avoid words you wouldn't say to someone else in person. This is especially effective if you are explaining a complex technical concept or action. Imagine yourself looking over the user's shoulder and explaining how to accomplish the task.
- Use short, plain words whenever possible. Shorter words are more conversational, save space on screen, and are easier to scan.
- Don't invent words or apply new meanings to standard words. Assume that users are more familiar with a word's established meaning than with a special meaning given it by the computer technology industry. When an industry term is required, provide an in-context definition. Avoid jargon, but remember that some expressions specific to computer usage—hacker, burn a CD, and so on—are already part of everyday speech.
- Choose words with a clear meaning.
- Omit needless words—don't use two or three words when one will do.
- Address the user as you, directly or indirectly.
- Use first person (I, me, my) when the user is telling the application or a wizard what to do. Use second person (you, your) when the application, wizard, or UI is telling the user what to do.
- Use we judiciously. The first-person plural can suggest a daunting corporate presence. However, it can be preferable to using the name of your application. Use we recommend rather than it is recommended.
- Avoid third-person references (for example, the user) because they create a more formal, less personal tone.
- Use the active voice, which emphasizes the person or thing doing the action. It is more direct and personal than the passive voice, which can be confusing or sound formal.
- Use the passive voice only to avoid a wordy or awkward construction; when the action rather than the actor is the focus of the sentence; when the subject is unknown; or in error messages, when the user is the subject and might feel blamed for the error if the active voice were used.
Attitude toward the user
- Be polite, supportive, and encouraging. The user should never feel condescended to, blamed, or intimidated.
- Use the word please judiciously. Avoid it except in situations where the user is asked to do something inconvenient or the software is to blame for the situation.
- Use the word sorry only in error messages that result in serious problems for the user (for example, data loss, the user can't continue to use the computer, or the user must get help from a technical representative). Don't apologize if the issue occurred during the normal functioning of the application (for example, if the user needs to wait for a network connection to be found).