By Scott McDaniel
My daughter has been reminding me of the importance of asking questions to understand why things are as they seem or appear to be. She never stops asking “why?” As a designer of software systems, I believe that the child’s spirit of “why” is something to retain and infuse into our work when gathering requirements, interviewing users, and interviewing stakeholders.
Why?
People are not always good at stating their needs, but they are good at stating specific desires. To bridge the gap between needs and wants, it’s important to question each feature request and requirement. Playing the why game, asking “why?” after each and every answer, no matter what it is, moves the discussion from specific requests to fundamental goals.
Why Would We Want to Talk about Fundamental Goals?
Understanding a person’s goal reveals the true, perhaps hidden, requirements. Maybe the feature request was correct, or maybe it was a sign that they were really trying to do something else that could better be accomplished another way. In either case, formally playing the why game allows designers to trace specific requirements to the tasks they support, and the tasks up to the high-level goals that they support.
Let’s look at an example. A business-to-business system allows companies to create and sign contracts with each other. The companies then buy and sell goods under that contract. Contracts are usually for a fixed amount of money, and they are automatically closed when the contract is fulfilled.
A summary page shows the details of a contract’s transactions. One company’s shipping department asked to be able to print the summary page as a printer-friendly, official-looking document. Why? So they could give the accounting department a record of the transactions. Why does the accounting department need an official-looking, paper copy? So they can have a person enter the data to double-check the data received directly from their own sub-system and their customer’s system. Why do they do double data entry? Because that is an established (and trusted) way to reduce errors and keep the books balanced. Why does accounting keep the books balanced? Well, because that’s what an accounting department does.
This example traces a very specific request to a general goal and a group’s identity. The need for a formal-looking document to give to the accounting department was never really established. Why wouldn’t the accounting department be happy with a printout of the “ugly” screen as it appears in the web application’s browser?
Following this line of questioning establishes that the original feature request for an official-looking document isn’t actually needed. Or maybe the answer, perfectly legitimate, would be that the culture of the company places a premium on formality and record keeping and that the system won’t be taken seriously unless it can produce official-looking paperwork.
The principle is this: Every feature of a design should be traceable to its users’ goal and identity. One way to do this is by asking the “why?” questions until we can do this.
When interviewing users and stakeholders I often find myself starting this chain of “why” questions, but for some reason I hesitate to continue, perhaps because people react as if they’re being interrogated and that their answers aren’t good enough. I urge myself to continue. I rephrase the questions, and I don’t stop until the user’s goal is stated and understood.
Why Do We Want to Trace a Feature to User Goals?
Each level of question between feature and goal provides two opportunities:
- To identify requirements that were not explicitly stated. Knowing that the task of printing a formal contract summary is to give accounting a copy for data checking suggests other requirements. Do sales account managers need copies of these summaries for their reports? Ask them.
- To identify alternate design solutions or provide a rationale for a current solution. Knowing that the accounting department needs contract summaries for data checking purposes suggests the possibility of having the system automatically generate a PDF version of a contract’s summary once it closes. It could then e-mail it to accounting, thus eliminating the printing requirement but satisfying the need. On the other hand, the system could automatically reconcile the contract summaries with the accounting system records, but understanding the value of having a person double-enter argues against that direction.
This technique is useful in several ways:
- With customers during user analysis to identify their goals.
- With requirements analysts as a check when assembling requirements to discover what may have been omitted.
- With designers to ensure that the method to implement the features satisfies requirements, tasks, and goals.
- With reviewers or users while evaluating an interface (heuristic review or usability testing) to make sure each feature satisfies a requirement that is based on a task, which supports a goal.
- With interviewers to investigate why a stated goal is an integral part of a person’s work identity.
Tracing features to goals allows me to be certain that I have met the customer’s needs and created a truly useful system. In combination with user analysis and iterative usability evaluation, this strategy allows me to be certain that I have produced the best user-centered design possible.
