Interacting with a web application is a conversation. The user interface is your company’s proxy, it communicates on your behalf and just like a real conversation, you communicate as much with your body language as with the words you exchange. Good visual design can provide the right setting for this conversation, but interaction is the body language in this analogy. And one of the defining characteristics of good interaction is responsiveness.
"Is this thing on?"
Software user interfaces require a suspension of disbelief on the part of the user. They need to trust that this virtual console with its buttons and input fields are really hooked up to something meaningful that they can control. And despite the whole thing being run by a computer – which are notoriously stupid – the time they invest in working with it will be productive and have all the intended effects. This illusion starts to wobble when the system doesn’t respond in a timely fashion, and can break entirely when the system fails to respond at all. When the user’s trust in the interface is broken they start looking for other ways to accomplish their task. In our conversation analogy they’re looking around to see if there’s someone else to talk to who might actually know what they are talking about.
How fast is fast enough?
The web has many things to recommend it as a platform for software applications. Speed and stability are hit n’ miss though, and only partially under your control as a business serving customers. Despite that, it turns out that the expectations and rules for what is fast enough are the same as they have always been. They were documented in 19681, and are summarized again in Response Times: The Three Important Limits:
0.1 second: Limit for users feeling that they are directly manipulating objects in the UI. For example, this is the limit from the time the user selects a column in a table until that column should highlight or otherwise give feedback that it’s selected. Ideally, this would also be the response time for sorting the column – if so, users would feel that they are sorting the table.
1 second: Limit for users feeling that they are freely navigating the command space without having to unduly wait for the computer. A delay of 0.2-1.0 seconds does mean that users notice the delay and thus feel the computer is “working” on the command, as opposed to having the command be a direct effect of the users’ actions. Example: If sorting a table according to the selected column can’t be done in 0.1 seconds, it certainly has to be done in 1 second, or users will feel that the UI is sluggish and will lose the sense of “flow” in performing their task. For delays of more than 1 second, indicate to the user that the computer is working on the problem, for example by changing the shape of the cursor.
10 seconds: Limit for users keeping their attention on the task. Anything slower than 10 seconds needs a percent-done indicator as well as a clearly signposted way for the user to interrupt the operation. Assume that users will need to reorient themselves when they return to the UI after a delay of more than 10 seconds. Delays of longer than 10 seconds are only acceptable during natural breaks in the user’s work, for example when switching tasks.
This means that to avoid interrupting the flow of the conversation, the user interface must give some feedback to every selection, click and key-press near-instantly, and get at least some results in front of the user in under a second. After 10 seconds you can assume your user has picked up a magazine or is checking email – the conversation is on hold.
You might hope your users will make accommodations for that fact they are using your application over the network and through their web browser. And if you are lucky they might not condemn you out of hand when it takes a while to get things done, but neither will they enjoy it. Great software is a delight to use and reflects well on everyone involved. We want that.
Speed matters, now what?
Some things are inevitably slow, or so prohibitively difficult and/or expensive to speed up, that compromises must be made. If you keep the feedback flowing, your users will forgive you. But clam up and make them sit and wait not knowing what’s going on, and you erode confidence. If every click hangs unnaccountably, frustration starts to build. You probably already know about some of the bottlenecks in your application, but go back and work through some task flows with these guidelines in mind. It gives you an angle to take on those reports you’ve had of the software being “sluggish” or just “so-so” or even “it worked fine”.
No amount of advertising can leave as strong an impression as a sustained user experience with a shabby product. Jakob Nielson
So your application’s user interfaces don’t feel snappy. Where do you begin? You start by asking questions. Where are the pain points, what are the most used, most critical paths through your application? When a user sits down to use your application, what do they do, how do they do it and how long does it all take?
SitePen can help you identify the performance problems in your application that impact the user experience. We can provide technical analysis and help you focus on implementing optimizations that will make a tangible difference to your users. We are experts at building highly usable, rich internet applications, and can bring a deep collective experience to improving your customer’s experience with your software. Get in contact with us now to get this conversation started.
1. Miller, R. B. (1968). Response time in man-computer conversational transactions. Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277