Quick summary: it’s important to let users know when a hidden process will take more than a few seconds. This article looks at the “when”, “why”, and “how” of communicating system status.
A key principle of good interface design is that it’s important to communicate system status to users, especially when the system requires them to wait for a process “under the hood” that’s not visible. Examples include file operations (copying, moving, deleting) or communication between systems (verifying a credit card or checking available inventory). Messages that communicate status can vary widely – from simple (“Please wait – this will take a moment”) to more complex (animated graphics indicating a percentage of the process completed). Let’s examine the when, how and why of communicating system status.
Say something… say anything.
We’ll start with the most basic level, the “when” and “why” of communicating system status. In general it makes sense to give users a sense for what the system is doing any time there’s a wait of any consequence. How long is that? Various studies have shown that users begin to feel like something’s wrong if they’re forced to wait more than a few seconds between the time they perform an action (like clicking a button) and when they perceive a change in status. Note that it’s not “when a change occurs” or even “when a change is indicated” but when the user actually perceives it. That’s an important distinction that we’ll come back to in a moment.
Part of delivering a good user experience involves keeping users informed and in control as much as possible, so if your system ever requires a user to wait for a process to take place it’s beneficial to clearly communicate what’s happening. This prevents the frustration that typically occurs if a user believes the system has stopped responding and/or is “broken”. But remember, users have to perceive that something’s happening. So how do we ensure that?
Speak up.
Just as important as delivering some type of system status message is ensuring that it’s visible and easily noticed. I’ve seen countless examples of system status messages that are buried below the fold of a scrolling page, displayed using small or low-contrast type, or placed in an obscure location where they’re very easy to overlook. If you’re going to the trouble of telling users that something important is happening you need to be sure they actually notice and read the message. Using eye-catching colors and/or images can help. Here’s a simple wireframe example of a text status display that employs a yellow background for visibility:
Naturally status displays don’t need to be text – here’s an animated display that Orbitz uses to indicate it’s searching for fares (the dots are animated):
Another travel website – Kayak – also uses an animation to show users it’s comparing fares:
There are many ways to show status, and in the case of simple processes the status messages can also be fairly simple. But they must be clearly visible.
Speak clearly.
Now that you’ve got the user’s attention, if you’re going to explain what’s happening the clarity of your language is important. It’s wise to avoid jargon and instead use simple, descriptive language. For example, “SQL query initiated” might be technically accurate in certain situations but it’s cryptic and doesn’t mean much to the average person. “Please wait – we’re searching for your information” is much clearer and can be understood by just about anyone. In general unless your audience is comprised only of technical experts it’s wise to keep things very simple. (as a side note, even if you’re convinced your audience is comprised of technical experts there are probably exceptions – see below).
Try this: put all of your messaging to a “grandma test” – if you were to read the message to your grandmother would she have any idea what it means? If not then consider re-writing it so that it’s understandable to a broad audience.
Seriously, speak clearly.
Speaking of a broad audience, it’s common for software and web teams to make bad assumptions about their use of language. I’ve encountered many development teams in which the prevailing notion was “our audience understands industry terms and abbreviations, so there’s no need to dumb down the language”. But in my experience this is almost always a bad assumption, and is quickly debunked in user testing.
Here’s an example: suppose you’re building a medical billing application. You might be tempted to assume that the people who use the application are mostly medical billing professionals who have plenty of training and already know all the special terms and abbreviations. But what about:
- A new hire? He or she might not yet be up to speed on all the abbreviations.
- The employee who normally doesn’t handle billing but is asked to help out in an especially busy week? He or she doesn’t have exposure to arcane billing jargon.
The point is that it’s easy to make excuses about the clarity of your status messages – but if you’re striving for usability then you need to ensure that all your language is clear and concise and stays away from jargon and excessive abbreviations. Believe me, it’s worth the effort.
Be friendly and polite.
This isn’t as critical as the previous points, but it’s also beneficial to create status messages that are friendly and conversational in tone. Consider this metaphor: you walk into a bookstore and ask a clerk if they have the #12 New York Times bestseller. You might find it a little puzzling and offputting if the clerk simply says “Stand by” in a robotic tone and disappears behind a stack of books. In the real world if the clerk is a human being, he or she is more likely to respond to you conversationally, along the lines of “Let me see if we have that, just a moment.” There’s no reason status messages can’t be similarly conversational. Employing a conversational tone helps put users at ease and reinforces the impression that you care about them as a human beings.
Be specific (even if it’s a guess).
If you’re communicating status about a process that’s especially involved and will take more than a few seconds it’s usually beneficial to give users a sense for the magnitude of effort and/or the amount of time involved – even if there’s no precise answer. For example a simple message along the lines of “This usually takes about a minute” is informative and helpful. If the amount of time is variable then a graphical display of percentage completed and/or time remaining is good. This type of display is already commonplace in operating systems:
This is the status message for a file copy operation from Apple’s OS X. Note the mention of an approximate time (“less than a minute”) – it’s imprecise but still useful. Progress is indicated with a bar as well as a text display showing how much data has been copied so far and how much total data will be copied. This is a good convention because the user gains a sense for the status at a glance and can also choose to read the details.
In Windows (XP shown here) copy operations include an animation depicting what’s happening as well as an estimate of time remaining. In this example it’s less detailed information as the OS X display but still useful and a good convention.
In conclusion
There are many ways to display system status, but just a handful of underlying usability principles that apply:
- Keeping users informed about what’s happening “under the hood” prevents them from becoming confused or frustrated when a process takes more than a few seconds.
- It’s critical to ensure that users actually notice status messages, so be sure they’re bold and not hidden.
- Use clear and concise language to describe what’s happening,
- Avoid jargon or abbreviations if possible.
- If the operation will take more than a few seconds, consider estimating the amount of time needed and/or displaying progress.
Visible and clear status messages are just one facet of creating a positive user experience but I think you’ll find it can be a very important one.
Photo credit: Divemasterking2000. Creative Commons licensed.
Related posts: