Disclaimer: Please point out any improper translations. Original link: Response Times: The 3 Important Limits, thank you.
Excerpted from Chapter 5 of Usability Engineering (1993)
The basic advice regarding response times has remained unchanged for 30 years (1968–1991):
0.1 second: 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: 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: 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.
Normally, response times should be as fast as possible, but it is also possible for the computer to react so fast that the user cannot keep up with it. For example, a list can scroll so fast that the user cannot stop it when the desired item appears. Actually, the computer can be very fast in showing UI changes, such as animations being timed according to the clock rather than the computer's execution speed: even if a faster computer becomes common, the UI should maintain its usability.
If the computer cannot provide an instantaneous response, continuous feedback should be provided to the user in the form of a percent-done indicator (Myers 1985). Percent-done indicators should be used for operations that take longer than about 10 seconds, which is a golden rule. Progress indicators have three main advantages: they reassure the user that the system has not crashed but is working on the problem; they indicate approximately how long the user can be expected to wait, thus allowing the user to do something else during a long wait; and they provide something for the user to look at (at least they see a wait prompt), making the wait feel less boring. This last advantage should not be underestimated, which is why graphical progress bars are recommended over numeric displays of the time remaining.
For operations where the time taken cannot be predicted in advance, it is impossible to use a percent-done indicator, but it may still be possible to provide feedback on the progress of the task in absolute terms. For example, a system might search an unknown number of remote databases and output the name of each database as it is being searched. If all else fails, the last resort is a less specific progress indicator like a spinning ball, a busy bee flying around the screen, dots in the status bar, or any other mechanism that indicates that the system is working, even if it cannot show what it is doing. Note added to the web version of this article: Most web browsers fail to provide useful progress bars because they do not show the percentage of the page that has been downloaded.
For operations that are reasonably fast, taking between 2 and 10 seconds, a percent-done indicator is overkill. In fact, displaying a progress bar violates the principle of display inertia (the idea that changes flashing on the screen too quickly can be unsettling or stressful for the user). Less obvious progress feedback can still be given; a common solution is to use a "busy" cursor shape combined with rapidly changing numbers in a small area at the bottom of the screen to indicate how much has been completed.
See also:
Articles on website response times and how to improve response times.
Response Times for Web-Based Applications
Updated in 2014: This question has come up again, so I've decided to answer it here.
Q: "You've mentioned many times that response time is important, and there are many tools to measure it, but what is an acceptable response time for a web-based application? Excluding the shopping experience, what is the user's tolerance (upper limit) specifically for interactive applications?"
A: I wish the term "web-based application" would disappear entirely, as it confuses a practical issue in application UI design (a topic we cover in several days of courses). There are no separate guidelines for applications implemented in C++ or JavaScript. Basic usability advice remains the same regardless of implementation because we are discussing user experience, not coding.
Therefore, the response time guidelines for web-based applications are the same as for all other applications. These guidelines have been around for 46 years, so they are unlikely to change because of new technology.
0.1 second: The perceptual limit for direct manipulation of objects in a UI. For example, the time interval between when a user selects a column in a table and when that column is highlighted or feedback is given to the user that it has been selected. Ideally, it is also the response time for sorting columns—in this case, users feel they are sorting the table themselves.
1 second: The perceptual limit for a user to perform an action within the computer's command space without excessive waiting. A delay of 0.2 to 1.0 second will be noticed by the user, and they will feel the computer is "processing" the command, as opposed to responding directly to user action. For example, if sorting a table by a selected column cannot be completed within 0.1 second, it must be completed within 1 second; otherwise, the user will feel the UI has become sluggish and lose the experience of "flow" while performing the task. For delays of more than 1 second, users should be prompted that the computer is working on the problem, such as by changing the shape of the cursor.
10 seconds: The limit for a user to stay focused on a task. Any operation taking longer than 10 seconds requires a percent-done indicator and a clearly marked method for the user to interrupt the operation. Assuming a user returns to the original UI after a delay of more than 10 seconds, they will need to reorient themselves. In a user's workflow, delays of more than 10 seconds are acceptable only during natural breaks, such as when switching tasks.
See also:
Article on time scales in user experience.
No comments yet. Be the first to share your thoughts.