How to write for the web to make your UI more intuitive

Neat, coherent, and obvious texts make interfaces more intuitive and instill confidence.

Below you will find all common words to avoid in writing when you create a text for your UI.

Words to Avoid in Writing: Unknown Terms and Jargon

Specific phrases or terms can be overwhelming for the user, so always strive to avoid jargon. Do your best when writing for wide audiences and choose words that are easy to understand, both for beginners and advanced users.

Here you can see an example of using jargon:

Yes, sometimes it depends: if your users know this terminology, then this message is fine. Otherwise, give up complicated and uncommon words in your UI.

Long Paragraphs With Plenty of Details

Usually, there is no need to describe each detail at first sight. It’s more convenient for users to explore features individually and find out more details about them gradually, if they actually want to know more.

Useful tips:

• Ask yourself each time: Do my users need to know it?
• Use small units to simplify exploration. Write in sentences with up to 30 words wherever possible.

Complex Tense Forms for Describing the Action

Write in the present tense when describing product behavior. If you want to narrate in the future or past tense, strive to use simple forms.

Using “You”/”Your” With “Me”/”My”

To avoid confusion, don’t mix both pronouns when you address the user in the same context.

Words Instead of Numbers

Using numbers as opposed to their written equivalents saves you screen space.

Declaring “We”

You should be focused on your users and what experience they have with your app, not what it does for them or you.

The only exception is if it requires some action from the human, e.g. replying to a request. In this case, using “we” is appropriate.

 

Uppercase Text

Enabling Caps Lock on your keyboard is fine for logos or acronyms, but not for the entire text. It’s better to use it in prints which do not require extensive reading. Otherwise, users shouldn’t be forced to read your text. Miles Tinker pointed out in his authoritative book, Legibility of Print, that in comparison with lowercase print, capitalised text seriously decreases the speed of reading. Besides, most readers consider uppercase as less legible. Lowercase print is faster to read for users because of its characteristic word forms. It allows users to read by word fragments, whereas uppercase text usually is read letter by letter.

So, in headings, titles, and menu items always use lowercase text.

Using Absolute Forms

Don’t promise the world to your users, and strive to avoid absolutes.

Don’t boast —  explain the feature without excessive pride. It’s needless to say how wonderful it is.

Exclamations

You should avoid them, because they could be considered as shouting.

Gender Neutrality

When it’s possible to specify the gender —  use her or his. The English language allows gender ambiguity (e.g. their instead of he or she). Other languages should be more specific in this case (e.g. you can see her or his photo).

Using Common Phrases

Reduce the wordiness. Speak simple language that is easy to understand. Avoid all common phrases like ‘you should,’ ‘please be advised that’, ‘in order to’, and so on.

12. Asking About Sureness

The “Are you sure?” question usually doesn’t add any value to your request and on the whole, it is useless for the users.

Using Idioms

Sometimes, it’s difficult to find adequate translations for culturally specific language and in some contexts, it’s better to give up on using it altogether.

Using “OK” in Dialogs

In a good dialog box, you need to make all buttons clear, not just ask your users what they want to do. Even though in many dialogs the ‘OK’ button seems to be the standard convention, a more user-friendly approach to dialog boxes can be used instead. For example, it’s better to name a button with the action itself, rather than just providing the dialog with an ‘OK’ button. This method can help to avoid the chance of user errors, as not all of them read dialog boxes.

For instance, in removing photo dialog:

Uncertain Error Messages

Error messages seem to be imminent. However, you can make them less obvious to the user. Write clear and neat error messages that indicate:

• What fell through and why.
• What to do to fix the issue.

Accusing Users

It happens: sometimes users make mistakes. However, you shouldn’t blame them for this.

Write a neutral message without any charges for the issue. Focus on the user, not the problem itself.

Conclusion

Now you’re aware of all the common words to avoid in writing. Knowing this can make your UI texts accurate and easy to understand for every person, regardless of language or cultural background.