[copperpress-advertserve-ad zone="3"]
 January 1, 1998

Geek News: Software only will get better when users get to have a say

I’ve recently been taking part in a discussion about programmers and software development.

The discussion — on an Internet mailing list devoted to the computer-book business — began when a member complained about an interview he’d heard on the radio, during which a writer said that programmers hate end users, and, furthermore, that programmers don’t get

input from users when designing software.

On the same day, I received e-mail from a programmer who had sent me a review copy of his software. I had pointed out an important feature that the program lacked, and his response was, “not a single customer asked for this feature in our user survey.”

This comment reminded me of the scores of times I’ve reported bugs to programmers, only to be told, “but none of our users have reported this bug” (not that the bugs didn’t exist, you understand; this comment is generally made with a tone of exasperation in the programmer’s voice — unable to deny the existence of the bug, but frustrated that his or her expensive usability testing hasn’t uncovered it).

So what’s going on here? Do programmers consult users? And if they do, do they get good feedback?

First, let me say that I think most software on the market today is released with glaring user-interface problems. Most programs have mistakes so obvious, there’s no good excuse for the software to be released in that condition.

I want to concentrate on two important causes of these problems:

1. Software publishers often don’t consult users.

2. Software publishers sometimes rely too much on users.

Not consulting a user when creating a program is like designing a car without getting feedback from potential buyers. No self-respecting car company would do that these days; they use focus groups, give cars to ordinary people to use for a while, and so on. In the software industry, though, it’s considered OK to write a program with almost no user input.

On the other hand, some companies do consult users. In fact some companies spend millions of dollars testing their products with ordinary users, in alpha and beta tests, and even in costly usability labs. Still these companies release software with glaring errors. How can that be?

To some extent, I think software companies employ end-user testing as a cop-out. If the program is given to a group of users, and the users can’t come up with any good ways to improve the product, then obviously the product is good. But end users are not designers. In the same way that the average driver is not an automotive designer, the average software user is not a software designer. You can’t expect a user to tell you how to design your product.

Why bother testing, then?

Testing should be just one part of the design process. The purpose of testing is to see how users react to the program you’ve created and to find bugs. Certainly you hope that you’ll get good suggestions for new or improved features. But most user feedback is along the lines of “I tried that command, and the program crashed,” or “Why do you make it so complicated to do that?”

Rarely do users provide specific ideas for new features. And even if you do get some good ideas, there’ll always be plenty of ways to improve the program.

You can’t expect users to design your software for you. They don’t understand software design; they don’t understand what software can do. They don’t understand just how easy software can be to work with, in fact, because they’re used to working with complicated, clumsy programs.

I find working with most of the software I have to deal with a real frustration. I’m glad to say, I’m not alone. The consensus of opinion in the computer-book discussion group — which has hundreds of people who work in software design and documentation, including many programmers — is that software is generally pretty awful. And that it really could be so

much better.

What’s the solution? When will software get easier to use? When software companies do two things: When they start working closely with users, to learn the needs of users, and to see what happens when users work with their software. And when they realize that users can’t design programs, so focusing too closely on user feedback to drive the design is sometimes a

mistake.

There’s a very simple and inexpensive step that can be taken to improve software. It’s called heuristic analysis, a process in which someone who is very knowledgeable about software and its capabilities — someone who is not on the development team — plays with a program and recommends changes.

There are people in the software business who have worked with many hundreds, perhaps several thousands of different programs; people who’ve worked with software design teams for years, and who have seen just about every way that software can accomplish particular tasks.

The missing link in software design is this heuristic analysis. This type of analysis costs a small fraction of full usability testing, yet it can often accomplish much more.

Peter Kent is the author of “Poor Richard’s Web Site: Geek-Free, Commonsense Advice on Building a Low-Cost Web Site.” To register to win a free copy, go to http://www.poorrichard.com/info/geek.htm

I’ve recently been taking part in a discussion about programmers and software development.

The discussion — on an Internet mailing list devoted to the computer-book business — began when a member complained about an interview he’d heard on the radio, during which a writer said that programmers hate end users, and, furthermore, that programmers don’t get

input from users when designing software.

On the same day, I received e-mail from a programmer who had sent me a review copy of his software. I had pointed out an important feature that the program…

[copperpress-advertserve-ad zone="3"]

Related Content