Article: The Truth about Download Time
February 14th, 2006
UIEtips 2/14/06: The Truth about Download Time
As we study how people interact with web sites, we keep having to remind ourselves one important thing: we need to be very careful when we listen to our users. I don’t mean that we have to listen to them carefully. Instead, I mean we have to interpret what they are saying with caution and care.
When users say what they like or don’t like about a design, they mean well. I think they really intend to help us understand how to make things better.
Unfortunately, they are the wrong people to help us. Study after study shows us that users can’t attend to the details necessary to arrive at the right solution. Instead, they’ll often suggest changes that, when executed, fail to make any improvements at all and, all too often, make the experience worse.
In today’s UIEtips, we’ve dug into the archive and brought you an article to help us remember to be careful in our interpretations. In The Truth about Download Time, originally written in 2001 by Christine Perfetti and Lori Landesman, we revisit our discovery that just because users believe a site to be slow doesn’t mean speeding it up will make them happy.
Since we conducted the original research five years ago, we’ve repeatedly discovered users are more interested in achieving their goals than having speedy page loads. Since goals are often complex and require the users to be thoughtful, the best designed sites seem to get away with slower-than-average pages.
So, if we’re not supposed to listen to our users, what are we supposed to do to learn what to improve? Watch the users. Study them. Understand what they are trying to do. Learn what happens when they try and fail. (Or succeed.)
It would be a wonderful world if we could just say to our users, “Tell us what we need to fix” and they’d give us a complete list. Every design would be perfect within weeks of deployment. Unfortunately, it’s far more complex than that scenario would allow.
This is why we’ve packed our new Roadshow with a ton of tips about collecting and disseminating information from our users. The more we learn and the more everyone on the team understands, the better our designs will be.
You can learn more about the UIE Roadshow program and all the techniques for improving your web site design here. Almost every city is full (we found more space for Seattle, but it’s still going to be tight), so you’ll want to register right away. (This Thursday, 2/16, is a big day: the prices for the DC and Philadelphia events increase and it’s the last day to register for Atlanta online. Don’t delay.)
What’s been your experience with listening to what users actually say? Have you found you need to look beyond their words and understand what’s really going on? Or are we completely off base? We’d love to hear your thoughts. Just leave us a comment.
Read the article here.
You’ll want to register for the UIE Roadshow by this Thursday, 2/16, to ensure you get the best prices available and reserve your seat in the city of your choice. We’re close to selling out in every venue. Register here.
February 14th, 2006 at 3:24 pm
I have found that the best response to a client telling me that the website should include x or that y needs the following improvement is to ask a simple question: What is the problem you are trying to solve? And how did you determine that x or y is a problem?
Frequently clients base their sudden need for changing something or adding something to their site based on a single email’s feedback, or a comment from a friend or colleague, or something they read in the paper that morning. Their complaint may or may not be truly problematic and may or may not need addressing. Also, when the complaint is real and legitimate, clients don’t often have a good technological grasp of what needs to be done to suggest a good solution. (After all, if they did, why would they need to hire us to do it?)
If the conversation happens in a mutually respectful way, the client is often open to a different solution to the problem than the one they originally suggest. After all, they really just want the problem to go away, and they aren’t usually so attached to their own solution that it must be implemented exactly as they want… provided they understand the reasoning behind the alternative solution.
February 14th, 2006 at 5:38 pm
Hear, hear! My experiences and conclusions have been spot on with Jen Kramer’s. Many times clients offer solutions as a way of pointing out problems. But the right solution usually not the offered solution (though every once in a while it is).
Once a client suggested that searches should return similar matches as well as exact matches. The following week, he suggested that searches should only return exact matches, seemingly unaware of the contradiction. After a little thought and conversation, I realized that there was no contradiction. The client didn’t want to make multiple searches for similar terms, but also didn’t want to wade through near matches when he did know the exact term. The solution was to return near matches, but to order results so that exact matches appeared first and were visually separate from near matches.
Often, the *right* solution may not be immediately obvious. In that case, it is not possible to have a mutually respectful conversation AT THAT TIME. It is best to put off the conversation until you do have a workable solution. In that case I find it is best to voice my concerns about the proposed solution and offer to get to work. Then when I have a better solution, get back to the client with that and explain how it avoids the problems of the original while fixing what needs to be fixed. The carpenter’s adage “Think thrice, measure twice, cut once” is applicable in more fields than wood working.
February 14th, 2006 at 5:49 pm
The study is flawed. The testers were required to perform tasks on the sites, so they had to wait for the sites to load. In the real world, users abandon slow-loading sites without visiting unless they are absolutely sure they can’t find what they need elsewhere. Too ignore download time is throwing away potential visitors.
February 14th, 2006 at 5:54 pm
I’ve just read “The Secrets of Consulting” and something that actually really helped with my current job was a comment about how users phrase problems. That is, usually without implicating themselves as the root cause. If you extrapolate that to completing a task on a website, blaming the page download speed rather than their ability to complete the task (not their fault – but that’s not what most people think) fits rather nicely together.
February 14th, 2006 at 11:20 pm
John Wells: Subsequent studies where we’ve allowed users to choose to abandon the site have shown that perceived page-load times still show no correlation with actual page-load times.
In those studies, we saw a repeat of the same results: users only became impatient with the download time (which was often quite quick) when they felt they weren’t making progress. Often this was due to other usability issues with the site.
When the site design was effective, the actual page-load times (which were often quite slow) didn’t seem to play into user’s perceptions.
I’m not so quick to throw out these results.
February 15th, 2006 at 3:40 am
I agree, of course, that a badly designed site does not get better if you speed up download times. And I agree, that it is far more important to address a user’s goal than to have the fastest-downloading site in world. But the article does not say anything about how download times were measured. Did you measure the time until the whole page was downloaded or did you measure the time until a relevant part of the page was displayed (while the rest of the site was still loading)? My experience with testing slow bandwidth connections is that many (well-done) sites display relevant information very quickly even if the whole page-download may last 30 or 40 seconds.
February 15th, 2006 at 7:56 am
Rainer:
Excellent question.
We measured both. For example, Amazon (one of the fastest rated sites in the study) took, on average, 36 seconds to load entirely, but after 11 seconds there was enough useful stuff on the screen for the user to work with.
However, About.com, (one of the slowest rated sites) still loaded in it’s entirety in an average of 8 seconds.
So, even looking at partially loaded page times, there still is no correlation between actual download time and perceived download time.
February 16th, 2006 at 6:33 am
Jared, thanks for adding this interesting piece of information.
February 19th, 2006 at 7:22 pm
I agree with the first two posts. Getting the client to describe the problem that has to be solved is better.
Once the problem has been described, I can propose an array of possible solutions, describe the advantages of each one and how they address the problem, and let the client elect and make proposals.
March 8th, 2006 at 1:38 pm
[...] …users are more interested in achieving their goals than having speedy page loadsZo, een “bold statement” als kop, dat werkt vast goed… Jared Spool schrijft misschien ten overvloede nog maar eens over de download snelheid van websites en de invloed op de gebruiksvriendelijkheid. Die invloed is er wel degelijk, maar is niet zo groot als je soms zou vermoeden. Het is echter wel een onderwerp waar gebruikers over klagen. En omdat we (hopelijk) hebben geleerd naar onze gebruikers te luisteren, wordt die download snelheid als belangrijk op te lossen probleem gezien. Jared quote hierbij een artikel uit 2001: The Truth About Download Time. [...]