Nobody likes to wait. Especially not for a server that is once again too slow. Least of all your customers. But what can you do if there is no technical improvement in sight? Couldn't you just make your application appear faster than it really is and, on top of that, cleverly use the waiting time in your favor?
Unpopular waiting time
Why is waiting time viewed negatively in the first place? It is often because we have a certain expectation, but are not sure if and when our expectations will be met. Waiting triggers uncertainty in us because we cannot control this time and are thus forced into a passive state of uncertainty from the outside.
What happens when we are exposed to passive waiting for too long without protection? We feel uneasy, feel robbed of our time, become nervous, annoyed, lose confidence and finally lose interest. A perhaps initially positive feeling of anticipation turns into frustration. This is pure poison for any digital application - be it a website, app or desktop application. Once our user loses interest, what's left? Most likely, the user will turn their back on the application or at least lose the thread, wasting valuable time and possibly looking for a better alternative.
A question of expectations?
Sounds really unpleasant, doesn't it? The good news is that there are different types of waiting - and not every type is necessarily perceived as negative. The duration of waiting, as well as the perception of time and its manipulation, help to dampen or even eliminate the negative effects of waiting. Waiting is also highly contextual and a matter of expectation. If we are prepared to wait, waiting is perceived as less negative than if it is unexpected. The Coinstar machine in the U.S. counted the inserted coins so quickly that users were convinced that the machine had counted incorrectly, even though the count was absolutely correct.
As a result, the machine was set so that the result was displayed later, making the whole process take longer. But the users were more satisfied with this, because it met their expectation, and the complaints stopped. So a certain waiting time can be a (supposed) quality feature under certain circumstances. If our users are prepared to wait, then it may well make sense to fulfill this requirement.
Is a technical improvement worthwhile?
If you are now thinking: But I have first-class developers in my company who strive for the maximum possible performance, why develop other strategies? Then you should definitely consider that a time difference that is less than 20% is not explicitly perceived by the user [1]. An effect that is also known as Weber-Fechner law.
Let's say your developers improve the loading time of your product from 12 to 10 seconds, this will hardly be noticed by their user, even if your development manager can declare this technical improvement as progress. However, if the loading time is reduced to 8 seconds, the presumably high technical effort has paid off and your users will thank you for it. But what about all other cases? Do we really have to put our user through any waiting time and hope for the best? The clear answer is: No!
"Use the waiting time" and improve the user experience!
"Use the waiting time" is our magic formula at this point. Accept that waiting is unavoidable at some points. As described at the beginning, waiting creates uncertainty in us when we feel passively at the mercy of the waiting time. In addition to this passive waiting, however, there is also active waiting (Figure 1). In this case, although a process is running in the background and the user has to wait for its result, he or she feels actively involved in what is happening. Perhaps even better: he or she does not even enter the conscious state of waiting. This has a very positive effect on the user experience of your app.
Compared to active waiting, passive waiting is perceived to be about one third longer [2]. And that is why it is particularly important to shorten passive waiting. Our task is therefore to convert as much of the waiting time as possible into active waiting. We have a small advantage in addition: it takes one second for the human brain to realize that there is actually (passive) waiting [3]. This means we have a small head start to spare our users from getting into this unpleasant state.
Stay alert!
Attention span in the digital environment Let's take a closer look at the human attention span. What waiting times are tolerable for our brain and at what point do we start to drift off mentally? As shown in Figure 2, a waiting period of up to 0.2 seconds is not perceived as such. Humans perceive this short period of time as instantaneous. Up to one second, we perceive an interaction, but not yet a wait. From one second we then start to realize: aha, we have to wait, thoughts wander, we become impatient. In short: the state is no longer optimal and we start to lose focus. From 5 seconds on, it becomes really critical: why does it take so long? We are annoyed and lose the desire. That's why: let's give the user a feeling of active participation, influence, security, anticipation and trust, instead of alienating or even alienating them. How to do that? We'll show you the techniques and possibilities step by step below.
Are progress indicators the salvation?
Who doesn't know them, the various forms of progress indicators? They give us a good feeling that something is happening and we are getting closer to the goal. In the best case, they inspire confidence and anticipation. In addition to the classics such as spinners and loading bars, another, more indirect type of progress indicator is now conquering the field: the transition. Here, the transition from state A to state B is represented by a flowing animation, which in the best case even provides the user with further information, so that he does not even notice how much time has passed.
Through the animation, the user has become a spectator and as long as something "happens", this time is not perceived as waiting time, but as a natural transition, which incidentally still communicates, for example, the successful sending of an e-mail. The transition is thus ideally suited for waiting times of less than one second. However, the gyro, often referred to as a spinner (Figure 3), also has its raison d'être.
It indicates that something is happening, even if it is not clear what to wait for and for how long. It is especially suitable for short waiting times of less than 3 seconds that cannot be covered by a transition or other methods. It also offers the possibility to convey a company-specific design and entertainment with brand identity.
Now to the classic among the progress indicators: the loading bar. It gives us direct information about the progress and, in the best case, lets us estimate the remaining waiting time. In some cases, it is enriched with additional information about which step is currently being executed. The loading bar is especially popular for the certainty that the wait will end in the foreseeable future. To reinforce this certainty, a stripe pattern can be added that moves in the opposite direction (Figure 4). This creates the impression that the loading bar would move 12% faster than the same loading bar without this trick [4]. This effect can be compared to a passenger whose train passes an oncoming train. Moving in opposite directions at the same time creates the impression of moving much faster. This UI design trick is a true user experience booster!
To increase the user's relief and sense of achievement at the end of the waiting process, some loading bars intentionally overestimate the remaining waiting time or delay progress at the beginning to become faster towards the end. This way, the impression is created that the entire process was unexpectedly fast. A nice psychological trick. But for all its sophistication, the best loading bar is the one that never comes into use, because such progress indicators make it definitively clear to the user that he or she is waiting. But what can we do to make loading bars superfluous?
Tell a story!
Instead of frustrating the user, we can increase their anticipation of the new product by telling them an exciting story while they wait (Figure 5). Today, for example, we find a successful implementation of storytelling in the installation of the open-source Linux distribution Ubuntu. While the installation is running in the background, the installation window explains how great the new version is, what benefits and new features will excite the user in the future.
Storytelling not only distracts the user, but it also provides a great opportunity to showcase the product and offer added value. Of course, the user experience is even higher when waiting time is not perceived as such, but at the same time added value is offered. Using the time to build a connection with the user and increase their anticipation is high art! To achieve this, you should think carefully about what information is relevant to the user and how it can help them. Again, context is everything. Go ahead and explain special features to your users, share useful background information, and show what added value your product offers. With the help of a good story, the loading time underlines the quality of the product. You probably remember the Coinstar example above.
True to the motto "good things come to those who wait", it will definitely be worth the wait. You should definitely convey this to your users. The games industry in particular makes use of this method. Of course, this results in particularly exciting and imaginative stories that pick up on the content of the game and create the right mood. While a lot is going on in the background, the player is already getting ready for his mission and gets to know the rules of the game.
"I'm already here!" cried the hedgehog
Now let's move on to the advanced techniques, where the user doesn't even notice the waiting time (Figure 6). Does that sound like fairy tales and magic to you? Our suggestions are certainly based on that. First, let's take a look at the end of the wait. Here the question quickly arises: why wait until the end at all? Don't we have something to offer much earlier? In most cases, the answer is: yes! We already have something and we can start with that. Why should the user wait until the very last part of the interface is loaded when he or she could interact with the already loaded elements much earlier?
A good example of this is YouTube (Figure 7). As soon as the first few seconds of the video are loaded, it is started. If we had to wait until it was completely loaded, we would certainly be over the hill very quickly.
We can also use this trick for entire web pages and include everything we need in the HTML. A good tool for this is Inline CSS. Here we can include all the necessary CSS rules, also called "Critical Path CSS", to make our page look good initially - at least as far as the user sees it. This area is also called "above the fold" (Figure 8). Everything else will follow once the rest of the CSS is loaded. For a first throw we can use the "Critical Path CSS Generator" [5]. Inline CSS can cut the time to first render by a good 40%. A crucial advantage, especially if your users want to get information quickly.
Develop psychic abilities
Another way to present content as early as possible is a method often referred to as "skeleton loading" or "content placeholder" (Figure 9). Here, the places where content is loaded are already pre-structured as such and the content is displayed schematically. In this way, the user already knows what to expect and can focus accordingly. The schematic representation also serves as a progress indicator that tells the user that the desired content will soon be loaded.
Let's be realistically optimistic!
In many cases, we make the user wait for a response from the back end. After all, we want to be on the safe side and make sure that his data has really been saved correctly. But let's assume that in 99.9% of cases a predictably positive response comes back from the server. Does it then make sense to make every user wait or is it sufficient to check in with the user in the rare 0.01%? Especially if the feedback from the backend is not of significant importance to the user, it is worth taking an optimistic stance and not bothering the user further with it. This approach is also known as "Optimistic UI". Especially small interactions such as "likes" no longer have to wait for a server response, but can give a positive feedback right away. If problems do occur, they can either be solved "invisibly" by continuing to try to perform the action or the user can be informed more or less conspicuously.
Twitter, for example, takes an optimistic stance. When the user likes a post by clicking the heart icon, it immediately turns red and signals: "You have liked this post. Although there is no response from the server yet, the heart icon turns red. If, contrary to expectations, there is no response from the server, Twitter will remove the red coloration of the heart, assuming that one more or less Like will not be essential for the user.
Taking users by the hand
.png)
If your application loads in under a second, great! Since this is often not technically feasible, there are fortunately a number of ways to take advantage of the human perception of time and make applications appear faster than they really are. To do this, focus on the three essentials: Speed, entertainment, and explanation (Figure 10).
In summary:
- Be as fast as you can.
- Show progress and what is happening in the background.
- Don't let boredom set in.
- Explain to your users why waiting is necessary in this case.
- Offer added value and fill the waiting time with meaningful content.
This way, your users will perceive the waiting time to be much shorter or hardly notice it as such. In this way, you generate trust and no longer leave your users in the dark.
With this in mind, take your users by the hand and guide them through your application just as you would guide a child through a new environment: gently and trustingly.
[1] "Designing and Engineering Time: The Psychology of Time Perception in Software" by Steven C. Seow.
[2] "Perspectives on Queues: Social Justice and the Psychology of Queueing" by Richard Larson (MIT).
[3] "Usability Engineering" by Jabob Nielson
[4] "Faster Progress Bars: Manipulating Perceived Duration with Visual Augmentations" by Chris Harrison, Zhiquan Yeo & Scott E. Hudson (Carnegie Mellon University).
[5] https://www.sitelocity.com/critical-path-css-generator
.svg)
.svg){kind=small}