Feedback must be FUN. Without FUN, you might as well not have any feedback at all.
About two weeks ago, a group of five adults, all highly intelligent, well-educated people with years of experience in working with software were completely baffled by a user interface. I know because I was one of those people.
We were trying to download a piece of software by selecting the version we wanted from a list on the right-hand side of a Web page. We all decided that the page didn’t work because when we clicked on the version nothing happened (we even tried the page in a couple of different browsers in case that was causing the problem).
Eventually, we realized that the page did work. The problem was with the page’s feedback when we selected a version. While we were busy clicking on the version on the right-hand side of the page, a box on the left-hand side of the page was quietly being updated with a new hyperlink that pointed to our download. Unfortunately, all of these links (including the default link displayed when we first opened the page) were almost identical. It took us ten minutes before one of us (not me) noticed what was happening.
We take it for granted that feedback is essential in an effective user interface. At the very least, feedback lets the user know that they’ve done something and that the application has taken action. Feedback also lets the user know that they’ve done the right thing and can carry on to the next step in the process. Often, feedback tells users exactly what they’ve actually done (“Your order has shipped!”).
And, yet, lots of times — as in my example — the feedback we provide to our users doesn’t seem to help: Users don’t see it or don’t react to it in the way we expect. If you want your feedback to be genuinely useful to your users it needs to meet three criteria: It has to be immediate, specific, and obvious. The acronym I use to remember this is FUN: Fast, Unambiguous, and Noticeable (because, I’m told, the acronym ISO for immediate, specific, and obvious is already taken).
As soon as the user has done something, you need to provide them with feedback. This means that your application shouldn’t first:
Instead, the first thing you should do is signal to the user that something has happened. That might be as simple as disabling the button the user just clicked and enabling a Cancel Processing button; it might mean just highlighting the option that the user has selected and displaying the option’s full description; it might mean putting up a “Just a sec” screen while you decide what screen the user will see next. Whatever you do, give the user feedback first.
If it turns out that you can’t do what the user wants, you can provide the user with more feedback…which leads to the next criteria for successful feedback.
Users aren’t interested in your application — they’re interested in achieving their goals. As a result, they’re not really thinking about your application (in fact, if your users have to think about your application, you’re probably creating a rotten user experience). Because, as far as your application is concerned, your users are distracted, you need to be very specific in your feedback. I know you’d like to write one generic feedback message but, if you do, your users will never understand what you’re telling them.
For instance, if you need your users to wait, say “Please wait…” — don’t say “Thanks for your input.” If something has gone wrong tell your users exactly what they need to do to fix the problem (“Date is in the wrong format. Please use Year-Month-Date”, not “Not all inputs are correct”). The more specific you are the less likely users are to misunderstand you and the more likely they are to do what you want.
I should add “distinctive” here also. I used WinZip for two years before I discovered that two dialog boxes that appeared one right after the other were asking two different questions — the two boxes looked exactly alike. If you have two pieces of feedback that appear one right after the other make sure that any messages they contain begin with different words, provide different icons, or highlight different portions of your UI.
In Windows applications, it’s traditional to put messages in a status box in the lower left-hand corner of any form. Despite this being a UI convention for several decades now, I can assure you of one true fact: In the entire history of the world, NO ONE (let me repeat that: NO ONE) has ever looked at the status box in the lower left-hand corner. If you’re providing feedback, you must put it either where your user is looking when they perform their action or where your user is going to look next.
For example, there are three places you can display error messages after the user has clicked a submit button: Right beside the submit button (where the user is looking right now), at the top of the page (but only if you scroll the user to the top of the page after the button is clicked), and right beside the place where the error has occurred. You pick the last option as part of making the feedback specific — a message right beside the incorrect item helps flag which item has the problem. However, that last option only works under two conditions: You provide the message as soon as the user enters the bad data (i.e. when the user is looking where the message will appear) or make the message so obvious that it attracts the user’s eye.
Displaying an error message beside the offending item when the user clicks the submit button just means that the user has to scan the page to find what’s gone wrong (you’ve probably had the experience of clicking a submit button, having nothing happen, and then having to go look for the problem). If you’re going to defer displaying an error message until the user clicks the submit button, put the message near the submit button (displaying it in a line underneath the button is one convention here) — though there’s nothing wrong with highlighting the item in error to add some specificity.
If the creators of the web page had put their feedback where we were looking (on the right-hand side of the page) or had made it stand out (instead of looking like what was already there), I wouldn’t have wasted my time thinking their page was broken. But, then, I wouldn’t have had a topic for this blog post, either.