Tuesday, March 13, 2007

The Right Answer

One of our friends here recently sent out a flyer on behalf of the local historical society asking people to submit their stories of how they learned about Point Roberts and how they got here. The flyer also asked people to donate $10 to the society. Unfortunately, the wording of the flyer made it appear that people had to donate in order to submit their stories, and the wording of the request for stories was so open-ended that some of the responses were unusable.

A university student was wrestling with the design of an experiment. She knew the general topic to be investigated and had a general approach in mind, but couldn't arrive at the specific approach or the steps that needed to be taken.

A group of engineers at a company I worked with were trying to design an input device for a workstation. They were trying out several options and having a hard time deciding which one was the best.

These situations all have one thing in common: inadequately defined requirements. I think this is one of the most common mistakes made by designers of every type, and I think it stems partly from a tendency to think one already knows all the requirements, or that the requirements are obvious and don't need to be spelled out. But my friend at the historical society might have had a better response if he had first spelled out what the desired product was (a specific type of story and a willingness, separate from the story, to make a donation), the student would have had an easier time designing the experiment if she had articulated the experimental question to be resolved, and the team of engineers would have been better able to decide which design was best if they had specified some criteria first.

You may think this goes without saying, but I can't count the number of meetings I've been in that have gone either nowhere or in circles until someone said, "What are the requirements?" Perhaps it's one of those lessons that are so basic that we need to be reminded of them continually, because we take them for granted otherwise. And, as illustrated by these three situations, I think this lesson goes beyond product or interface design to life in general. After all, how do you know what the right answer is if you haven't defined the requirements?

No comments: