Display a processing state immediately after user action
Posted on November 17, 2023
Takeaways
Always display a processing state immediately after users interacted with a component instead of waiting for another process to acknowledge users’ interaction.
This article is part of a series on user interface micro interactions and how they affect the user experience.
Cet article est également disponible en français.
“Did I click the button? Is my request taken into account by the system?”
These are the kinds of questions that many users ask themselves when the interface shows no reaction after interacting with a component.
Quite a few researchers investigated what is the acceptable delay before something is not perceived as instantaneous. In his article Response Times: The 3 Important Limits, Jakob Nielsen summarized it best:
- 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.
In contexts other than human-computer interaction (HCI), those values may change. For example, musicians can perceive delays with as little as a 5 milliseconds delay!
In order to avoid any kind of confusion for users as to whether or not their interaction with an interface was successful, always display a processing state immediately after users interacted with a component that must wait for an event to complete. Not after the back-end has acknowledged being contacted, immediately after interaction.
Let’s illustrate this design pattern with a few examples.
Example: non-ideal series of events for updating an interface after user action
This design pattern became popular, or at least more noticeable, since the event of reactive front-end JavaScript frameworks within the last fiften years or so. The design pattern Developers follow with those frameworks tend to be connecting every user interaction in the interface directly with an update to the database.
For example, in a form, instead of waiting for users to click a “submit” button, every time a user finishes updating an input field, the values are sent directly to the database via a call to back-end services. This is obviously an over simplification, but it explains the design pattern.
In such cases, Developers rarely update the front-end to inform users that their is a process going on behind the curtains, most often because the belief is that such small updates are immediate.
However, as illustrated by research, immediacy is a really short period, and unless we can guarantee a delay of less than 100 milliseconds, we are likely to design systems where the user interface is not updated after user interaction, but rather after a back-end system’s acknowledgement of that interaction. That is not ideal.
Example: ideal series of events for updating an interface after user action
Instead of waiting for a back-end system’s acknowledgement that users interacted with the interface, whatever element that waits for that system’s process completion should be set to a processing state immediately after users triggered the call to the system.
In the series of events illustrated above, users would click on the “submit” button, which immediately informs users that their action has been taken into account. No delay, no floating period of doubt for the user.
Furthermore, in the case of a form with multiple fields, it may be ideal to disable the fields that are taken into account during that processing state, which further reinforces the reassurance given to users that their input is being processed. This needs to be considered case by case, as it may differ depending on what the component does in a specific design and implementation.
References and Additional Readings
Articles
Defining “Instantaneous” as part of usability acceptance criteria | User Experience – StackExchange
Designing Better Loading and Progress Indicators UX | Vitaly Friedman – LinkedIn
Designing Fluid Interfaces | Apple
Loading & progress indicators — UI Components series | Taras Bakusevych – UX Collective
Powers of 10: Time Scales in User Experience | Jakob Nielsen – Nielsen Norman Group
Response Times: The 3 Important Limits | Jakob Nielsen – Nielsen Norman Group
What is the shortest perceivable application response delay? | Stackoverflow
Research Papers
Delays in Human-Computer Interaction and Their Effects on Brain Activity | Korhs et al. – Pub Med
Card, S. K., Robertson, G. G., and Mackinlay, J. D. (1991). The information visualizer: An information workspace. Proc. ACM CHI’91 Conf. (New Orleans, LA, 28 April-2 May), 181-188.
Miller, R. B. (1968). Response time in man-computer conversational transactions. Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277.
Myers, B. A. (1985). The importance of percent-done progress indicators for computer-human interfaces. Proc. ACM CHI’85 Conf. (San Francisco, CA, 14-18 April), 11-17.
Last updated on February 13, 2024