Tone and Terminology
Tone defines the relationship between the writer and the reader. Tone creates an atmosphere that can either engage or repel users.
Guidelines for tone and terminology
Overuse of computer terminology and jargon, inconsistent terminology, and patronizing messages make users feel confused, disheartened, and ultimately disengaged from their experience with software. Therefore, make sure that you adopt a consistent tone that is respectful, reassuring, professional, and friendly.
Your text must be based on the user’s perspective. Users must feel that they are informed about the issues relevant for them, and that regardless how involved a task is, they can get the assistance that they need.
Add value with your text
Always strive to write text that is:
Accurate. Users should feel reassured that the information is technically accurate. If the information is not accurate, the user’s experience with that specific task is spoiled, and they lose trust in other assistance they read from that source.
Encouraging. Use language that communicates that the software empowers users to do things, instead of allows them to do things. For example, use “you can” instead of “Microsoft Dynamics NAV lets you” or “this feature allows you.” It is okay to use “allow” when you refer 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 more difficult and that you will guide them through it. At the same time, always treat users as intelligent people who sometimes need help with a particular problem.
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 intuitive to them.
Keep it short and simple
All the control labels have character limitations, and most control labels are not full sentences. Full sentences are used in instructional text and in message and dialog text.
Address the user directly
Second-person construction, using you and your, makes writing more conversational. However, extensive use of second person can weaken a sentence.
Address the user as you, directly or indirectly. This enables you to write more directly and in a more user-friendly tone. Implying the second person is often the shortest, and the most likely to fit in the control label. For example, ”Choose a customer” (second person is implied).
Use the first person (I, me, my) to let users tell the program what to do. For example, “Save my order”.
Use we judiciously. The first-person plural can suggest a too corporate presence. However, it is better to use the name of your application. Use "we recommend" instead of "it is recommended".
Avoid third-person references (the user) because they create a more formal, less personal tone. Incorrect: The user should save his data. Correct: Save your data.
Set the right tone
How you write, even at the individual sentence level, can make a big difference, so it is important to set the right tone.
Be polite, supportive, and encouraging. The user should never feel condescended to, blamed, or intimidated. Acceptable: Cannot delete document, access is denied. Better: This file is protected and cannot be deleted without specific permission.
Avoid slang. Slang terms can seem forced and unnatural, are difficult to localize, and may not make sense to a broader audience.
Use please judiciously. Avoid please except in situations where the user is asked to do something inconvenient or the software is to blame for the situation. Correct: Please wait while Windows copies the files to your computer.
Use sorry only for serious problems for the user. Do not apologize if the issue occurred during typical functioning of the application. For example, if the user has to wait for a network connection to be found. Correct: We’re sorry, but Fabrikam Backup detected an unrecoverable problem and was shut down to protect files and other data on your computer.
Phrase statements in the positive form. Emphasize what users can accomplish, instead of what they cannot.
Use active language
Active structures keep text concise, give energy, and are explicit. Passive structures are usually longer than active ones and do not express who is doing what. This can confuse the reader about the meaning.
As exceptions to this rule, do use passive voice when:
The action instead of the doer is the focus of the sentence, a wordy or awkward construction can be avoided, or when the subject is unknown.
The user is the subject and might feel blamed for an error or unexpected event if the active voice were used.
Avoid should
Only use should to describe a user action that is recommended, but optional. Avoid using should to indicate probability. Use must only to describe a user action that is required. Use can to describe actions or tasks that the user or program is able to do. Use may to express possibility, not to imply that the user has permission to do something. Wherever possible, express certainty.
Incorrect: When you choose Submit, the data is sent to Microsoft, and you should get a confirmation email message within 24 hours. You should sign the order.
Correct: When you choose Submit, the data is sent to Microsoft, and you will get a confirmation email message within 24 hours. Sign here.
Be precise
Unnecessary information can confuse and frustrate users. Users feel obligated to read what is written. Be sure that information is not too obvious and burdensome for the reader.
Choose words with a clear meaning.
Omit needless words. Do not use two or three words when one will do.
Avoid unnecessary adverbs.
Choose single-word verbs over multi-word verbs.
Do not convert verbs to nouns and nouns to verbs.
Be consistent
Consistent terminology promotes learning and a better understanding of technical concepts. Inconsistency forces users to determine if different words and actions mean the same thing.
Consistent syntax helps set users' expectations. Once these expectations are set, users can quickly parse text that uses consistent syntax. For example, if instructions are always written in the imperative form, users will learn to pay closer attention to imperative sentences.