Progress Indicators
Google’s second principle for UX states:
Every millisecond counts.
Nothing is more valuable than people’s time. Google pages load quickly, thanks to slim code and carefully selected image files. The most essential features and text are placed in the easiest-to-find locations. Unnecessary clicks, typing, steps, and other actions are eliminated. Google products ask for information only once and include smart defaults. Tasks are streamlined.
Speed is a boon to users. It is also a competitive advantage that Google doesn’t sacrifice without good reason.
User experiences are now often defined, not only by ease-of-use and fun-to-use measures, but by speed. As a user experience designer, it’s not my job to make the system perform faster, but I can include designs that take speed into consideration. Consider Jakob Nielsen’s advice regarding response time:
- 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
- 1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
- 10 seconds is about the limit for keeping the user’s attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.
I’ve had a few conversations with my company’s Performance Engineering team to discuss the overlap between performance and user experience. The work the User Experience team focuses on is how to create designs and interactions that are intuitive, consistent and desirable. We can work to limit the number of clicks and page loads, but we do not have control over how fast the system should respond to user interactions with the product. Enter our Performance Engineering team. They are responsible for making sure that our products are fine tuned so that human-computer interactions are as efficient as possible. But what happens when lag time is unavoidable? We use the progress indicator to provide visual feedback to the user that they must wait.
Obviously, the goal is to keep response times short so that a progress indicator is not needed. However, there are times when it is necessary to use them. Consider the 4 progress indicator types as explained by Steven C. Seow, Ph.D., in his book entitled, Designing and Engineering Time.
Dr. Seow provides the following rule of thumb:
Beyond 2 seconds, some form of progress indication is necessary. Between two and five seconds, a simple indication to the user that the system is working is typically sufficient (Class B). The indication can be a typical “busy” animation or a simple line of text that indicates that work is underway, such as “Saving document.” Beyond five seconds, it is critical to provide some form of active progress indication to the user (Class A or C). This doesn’t mean that the indication cannot take momentary pauses, but it does mean that it must communicate and assure the user that progress is being made. Another class of responsiveness (captive) comes into the picture beyond ten seconds. When a process takes more than ten seconds, you must include an “escape hatch” (typically a Cancel button) to enable users to abort or ignore the process. For durations reliably beyond five minutes or so, consider providing notification of completion (Class D).
After speaking with our Performance Engineering team, we wondered how to engage users when they may be forced to wait. Since we are not in an eCommerce product space, we do not need to fill the space with advertizing. We have the opportunity to display information that is useful, and potentially actionable, to the user.
In your designs have you had to account for wait times? Have you worked with engineers to come up with solutions that focus on alleviating wait times and design appropriate user wait feedback?
Tags: [user experience, ux, ucd, performance, progress indicator, Partial Recall]
Subscribe to My Feed
AIM: heyrobfay
