A whopper of a lesson in user-interface design, part 3

To recap: I wanted to upgrade my computer's graphics card. First the computer manufacturer recommended a card that wouldn't fit, then they replaced it with a card that fit but required a power-supply upgrade, and the new power supply didn't fit.

Is the third time the charm?

To figure out what to do about the non-fitting power supply, I contacted the vendor's tech support yet again. I explained that on their recommendation, I had just purchased a graphics card that said (on the box) that it required a 350-watt power supply, but my machine had only a 250-watt one and the replacement didn't fit.

The response: "We checked your machine's configuration; it has a 305-watt power supply, which is adequate for this graphics card." I said that the label on the power supply said it was 250 watts, but they insisted that their records showed that it was 305 watts.

I did not ask how they managed to get from 305 watts to 350 watts. Instead, I reasoned that the graphics card's power-supply requirements were not absolute. After all, how could the graphics card's manufacturer know what other devices were on the machine. The manufacturer's technical-support people had assured me that this card would work with my existing power supply; if I tried it and it did not work, it would be their problem. Bad reasoning based on wishful thinking, I know, but so be it. I was worried that if I tried to return the card after tech support had said it would work, they would charge me a restocking fee, or--still worse--refuse the return altogether.

So I tried the new graphics card. Somewhat to my surprise, it appeared to work, though the speed of my computer's cooling fan reminded me that the power supply was now working hard. Nevertheless, I thought I'd contact tech support again to ask about that gap between 305 and 350 watts, and to see if there was another power supply available.

The second tech-support rep's story flatly contradicted the first: (1) This graphics card requires a 350-watt power supply, not 305; (2) 305 watts is the largest power supply that could be installed in this machine, and therefore (3) I had to send back the graphics card that I had just installed and buy another one with smaller capacity.

We've already seen lesson one: Making incorrect recommendations is worse than making no recommendations at all. We can now add to that as lession eight: Once you've made an incorrect recommendation, correcting it later doesn't help much because there's no reason to believe the correction.

Anyway, I asked for a recommendation for an appropriate graphics card. Silly me. But then I had an idea: I phoned the manufacturer of the graphics card, described the situation to them, and asked for their recommendation. They recommended the same model. Now, at last, I had independent corroboration.

So I ordered the new card, hoping that my machine wouldn't fry itself before it arrived. This time, I got lucky: When I installed the new card, it worked just fine, and the machine was significantly quieter too.

Now, let's look at what would have happened had the computer manufacturer refrained from advising me about graphics cards. I would probably have rummaged around the web and come up with the same card I eventually bought. The chances of doing so would be even greater if the computer manufacturer had a web page saying something like "Here are the different types of graphical interfaces," "Here is how to find out what will fit on your machine," and other such general advice.

I would probably have been slightly annoyed that they didn't know enough about their own products to make specific recommendations, but that annoyance would be nothing compared with how I ultimately wound up feeling. In effect, by trying to be helpful, they wasted my time and their own, and damaged their reputation.

Now let's see how these lessons might apply to other aspects of system design.

First and foremost is the idea of thinking about systems from the user's viewpoint rather than from the designer's viewpoint. I am fond of saying that when a company's representative explains why the company can't help me by describing the company's organization chart, the company is in trouble. When I have a problem with a company's products, and I call their customer-service number, I expect to be connected with someone who can help me solve my problem--not with someone who listens at length to my problem and then tells me that I need to contact someone in another department.

The other important idea is that incorrect information is worse than no information at all. This notion usually extends to other aspects of system design as well. For example, it is usually better for a program to refuse to produce output at all than it is for the program to produce incorrect output without complaint. Moreover, once a program has produced incorrect output, correcting it after the fact may not make things any better.

The third idea, and perhaps the most important one, is that complexity is an ever-present problem. Think about all of the details involved in these transactions, and all the specialized knowledge that was necessary to arrange for them in the first place. Such complexity seems to have been creeping for decades into every aspect of every computer system I encounter. It is so pervasive that it has no chance at all of going away--the best we can hope for in practice is to find useful ways of managing it.

Managing complexity is, of course, another huge topic, so let's save that one for later.

Posted by Andrew Koenig at 02:06 PM  Permalink