(Read part 1 here)

A helpful UI is not as rare as a friendly one, because being helpful is more of a technical skill than a personality. Helpful means informative and organized, as well as comfortable to use. I’ll discuss organized and comfortable in a later article. For now, let’s talk about informative.

Name Everything

1. Remember that users talk to each other (and to technical support). So the UI needs to provide them, as much as possible, with names. Clear, memorable and unique – don’t give two different things the same name.

2. Names should be in plain English (or whatever language your interface is in), not in code.

3. Don’t give things cute names, in case your users aren’t as amused as you’d hoped. Clippy would never have been loved, but with a more respectable name he might not have achieved meme-status so many years after his death.

4. Use words, not symbols, wherever possible. Don’t use # to mean number, for example. Don’t use & where and will fit and don’t use \ or / for or (and certainly do not use ||).

5. Don’t use two words that most people think are the same word. I see a lot of pairs of windows like Settings and Definitions, where a clearer naming scheme would be General Settings and [topic] Settings.

6. Along those same lines, don’t add the distinguishing word to just one instance. Sticking with our previous example, don’t name the first window Settings and the second [Topic] Settings.

Buttons

1. If you’re asking a yes or no question, the buttons should be Yes and No. This seems obvious, and yet I see a lot of yes and no questions with buttons like Save and Cancel.

2. Any button that initiates an action should display the name of the action (in its verb form). Initiate, Save, Cancel, Change etc. When the button is an answer to a question, its name must match the question. Don’t ask people “Do you want to edit or save” and then name the buttons “Accept” and “Cancel”.

3. Many people don’t use Okay as a verb, but it’s a perfectly respectable option for a button.

4. Navigation buttons should say Next and Previous, First and Last etc. Don’t settle for arrows unless there is absolutely no room for the words.

Error Messages

1. Have error messages, always. Silent failures are simply not okay.

2. Error messages shouldn’t be in code. If you want the users to be able to give code-based information to support people you can add that information after the regular error message, not in its place.

3. Error messages should explain the real problem, not just that there had been some error. And certainly don’t lie in an error message. For example, if a file can’t be opened because it’s corrupted, don’t say “Please try again later”; it will never work, and you’re just jerking the users around.

4. However, don’t make up errors. Saying “unknown error” is better than giving wrong error information, because people do try to act based on it.

5. As much as possible, give details of the error. For example, “Your definitions cannot be saved because they conflict” is good, “Your definitions cannot be saved because [definition A] must match [definition B]’s [sub-definition]” is better. “Your definitions cannot be saved” without any explanation at all is bad – how are the users supposed to know if the problem is with the definitions (something the users can fix) or with the saving mechanism (a bug)?

6. Offer solutions to problems, if you can. At least in text, preferably in a button that fixes the problem.

7. The question of how to handle multiple errors at once is always a bit delicate. Do you show one large error, or several small ones? I normally decide this based on the responses to the errors. If the errors must all be handled at once, show them together. If each error must have a different response, show them one at a time. If the errors can be handled either all at once or on their own, show them one at time but give the option “apply to all”.

Extra Information

1. Tool-tips and information bubbles: don’t be shy about them – especially tool-tips. But do make them unobtrusive; tool-tips that cannot be escaped from annoy far more than they help.

2. Place-holders are a great way to name a field without taking up extra space in the UI, or help users understand what goes in the field by putting in an example.

3. Don’t drive users nuts with too many warnings, they’re not children. Warnings are best used for major changes that cannot be undone, for things that are going to work on several entities at once without the users necessarily seeing it in the UI, and for actions that might cause a loss of connectivity with the interface (making it near impossible to fix the connectivity problem without the aid of technical support).

4. Try to use positive rather than negative sentences in settings, buttons etc. Users expect positive actions (“do x”, not “don’t do y”) and might work based on that expectation

5. Give amounts where they matter. Number of results, number of pages and so on.

6. Always show users their own search string and parameters. If you find nothing, say “No results found”, not “Showing 0 of 0 results”.

Statuses

1. Do not leave users in the dark. If you’re working, or thinking of working, or finalizing your thoughts about working, show a proper status message, a loader or a progress bar.

2. If you’re showing your progress, make sure it’s your real progress. If your technology doesn’t allow you to calculate your progress, then just say you’re working.

3. This is not strictly speaking text but I’ll mention it anyway: if you’re using colours to show different statuses, make them very different colours. Similar colurs, and different shades of one colour, are indistinguishable for most users.

Text Order

1. People don’t read very much of a UI, so if you’re providing information, make sure the gist of it is the first few words. The rest of the text should be bonus information for committed readers. In a related note, don’t assume that people have read one section in the window before moving on to the next; if you need text twice, write it twice.

2. When you need to use units of measurement (MB, pixels etc) put them in parenthesis at the end of the field’s label, not after the field. People don’t read that far.

3. When texts are related (such as radio buttons and check boxes in a list), try to make them very similar, so that the differences stand out; this helps users scan the text and pick out the differences, rather than forcing them to read the whole text. If part of the text of all options is identical, it should be moved to the section label, rather than be used again and again in every option

4. Wherever there is no logical sorting for a list (it is not values on a scale such as low, medium, high; is not numbers; and is not progressive states such as on, connecting, off), sort it alphabetically.

Capitals

I won’t bother you now with the rules of capitalization, but do remember – all-caps are aggressive and ugly, so don’t use them.