It is true that we generally want to minimize the time that users have to wait because slower load times equates to a bad user experience. We want to make it faster for users to get to your site or product, do what they want and leave. We want to ensure that we optimize our processing in a way that users feel as if they are the ones in control and that they are not at the whims of a machine that is holding them back from being productive.
However, research has shown that it is not necessarily slower response times that drives users crazy. It is inconsistent times that drive users mad. If clicking a button results in a 5 second delay before something happens and users come to expect that, then they are generally okay with it. But if that same button process executes in widely varying times (i.e. 0.1 seconds, 3 seconds, 10 seconds, 1 second) each time, users find that unbearable and confusing. (The Nielsen Norman group has written a fantastic article on various facets of page response times that everyone should read.)
Therefore, I’d like to offer a slightly different take on these response times. What if intentionally slowing down that time can improve a user experience? Here is what I mean.
Imagine two scenarios. In the first scenario, you are waiting at the doctor’s office. The doctor comes in. You list out your symptoms and issues. The doctor writes them down, tells you that they know what the issue is, prescribes the appropriate medication or treatment, and sends you on your way. The whole process takes about five minutes.
In the second scenario, you are waiting at the same doctor’s office. The doctor comes in. You list out your symptoms and issues. The doctor writes them down, thinks for a moment, and asks you some follow-up questions. The doctor checks the part of your body that hurts, performs some basic diagnostic tests, and reassures you during the process. The doctor tells you what the issue is, prescribes the appropriate medication or treatment, takes any final questions, and then sends you on your way. The whole process takes about 20-30 minutes.
Both doctors knew immediately what was wrong from the moment they heard your symptoms. However, which doctor would you rather see?
For some, getting in and out is the most important factor. However, I would argue that in this case, the latter doctor would be more warmly received by patients because of the extra time he or she spent with you.
Perception matters. Though both doctors ended up getting the diagnosis and treatment correct, the second doctor ensured that you, as the patient, were heard, understood, and felt that you were being cared for. The second doctor was perceived to be more thorough and sensitive than the first.
Or, consider sitting down at a restaurant and ordering some food. The food arrives within ten seconds of you ordering it. Is that a better user experience than a place where the food arrives in fifteen minutes? Perhaps, you may be tempted to question whether or not the food in the first restaurant was fresh or flash-frozen. Are you really getting the best quality of food?
In these scenarios, I hope to present counterexamples to the thought that faster is always better.
Similarly, I believe that there are times when intentionally slowing down response times a bit can make users feel that the decision-making that goes on behind-the-scenes is “working” or that it is being personalized for their best experience. Consider a web application that relies on a sophisticated machine learning engine to suggest a new movie or a web application that uses a very fast algorithm to perform various security checks. Perhaps those calculations are done within milliseconds but should the results be displayed that quickly?
I argue that they shouldn’t and that UX designers or engineers may consider elongating that time slightly or presenting some sort of animation where it shows a cute robot thinking very hard about calculations so that the perception of users about the service that they are receiving can be improved.
I realize that this flies in the face of what is conventional knowledge that users hate having to wait or that faster is always better. I am not suggesting that all response times should always be throttled down for the sake of improving a user experience. I am merely positing that it could be a consideration that warrants some more study depending on what your product or system hopes to convey. However, these delays in response times can walk a very thin line. Too long and users are upset and may leave your site. Too short and you may turn them off to whether or not your product actually works.
When it comes to things where waiting is normal if not expected (e.g. loan pre-approval, background checks, idea generation, mechanical diagnosis), slower can be better.