Chapter 10. Doherty Threshold

Productivity soars when a computer and its users interact at a pace (<400 ms) that ensures that neither has to wait on the other.

Key Takeaways

• Provide system feedback within 400 ms in order to keep users’ attention and increase productivity.

• Use perceived performance to improve response time and reduce the perception of waiting.

• Animation is one way to visually engage people while loading or processing is happening in the background.

• Progress bars help make wait times tolerable, regardless of their accuracy.

• Purposefully adding a delay to a process can actually increase its perceived value and instill a sense of trust, even when the process itself actually takes much less time.

Overview

One of the features that is critical to good user experiences is performance. Emotions can quickly turn to frustration and leave a negative lasting impact when users who are trying to achieve a task are met with slow processing, lack of feedback, or excessive load times. Often overlooked as more a technical best practice, speed should be considered an essential design feature that is core to good user experiences. Whether it’s the amount of time the product or service takes to initially load, how fast it is to respond to interactions and provide feedback, or how quickly subsequent pages load, the speed at which a system responds is key to the overall user experience.

There are several factors that can impact the performance of websites and apps, but the most significant is overall page weight. Unfortunately, when it comes to page weight on the web, the average has increased exponentially over the years. According to the HTTP Archive, the average desktop page weight in 2019 was approaching 2 MB (1,940 KB), with mobile not too far behind at 1.7 MB (1,745 KB). This is a vast increase over the average page weights in 2010–2011: 609 KB on desktop and 262 KB on mobile (Figure 10-1).

Figure 10-1. Average page weight is increasing each year (source: HTTP Archive, 2019)

This trend means longer wait times, and waiting is not something people like to do when trying to complete a task. Countless studies reinforce the fact that the longer the wait times that people are subjected to, the more likely it is they will grow frustrated and even abandon the task altogether.

Additionally, slow response times from a system lead to a decrease in the productivity of the people using an interface. While a 100 ms response feels instantaneous, a delay of between 100 and 300 ms begins to be perceptible to the human eye, and people begin to feel less in control. Once the delay extends past 1,000 ms (1 second), people begin thinking about other things; their attention wanders, and information important to performing their task begins to get lost, leading to an inevitable reduction in performance. The cognitive load required to continue with the task increases as a result, and the overall user experience suffers.

Origins

In the early days of desktop computing, 2 seconds was considered an acceptable threshold for response time from a computer when performing a task. The reason for this widely accepted standard was that it provided time for the user to think about their next task. Then, in 1982, a paper published by two IBM employees challenged this previous standard by stating that “productivity increases in more than direct proportion to a decrease in response time” when the threshold is under 400 ms.1 The authors of the study claimed that “when a computer and its users interact at a pace that ensures that neither has to wait on the other, productivity soars, the cost of the work done on the computer tumbles, employees get more satisfaction from their work, and its quality tends to improve.” It set a new standard that would come to be known as the Doherty threshold, based on Doherty’s observation that computer response times have a disproportionate impact on productivity.

Examples

In some cases the amount of time required for processing is longer than what is prescribed by the Doherty threshold (>400 ms), and there simply isn’t much that can be done about it. But that doesn’t mean we can’t provide feedback to users in a timely fashion while the necessary processing is happening in the background. This technique helps to create the perception that a website or an app is performing faster than it actually is.

One common example used by platforms such as Facebook (Figure 10-2) is the presentation of a skeleton screen when content is loading. This technique makes the site appear to load faster by instantly displaying placeholder blocks in the areas where content will eventually appear. The blocks are progressively replaced with actual text and images once they are loaded. This reduces the impression of waiting, which increases the perception of speed and responsiveness even if the content is loading slowly. Additionally, skeleton screens prevent the jarring and disorienting experience of content jumping around as adjacent material loads by reserving space for each item up front.

Figure 10-2. Facebook’s skeleton screen helps the site appear to load faster (source: Facebook.com, 2019)

Another way to optimize load times is known as the “blur up” technique. This approach focuses specifically on images, which are often the main contributor to excessively long load times in both web and native applications. It works by first loading an extremely small version of an image and scaling it up in the space where the larger image will eventually be loaded. A Gaussian blur is applied to eliminate any obvious pixelation and noise as a result of scaling up the low-resolution image (Figure 10-3). Once the larger version of the image is loaded in the background, it is placed behind the low-resolution version and revealed by fading out the top image. Not only does this technique ensure faster load times by prioritizing performance over content, but it also allocates room for full-sized images up front to prevent page jumping once the high-resolution version of the image is fully loaded.

Figure 10-3. Medium uses the “blur up” technique to enable faster page loading (source: Medium.com, 2019)

Animation is yet another way to visually engage people while loading or processing is happening in the background. A common example is “percent-done progress indicators,” also known as progress bars. Research has shown that simply seeing a progress bar can make wait times seem more tolerable, regardless of its accuracy.2 This simple UI pattern is effective for several reasons:

• It reassures people that their action is being processed.

• It provides visual interest while they wait.

• It reduces the perception of waiting by shifting focus to the animation of the progress bar as opposed to the actual process of waiting.

While we can’t always circumvent the need for processing and the subsequent waiting, we can increase the user’s willingness to wait by providing visual feedback.

An example of animation being used to reduce the uncertainty and frustration associated with wait times can be found in Google’s famous email client, Gmail (Figure 10-4). The loading screen uses an animated version of its logo in combination with a simple progress bar while the app loads. The effect of this simple yet distinctive animation creates the perception of a shorter wait time and improves the overall user experience by reassuring people that the app is loading.

Figure 10-4. Gmail uses a simple yet distinctive animation to shorten the perceived wait time (source: Gmail, 2020)

Ten seconds is the commonly recognized limit for keeping the user’s attention focused on the task at hand—anything exceeding this limit, and they’ll want to perform other tasks while waiting.3 When wait times must extend beyond the maximum of 10 seconds, progress bars are still helpful but should be augmented with an estimation of the time remaining until completion and a description of the task that is currently being performed. This additional information helps give users an idea of how much time they have to wait until the task is finished and frees them up to do other tasks in the meantime. Take, for example, Apple’s installation screen (Figure 10-5), which is displayed when an update is underway.

Figure 10-5. Apple provides an estimated time to completion along with a progress bar during updates (source: Apple macOS, 2019)

Another clever technique for improving perceived performance is the optimistic UI. It works by optimistically providing feedback that an action was successful while it is being processed, as opposed to providing feedback only once the action has been completed. For example, Instagram displays comments on photos before they are actually posted (Figure 10-6). This makes the app’s response time seem faster than it actually is: it immediately provides visual feedback that assumes the comment will be successfully posted, and only displays an error afterward in the event that the action isn’t successful. The required processing still happens in the background, but the user’s perception of the app’s performance is improved.

Figure 10-6. Instagram optimistically displays comments on photos before they are actually posted to improve perceived performance (source: Instagram, 2019)

KEY CONSIDERATIONWhen Response Times Are Too Fast

Most issues around response times boil down to them being too slow. It might seem counterintuitive, but it’s important to also consider when response times might be too fast. When the system responds more quickly than the user expects it to, a few problems can occur. First, a change that happens a little too fast may be completely missed—this is especially true when the change is not the result of an action taken by the user but something that happens automatically. Another issue that can occur when a response time is too fast is that it can be difficult for the user to comprehend what happened, since the speed of the change does not allow sufficient time for mental processing. Finally, a too-fast response time can result in mistrust if it doesn’t align with the user’s expectations about the task being performed. Purposefully adding a delay to a process can actually increase its perceived value and instill a sense of trust, even when the process actually takes much less time.4 Take, for example, Facebook’s Security Checkup process (Figure 10-7), which scans your account for potential security vulnerabilities. Facebook uses it as an opportunity to educate people about what is being scanned and adds additional time to the process to instill trust that the scan is thorough.

Figure 10-7. Facebook’s Security Checkup process scans your account for potential security vulnerabilities, extending the time the process actually requires and taking the opportunity to educate you (source: Facebook, 2019)

Conclusion

Performance is not just a technical consideration for our development colleagues—it is an essential design feature. As designers, it is our responsibility to help ensure the people who use our products and services can achieve their tasks as quickly and efficiently as possible. To this end, it’s important that we provide the appropriate feedback, leverage perceived performance, and use progress bars to reduce the overall sense of waiting.

1 Walter J. Doherty and Ahrvind J. Thadani, “The Economic Value of Rapid Response Time,” IBM technical report GE20-0752-0, November 1982, http://www.utsa.edu/mind/von_restorff_translation.htm.

² Brad A. Myers, “The Importance of Percent-Done Progress Indicators for Computer–Human Interfaces,” in CHI ’85: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (New York: Association for Computing Machinery, 1985), 11–17.

³ Robert B. Miller, “Response Time in Man-Computer Conversational Transactions” in Proceedings of the December 9-11, 1968, Fall Joint Computer Conference, Part I, vol. 33 (New York: Association for Computing Machinery, 1968), 267–77.

⁴ Mark Wilson, “The UX Secret That Will Ruin Apps for You,” Fast Company, July 6, 2016, https://www.fastcompany.com/3061519/the-ux-secret-that-will-ruin-apps-for-you.