To get a good interface you have to figure out who is going to use it to do what. You may think your idea for a new system is so wonderful that everyone will want it, though you can't think of a really specific example, and that it will be useful in some way to people, even though you can't say just how. But history suggests you will be wrong. Even systems that turned out to be useful in unexpected ways, like the spreadsheet, started out by being useful in some expected ways.

Example: The Illusory Customers

There was a startup here in Boulder a few years back that wanted to build a system to help people build intelligent tutoring systems. They raised a bundle of money, brought a lot of smart people in, and went to work. But they didn't stop to figure out EXACTLY WHO would use the system to do EXACTLY WHAT. The concept seemed too good, in those palmy days of AI madness, to require that kind of pedestrianism. The lack of specificity created some problems internally, since it was hard to make good decisions about what aspects of the new system were important. But the trouble became critical when the time came to line up test users, people who would try out the software and provide feedback to the developers. There were no takers! Not only were there no people waiting to fork out cash for the tool, there weren't even people who would take it for nothing. And this wasn't because the work wasn't quality. People just didn't want to do what the tool was supposed to help them do.

The company didn't just roll over; they searched around for something that people did want to do that they could do with something like the tool that had been built. Not surprisingly this didn't work out and the company folded its tents when the money ran out.

You may not have needed selling on this point. "Everybody" knows you have to do some kind of requirements analysis. Yes, but based on what, and in what form? Our advice is to insist that your requirements be grounded in information about real, individual people and real tasks that they really want to perform. Get soft about this and the illusions start to creep in and before you know it you've got another system that everybody wants except people you can actually find.

HyperTopic: Contracts and Requirements

"Fortunately I don't have to worry about this. I work on contract stuff and all the requirements have been spelled out for me before I start."

Not so fast! It's one thing to meet the requirements of a contract and another thing to build a good system. Are anybody's interests really served if you build a system that meets spec but is a failure? That's what is likely to happen if you work to requirements that have not been grounded in reality, even if it's not your fault. Being selfish, will you get repeat business, or will you get a good reputation from work like this?

Clayton did once talk with a contract developer who assured him that on his current job the success of the system was really not an issue under any conceivable future (no possibility of repeat business, etc.) He has also heard of third-world "development" projects in which the real game is to please the bureaucrat who turns the tap on the (U.S.- supplied) "development" money, rather than to make something work. But life is too valuable to spend on activities like these. Find something to do that matters.