No matter how hard we try to deliver lightning-fast performance, there will always be those tasks that take too long. We may have run out of ways to further reduce actual time, but there are still ways to reduce perceived time.
The best way to handle this situation is to spin the task off into the background. This lets the user get on with what he’s doing almost immediately, before the task completes. Of course, the user will want to know when the task is finished, so we must provide some kind of notification system – perhaps an e-mail, perhaps a progress indicator on every page he visits, perhaps a web page that shows the status of all his background processes.
If creating a background task won’t work for one reason or another, we’ll have to perform the task while the user is waiting. Let the user know in advance what the system is going to do and how long it will take. This not only gives him a good reason for waiting, but it also sets his expectations to an appropriate level.
Do not say things like “please wait” or “stand by” because that draws attention to the fact that there is a delay. Simply state what is happening (e.g., “saving your work”).
Give the user a reasonably accurate prediction of how long the task will take. He has other things he can do, some taking a few seconds (e.g., check e-mail) and some taking a few minutes (e.g., grab a coffee). If he knows how long the system will take, he can select an appropriate alternate task to fill the gap. Occupied time (time that is filled with an activity) is perceived to be shorter than unoccupied time (time spent drumming one’s fingers or staring at an hourglass).
Inaccurate estimates disappoint the user. If the estimate is too short, he finds the system still occupied when he returns. If the estimate is too long, he returns late and loses the opportunity to get on with what he’s really trying to accomplish.
A progress indicator gives the user assurance and control. As he sees it move, he is assured that his task is progressing. Like the up-front time estimate, he can control how he uses the remaining time. As he finishes each alternate task, he can check the progress indicator to see if there is enough time left for yet another alternate task.
Providing an option to cancel is also helpful. If the user changes his mind and decides that it is not worth waiting, he can cancel the task and get on with other things instead of waiting for it to complete.
Perceived time is longer when the user sees no progress toward his end goal.
For a short time after requesting a new web page, a user can see the previous page, an empty white screen, or parts of the new page as they become available. Which is perceived to be fastest? Which is perceived to be slowest?
The current consensus is that the “white screen of death,” so called because this is where some web pages hang, is perceived to be the slowest, and watching the new page load is perceived to be the fastest. The user needs reassurance that something is happening or he gets antsy and starts clicking on the refresh button, which starts the whole slow process all over again.
Users need to see something in the blink of an eye. This assures them that the request is being processed. They need to see something that appears to be a fully loaded web page shortly after that. This lets them know that they can get on with what they want to do. They need to have the functionality they’re looking for available to them a little bit later, just in time when they start typing or clicking. They don’t really care when the rest of the stuff loads as long as it doesn’t interfere with what they’re trying to do.
Web pages should download and render the immediately visible components first. This doesn’t include anything “below the fold” or in drop-down lists or other containers. Once the immediately visible components are in place and onLoad has fired, then download and render the components the user is expected to use first. Create web pages in this order:
Keep in mind that external style sheets block rendering. Since we want that first graphic visible in the blink of an eye, use inline style sheets only and keep them simple. Style sheets should be defined in the <head> section.
Too much information all at the same time is perceived to be slower, perhaps because it must be skimmed in its entirety before the user can decide what to do next. If too much of that information is irrelevant to his immediate task, he will blame the website for wasting his time.
Unnecessary sounds, disorderly arrangement of elements, decorations, too many options, and too many visuals all contribute to clutter. Animation is the worst offender because it constantly draws the user’s eyes away from what they’re supposed to be doing.
Icons are small, widely-understood visual representations of an underlying concept. If they are not widely understood, they are not icons; they are merely clutter. There is a tendency to create visual representations for every little thing on the web page. While repeat visitors will eventually learn some, perhaps most, of the meanings, newbies will feel lost and will perceive the page to be slower than it really is.
Keeping the user “in the flow,” also called “in the zone” or “in the groove,” increases satisfaction. Anything that distracts him from his flow reduces satisfaction. Cluttering the screen is one sure way of interrupting flow.
Tell users what you are going to do, then do it, then tell them what you’ve done. When you tell them what you’ve done, make sure to mention what benefit it gives them. Example: (1) “I will file your application now.” (2) File the application. (3) “Your application has been filed. You are now eligible for the scholarship competition.”
If the user waited more than a few seconds, draw attention to what he has accomplished rather than the fact that he had to wait. Example: Don’t say, “We apologize for the delay.” Instead say, “We made sure you are getting the lowest price possible.”
Perceived time is longer when the task is unpleasant or boring. Use humour, but avoid what your audience thinks is politically incorrect. Also consider your audience when deciding how much humour to use. Personally, I’d like to see a streetsweeper come out and sweep away the old page while I’m waiting for the new one to load. Other audiences may have a different idea of fun. Know your audience!
Perceived time is longer when the task is unsuccessful, so make sure the user accomplishes what he set out to do. System failures, 404′s, out-of-stock items, and finding out at the last minute that the system doesn’t do what you want it to do all frustrate, even infuriate, users. Make sure the users are able to get to end-of-job every time.
Being fast is good, but there is one drawback. If most of the web pages are fast, they set high expectations that are not met by the slower pages. In effect, the ultra-fast pages draw the user’s attention to the slowness of the other pages.
The first step, of course, is to speed up those slow pages. Once that is done, though, slowing down the sub-second pages may be an option, too. I know of no research dealing with this, so please consider it a thought rather than a recommendation.
Most developers have discovered that caching makes a huge difference for website performance. However, don’t stop there. Caching does nothing to help first-time visitors because their caches aren’t primed yet. If you want your first-time visitors to become second-time visitors, make sure they, too, get a good user experience.
Add to this the psychological factor that unfamiliar tasks seem slower than familiar tasks. The first-time visitor is not familiar with the website, so we’ve got one strike against us before we even get started. Ignoring the first-time visitor’s experience puts a damper on the website’s growth.
Some people have taken to putting the load time on every page. It helps ensure that perceived time and remembered time don’t become inflated.
If you do this, only do it for the fast pages. You don’t want to advertise load time on slow pages.
User satisfaction can be improved by reducing perceived time or by lowering the user’s expectations (i.e., raising expected time). The former is more important than the latter because if we set expectations too low, the user won’t even try our website. They’ll go to another website where the expected time is shorter.
Modifying perceived time is possible with the tips presented above. Remember:
And a gem to embroider onto your sampler: Never promise what you can’t deliver. …Never!
Improve your website performance by staying on top of issues 24/7. Sign-up for Monitor.Us for FREE now!