Response time in UX
#66: About how interface response time affects user experience
Welcome to Fundament, a bi-weekly product design newsletter where we share actionable tips and insightful stories with the worldwide design community. Join 2,200+ readers and grow as a UX and product designer with us!
Response time in UX
People are impatient, they dislike waiting, and they expect things to happen instantly. This is especially true today, when it’s harder than ever to capture and hold someone’s attention. Within just a few seconds, users decide whether the content they’re seeing is valuable to them, and it takes only slightly longer for them to lose focus and abandon a task if the interface responds too slowly or fails to provide clear feedback.
That’s why time, and more specifically the interface’s response time to user actions, matters so much. Let’s take a closer look at it.
How time shapes experiences
Almost everyone experiences delays in a similar way, whether it is during interactions with digital products or in everyday life. When something does not work instantly, freezes, or when a courier simply arrives late, frustration and irritation appear, especially when we do not receive any feedback about what is happening or why.
In the case of digital products, users judge the speed and smoothness of the experience. Products that create a sense of immediacy lead to better overall user experiences. This is not about measuring time with a stopwatch but rather about the subjective perception of users.
Delays in interfaces also have a direct impact on business metrics. According to Akamai report, even a 100 milliseconds delay in website load time can reduce conversion rates by 7%, and a 2 seconds delay can increase bounce rates by 103 percent.
There are several time thresholds worth knowing in order to properly manage the response time of an interface.
Key time thresholds
In 1968, Robert B. Miller published his article Response Time in Man-Computer Conversational Transactions, in which he examined and described three time thresholds that remain relevant to this day:
0.1 second
1 second
10 seconds
In the context of UX, these thresholds were popularized by Jakob Nielsen, who described them in his 1993 book Usability Engineering. Let’s take a closer look.
0.1 second
Any interface response that occurs within 0.1 seconds will be perceived by the user as instantaneous. It also enhances their sense of direct control. This response time applies to direct interactions such as mouse movements, key presses, clicks, dragging elements, or any other interface interactions that happen immediately.
1 second
The next threshold is one second. In the range between 0.1 and 1 second, the user notices a delay but accepts it as a natural processing time. They still feel in control, and their flow remains uninterrupted. This time range usually applies to actions such as navigating between pages.
10 seconds
The last of the three thresholds is 10 seconds. Response times between one and ten seconds are noticeable to users, and while they remain focused on the task, their motivation begins to drop. They start to feel like they are waiting for the system to complete the task. This often applies to actions such as loading complex reports, exporting data, or uploading files.
Once the ten-second threshold is exceeded, users lose focus on the current task and start thinking about something else. When the task finally completes, they need to refocus, which requires additional mental effort. There is also a risk that once users lose concentration after waiting for more than ten seconds, they may not return to the task at all, which can result in abandoning the page or application.
It’s worth noting that the time thresholds mentioned above are not fixed. Much depends on the type of interaction, the context, and the individual user. Immediate execution without any feedback is not always the best option.
How to manage delay
We do not have full control over how long it takes for an action to be completed. Of course, we would like it to be as fast as possible, but that is not always achievable. The system may not be optimized at a given moment, some actions may take longer for technical reasons, or simply the user might have a slower internet connection or weaker device.
That is why we need to understand how the system should behave so users do not feel the negative effects of waiting too long. Referring back to the previously mentioned thresholds, it is crucial to focus on delays that fall within the third one. The first threshold, for obvious reasons, does not require any special handling. The same goes for the second one, where the delay is short enough that additional feedback is unnecessary, as the change is often visible naturally, for example during a page transition. The third threshold, however, has the most significant impact on potential negative user experiences, as delays become clearly noticeable.
For delays between 1 and 10 seconds or longer, it is crucial to provide feedback indicating that the system has responded and is currently processing the action. Without such feedback, users might assume that the system has not reacted to their input, try repeating the action, and if they still see no response after several attempts, they might abandon the task or even leave the product entirely.
On this page you can see what this looks like in practice. You will find several time thresholds demonstrated with and without user feedback.
Since feedback is key, what exactly should we communicate to the user? For shorter waiting times (up to 10 seconds) or in cases where we want to provide feedback just in case, the most common approach is to use animated elements that show the system is working. These can be skeletons or spinners (also known as loaders). Skeletons give users a sense of structure and progress, while spinners only indicate that something is happening without giving any sense of duration. The choice between the two should depend on the context and technical possibilities.
It is important to ensure that loading indicators appear after the appropriate delay, as showing them too early can create a flickering effect when the element appears and disappears within a fraction of a second.
When the waiting time exceeds 10 seconds, and when it is possible to calculate progress in real time (for example, while uploading files), it is better to use components such as progress bars that indicate the current progress along with the remaining time or percentage.
You can also enhance loading states with contextual messages such as “Uploading file,” “Loading data,” or more casual ones like “Almost there…” or “We’re getting things ready for you.” Such messages can make the wait feel shorter and less frustrating.
For operations that take significantly longer, for example several minutes (such as uploading a video), users can be allowed to continue performing other actions while the process runs in the background. Once the task is complete, the system should notify them.
When large and complex views need to be loaded, you can use a technique called progressive loading, which is most often applied in SaaS applications. It means that the entire interface is loaded in chunks, starting from the simplest structural elements and gradually adding more data, finishing with the heaviest assets such as images or content below the viewport.
In recent years, we have also seen the growing use of so-called optimistic UI. This approach displays the result of an action instantly, without waiting for the server’s response. For example, liking a post or adding a comment appears immediately, while the actual operation is processed in the background. If an error occurs, the change is reverted, and the user receives an appropriate message. This technique works especially well for actions with a high success rate.
It is important to remember that while we cannot always improve actual performance (the real speed of the system), we can always improve perceived performance. This refers to the user’s subjective feeling of how fast the interface responds. Small UX techniques, such as skeleton screens, microanimations, or early partial content, help users feel that the system is responding faster even when the total processing time remains the same.
Finally, while this article focuses mainly on websites and desktop or mobile applications, these principles apply to all types of interfaces that humans interact with.
Support our work
If you enjoy our newsletter, consider switching to the Premium plan to show your support! For just $5 a month (or $45 a year), you will get full access to our archives and free access to ebooks from Fundament Library.
Follow us on other channels
Arek’s LinkedIn, Instagram, TikTok, and Twitter (X).
Mateusz’s LinkedIn
This article has been so useful to me, I've been checking my time-related designs with it so many times already. Thank you so much!