- Instantaneous Responsiveness
- Immediate Responsiveness
- Continuous Responsiveness
- Captive Responsiveness
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Captive Responsiveness
We all have limits to how long we're willing to tolerate a delay. The more highly we value something, the more willing we are to tolerate a delay before attaining or experiencing it. In many situations, users have little motivation to wait. A prime example is websites loading pages. Imagine a user grudgingly clicking one of several hyperlinks that may contain some information that he or she wants. The user clicks to one particular website, 20 seconds have gone by, and the website is still loading advertisement banners. Understandably, most users won't stick around and wait for the slow survey web page to load, because plenty of other websites are available.
Rule: Don't hold users captive to waits longer than 10 seconds. If a process needs to make users wait beyond 10 seconds, allow users to cancel or task out of the wait. Ensure that users get useful and consumable information within 7–10 seconds (see Figure 4).
Case study: An application was coded to invite first-time users to fill out an Internet survey when the application was launched for the first time. When clicked, the link took about 12 seconds for the survey site to load fully.
)
Figure 4 For processes that will take more than 10 seconds, provide an "escape hatch" that will allow users to cancel.
Verdict: The Internet survey, made worse by the fact that it was voluntary, was exceeding the average user's attention span. It would be wise to reduce load time to 7 seconds or under.
Remember: This rule has everything to do with the user's attention span, and is best understood as the system's opportunity to make an "elevator pitch" to the user to keep the user interested. Numerous lines of research show that most users have an attention span of 7–10 seconds.