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.

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)?

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.

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.

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.

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.