Asking questions is the only way to find out what the “real” user requirements are — what the other person really wants. But there’s a great deal more to asking the right questions than knowing the difference between open-ended and close-ended questions (in fact, there’s really no such thing as a truly open-ended question). Here’s what to ask that will let the other person tell you what they really want.
Back when I had a job (before I became a consultant), I got a request from one of the users for an application that my department was responsible for. The requirements behind the request were simple: reduce the font in one of the textboxes from 10 points to 8. Now, at 10 points, that textbox was already unreadable to me (I was also already on my second set of reading glasses). I couldn’t imagine that anyone in their right mind would want us to reduce the font still further — or that they would be happy with the results if we did.
But this, of course, is just a standard move in the “user requirements dance”: People ask for something, you deliver it…and discover you’ve made those people less, rather than more, happy. We often take it for granted that other people don’t know what they really want until we give them something. It’s only at that point the other person discovers they don’t want what they said they wanted. The only good thing about this dance is that this is just the first step. The second step is that, once the other person has something in their hands, the other person realizes what they actually do want (or gets very close to it).
It would be nice to avoid that first step, however, and start with a set of user requirements that reflect what the other person actually wants. Probably both you and the person you’re working with recognize that your initial offering wasted your time and the time of the person you’re trying to help. If you could, you’d both like to get over those wasted steps and get straight to the interesting/useful part of the dance.
The solution to this problem is in the questions you ask before you start the dance. At this year’s EdUI conference, Anne Haines talked about what questions will let you find out what your users really want. To begin with, Anne provided some insights about open-ended and close-ended questions.
Conventional wisdom suggests that the best way to discover what someone else wants is to use open-ended questions. Anne pointed out that open-ended questions don’t really exist.
I’ve always thought of “close-ended” questions as ‘questions with one-word answers,’ but Anne points out that there’s a much better definition for close-ended questions: They are questions where all of the possible answers are known in advance. Those answers may be “Yes” or “No” or they may be longer (“I totally agree”, “I partially agree”)…but you know all of the possible answers before the other person opens their mouth. At best, the other person is just picking from a set of pre-defined choices decided, in advance, by you.
And that’s not necessarily a bad thing. Often, when we get down to confirming details in a larger plan, there are only a few viable answers left. A close-ended question is the right choice to make sure that the other person picks an answer that can be used. You do want to make sure that the acceptable answers that the user can pick from meet some criteria:
Based on that definition for close-ended questions, open-ended questions are questions where you don’t know the range of answers — the other person can provide any answer at all. In many ways, open-ended questions are empowering in a way that close-ended questions are not because the other person can provide whatever answer they want.
It’s the difference between an interview like this:
Interviewer: “Do you want it in green or red?”
And this interview
Interviewer: “How do you want it to look?”
Interviewee: “Dynamic. Like something that’s coming right at you at full speed”
But, as Anne points out, even an open-ended question is really close-ended. When you ask someone else for what they want they will only ask for what they think they can get. Henry Ford is supposed to have said that if he’d asked his customers what they wanted, they would have said “faster horses”. From your point of view, a question may appear to be open-ended because you don’t know the answer; the other person, though, has some limited set of answers that they can provide. Because of that, even your best open-ended question is, eventually, closed off.
To get to the real user requirements, you have to explore what the interviewee really does understand: their problem. You might think that telling you what’s bothering them is what people do most, Often, though, it isn’t.
Often what people talk about is some proposed solutions, not the underlying problem. That’s what was happening with that request to drop the font size in a textbox from 10 point to 8 point. Fortunately, when I went to talk to the user I discovered what their problem was: They couldn’t fit all of the text they wanted into the box we’d provided on the form — that box stopped accepting new text as soon as it couldn’t display anymore.
Rather than drop the font size, I suggested that we could replace the textbox with a “notes box” that accepts an unlimited amount of text (far more than would fit on the screen). Furthermore, if the text overflowed what could be displayed, the notes box would provide a scrollbar to let the user scroll through the text. The user thought that was a great idea.
As Anne pointed out, the questions you need to ask should be open-ended but they must be about what the other person knows best: their world and their problems. Often, you will find that the answers you get will overturn some of your assumptions. In fact, if some of your assumptions aren’t overturned then you probably haven’t asked enough questions. If you’re going to ask any questions about the solution, ask questions about what the other person would value most in a solution: speed? reliability? low cost?
Only after exploring the problem should you start asking open-ended questions around solutions. You’re still working in what, in the end, is a closed system. However, originally, there were two closed systems: yours and the other person. Now you’ve expanded that boundary to include the joint knowledge of you and the person you’re talking to. It’s still a dance but you’ve gone right to the interesting part and saved you (and the other person) a lot of time.
Of course, once you’ve got to the “real” user requirements, you still have to document them, manage them, and deliver on them. We talk about all of that in Learning Tree’s user requirements course. But, first, you have to get to what the other person will regard as the real answer.