Remember the Desktop Cleanup Wizard from Windows XP? It popped up regularly saying, “You have unused icons on your desktop.” To this day I have no idea what an unused icon is…and it probably gets my vote for worst notification ever.
Good notifications and error messages require care. They’re not necessarily hard, but they are often overlooked – to the detriment of your overall product experience. Because notifications often occur at times of anxiety and annoyance, a bad notification can ruin your UX; while a good notification can take a moment of frustration and turn it around.
Not surprisingly, great notifications start with your product mantra, with an understanding – or at least a theory – of who’s using it, for what, and why. From there, I propose the following guidelines.
Do You Need a Notification At All?
Sometimes there’s no need to bother the user. Before you present that dialog, ask yourself:
1. Is it Useful?
An error occurred. It’s tragic. Does the user need to know? Is there some action she’ll need to take to recover, or can she go about her business oblivious to the problem? For example: our app, Emu, enhances your SMSes in various ways. Sometimes that fails: the server returns something the client can’t understand, and the enhancement failed. Initially, we posted a notification – because it was useful to us. But as we moved into alpha I took it out. The SMS has been delivered, and there’s nothing the user can do about the failed enhancement. Better to log the failure to Crittercism for our benefit, and stay silent for the user’s.
If a notification is useful, can you make it more so? For an error, have you provided the user with any action she might need to take, any way to avoid it in the future? For a non-error notification, can you present enough information for the user to make a decision about his next move without opening your app first?
2. Is it Unexpected?
When I mute my Android phone from its lock screen, I get a notification: “Sound off.” Think about that: I flipped a switch with the intention of turning off sound. The switch itself provides visual feedback. So my expectation, having flipped the switch, is that the sound is off. Why notify me of something I already believe to be true?
3. Is it Unknown?
Something can be unexpected but still known. If the user already understands the situation (even imperfectly), there’s no need to bother her further. Here is Android’s notification for a crashed app, which appears after you get dumped back onto the home screen:
The app has already disappeared. You know something has gone wrong. But before you can reopen the app, you must dismiss a dialog telling you what you already know has happened. Apple’s approach with iOS, while arguably more jarring, is far less irritating: you suddenly find yourself on the home screen and can simply pick up where you left off.
4. Is it Timely?
The right notification at the wrong time is disruptive, especially if it requires interaction. Think about all the times you’ve dismissed somebody’s dialog asking you to rate their app. It’s not that you don’t want to rate it; it’s that you’re trying to get something done. (Aside: rate-my-app dialogs would be far more welcome were they single-tap affairs; the multistep process makes them far worse. So the importance of timeliness is arguably proportional to the level of interruption.)
Or consider this popup, from the camera app on my Android phone:
It appears every time I try to take an outdoor picture, right before I hit the shutter button. In a sense, it’s timely: an HDR shot might come out better. But all the perfectly-exposed photos in the world won’t matter if I miss that winning smile. Timeliness is more than just relevance.
Writing Notifications, for People
So you’ve decided you need a notification: it’s useful, unexpected, unknown, and timely. How do you write something that serves your product mantra, that’s user-centered?
5. Can it Interrupt Less?
Let’s return to that Android crash dialog. Notice that it has an OK button. Why require the user to dismiss it? Even if the dialog itself were worthwhile, it’s an extra step after an annoying event, adding insult to injury. One possible rule of thumb: if your dialog only requires one action, maybe it should be non-modal – a transient notification that goes away after a few seconds.
If your notification does require action, allow the user to take that action right from the dialog. It’s frustrating when our devices ask us to do things for them.
And yes, I know building in-context actions can be time-consuming; sometimes it’s not worth the development effort. Better to make that decision consciously.
Removing unnecessary modality isn’t the only way to minimize interruption. What’s the user currently doing? What will the notification obscure? How can you size and position it to minimize the risk of getting in the way? That Android HDR popup might have been a welcome hint as a small message on the edge of the screen, out of the way of the main activity.
6. Is it Comprehensible?
Is whatever has happened comprehensible to users on a fundamental level? If not, are you really sure they need to know about it?
If the situation can be made comprehensible, what’s the right level of information to convey? Detailed error messages are better as a rule, but only insofar as the detail is useful. If you must include additional info for remote debugging, consider a “More Info” button.
7. Is it Clear?
The next challenge: putting it in terms the user will understand. This isn’t as simple as “dumbing it down,” but rather involves an understanding of the user’s expectations and mental model. Going back to the Android crash notification: someone presumably concluded that “crashed” was too technical and went with “stopped.” But if the user has any experience interacting with a computer or mobile device — or has turned on the TV recently — then she’s already familiar with “crash,” while “stop” is unfamiliar. Stopped what?
8. Is it Friendly?
There’s no reason a notification needs to be cold and inhuman. The right tone can soften the blow of a stressful situation, or simply bring a smile to someone’s face. Notifications and errors are an opportunity to give your product a bit of a personality. I’m a huge fan of attitude and humor in product design
But friendliness is a double-edged sword. It’s a balancing act, and it’s easy to overshoot and end up with copy that feels false, affected, patronizing, or just plain weird. Remember that your user isn’t interacting with you; he’s interacting with your product, which by nature is less human and emotive (depending on your personality).
On a more practical level, the quest for friendliness can yield copy that’s overly verbose. It’s possible, but more difficult, to be both friendly and concise.
Putting it Together
Consider the humble 404 error page. Here’s the Apache default, still surprisingly common:
Applying my guidelines above:
- Is it useful? Yes. You tried to load a page that doesn’t exist, and that information is useful in planning your next move.
- Is it unexpected? Yes. You expected to be elsewhere.
- Is it unknown? Yes. This page is the first you’ve heard of the problem.
- Is it timely? Yes. There isn’t really another time to present this, and it’s not disrupting anything that hasn’t already been disrupted.
- Can it interrupt less? Surprisingly, yes. It’s not modal, which is good: you’re not required to click an OK button to proceed. But you do have to get off this page somehow. AOL addresses this by including a search box and directory right on the 404 page, hastening your path onward. (They also redirect to their home page after a few seconds, which is really disconcerting.) But why not take it further? Maybe check for common URL misspellings and see if you can find the likely target page. Or use the URL to construct a search query. Or load the home page with a banner at the top showing the notification. None of these is a cure-all, but each might reduce the level of interruption and send the user on her way faster.
- Is it comprehensible? Sort of. There are really two notifications here: the initial 404 and the subsequent 404 on the ErrorDocument. The former is comprehensible; the latter is not. (Nor is it useful.)
- Is it clear? I don’t think so. It starts out OK: “Not Found” is somewhat clear, if a little unfriendly. The line underneath mostly just duplicates the title, and the “on this server bit” doesn’t really help anyone. Beyond that we get into the secondary notification, which isn’t necessary. The Apache specs at the bottom are really just debugging info. What’s really lacking here is user-level clarity. What happened? What might have caused it? What, if anything, should I do about it?
- Is it friendly? Not even remotely.
This 404 page from Bitly does better, particularly on clarity and friendliness:
The cartoon is cute and animated, adding a little delight to a frustrating moment. They’ve explained the problem in Bitly-specific terms. Their copy is relatively concise but friendly. I think they’ve covered everything on my list except #5: it’s still the same level of interruption as Apache’s version.
Why it Matters
Software pervades our lives, and it’s stressful. Connections drop. Work is lost. Apps crash. Emails come in when we want to be left alone. The best technology supports our lives as beautifully and seamlessly as possible, but notifications are unavoidable. As a source of interruption and stress, they’re already unwelcome. A poorly designed or unnecessary notification can be infuriating. A well-designed one – useful, timely, necessary, understandable, seamless, humble, and perhaps a bit funny – can turn a moment of stress into something good.