5 UX guidelines for feedback messages.

5 guidelines for feedback and error messages

Feedback messages and effects should not get overlooked in the application development process or be added as an afterthought, since they are at the core of the user / application interaction. While finding the right tone of voice is one important aspect of crafting meaningful messages, there are actually a number of additional elements to consider. Based on my experience, I have come up with 5 guidelines to follow when defining the interaction between the application and its users (let me know if you feel there’s something missing!):

1. Give feedback on user action and updates on system status
2. Prevent errors from happening
3. Allow for easy error recovery
4. Communicate clearly and consistenty
5. Provide access to more information / help when needed

Let's take each of these in turn.

1. Give feedback

We all thrive on receiving feedback. Take the example of radar speed signs: they not only show you whether you are under or above the speed limit, but also give you a smiley or a frown. We have one close to home and my kids always urge me to make the sign smile – so of course, I slow down to a snail’s pace! This is a lot more enjoyable than “real” radars, which are punitive and not at all playful.

When it comes to applications, these personal speed signs are a good example to follow, and the more immediate the feedback, the better. This includes simple things like :

• Roll-over effects on clickable items such as icons, images, buttons, links, rows (I know, basic stuff!)
• Visually showing focus on form fields
• Validating errors line by line and
• Providing additional progress indicators, such as checks for accomplished task or indicators for password strength.

Once the user has finished a task, it is important to show system progress (if needed) and success confirmation. For example, when clicking the save button, a little animation can show that the information is actually saved (when staying on the same page). If the action is tied to a workflow, it makes sense to display a clear success message that will also communicate what will happen next.

2. Prevent errors from happening

As with drugs – prevention is better than recovery. Different techniques help to prevent errors from occurring in the first place:

• Required fields: Indicate them clearly (I know this is basic again, but still worth mentioning)
• Progressive disclosure: Only show what the user needs to see at any given time, so that they can focus on the task at hand and not skip important steps.
• Responsive enabling: Do not allow buttons to be clickable when they are not (yet).
• Forgiving formats: Allow different formats for entering data – especially for dates and numbers (e.g. I can enter 11-01-2011 or 11.1.11)
• Default values: Whenever possible, provide smart default values.

3. Allow for easy error recovery

Let’s face it: as long as there are humans and machines, we will have errors. The key is to allow the humans to recover easily from their mistakes and for the machines to not get in their way.

Go back: You should always allow the user to go back when they get stuck somewhere. This should be obvious, but is not always so. Especially with rich Internet applications, the back functionality does not always work the way the user would expect it; this is because the notion of “multiple pages” often does not exist anymore. So if the user is in a wizard and needs to go back to correct some information, he should be able to do so and not lose any information before or after.

Provide an Undo command: Most computer users are familiar with the “undo” concept, and many have a natural reflex to hit Ctr X / Cmd X whenever they want to go back a step or two. But when it comes to web applications, this functionality is often overlooked by developers, which becomes a real issue when these applications are supposed to replace desktop ones. It is nevertheless possible to implement this functionality with help of Javascript – even at multiple levels, as Google Docs has demonstrated (also featuring my other favorite – copy & paste). While difficult to implement this functionality from scratch, there are frameworks such as Cappuccino which have it built in.

You should enable users to edit or delete items whenever business processes allow them to. When workflows are involved – e.g. a document approval process – there comes a point where editing is no longer an option. However, to simply enforce that you cannot modify your review once you have submitted it is an easy way out. A more “user-friendly” system would allow you to modify until the next person in the review process has opened the file.

If an action is critical and irreversible, always ask for confirmation, usually in the case of deleting or closing unsaved items. However, for less critical events it becomes annoying to the user to always be asked whether they are “really sure” they want to delete – so it’s a fine line to walk. Consider using a “don’t ask me again” option.

4. Communicate clearly and consistently

Here is an example of what NOT to do! It is rather sad, since the one who created the message had the best intentions in the world, allowing the user to do just about anything. However, the most likely scenario in this case would be for the user to check “Never ask me again”.