Most people about to run their first on-site requirements interview tend to focus on preparing a list of “good” questions. There’s a common belief that there are a set of questions which, when asked in the right order, will give you profound insight into your users’ goals and tasks.

If you’ve tried this approach yourself in the past, you’ll know that using an interview script to gather requirements doesn’t work. The first couple of questions may go as planned but then you quickly discover that your question list was developed from a place of ignorance. When you look over your prepared list of questions, you now realise that there are lots of things you didn’t know about the user, the context and the work domain that are now beginning to emerge as important.

The paradox of qualitative interviewing is that if you know the questions to ask ahead of time, you probably don’t need to run the interview in the first place. In user experience research, a good qualitative interview must scratch below the surface and explore the users’ goals and context. This means the interview often heads in a different direction to where you expected.

But at the same time, no-one wants to go into an interview feeling unprepared. How can you run a user interview without knowing the questions you’ll ask? Over the next two articles, I’m going to describe some different approaches to running one-to-one user interviews that will help free you from the straitjacket of question lists.

Why not just ask people what they want?

“You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new.” — Steve Jobs

Philip Hodgson has explained why focus groups don’t work, and many of the same issues apply to one-to-one interviewing. If you just ask people what they want, you’ll find people tend to focus on what they are trying to achieve right now — and as a consequence they tend to ask for a larger hammer, rather than thinking in terms of an entirely different tool. By focusing on goals we can get people thinking beyond their current context and task.

In this article, I’ll look at two techniques: story elicitation and Jobs To Be Done (JTBD). These goal-directed interviewing techniques allow you to dispense with question lists yet still give you the confidence to lead the interview.

The story elicitation interview

Stories are powerful ways to capture user needs and goals. Stories are inherently contextual, and this means that the requirements you gather are embedded in the real world. Note here that I’m not talking about “user stories” in the Agile sense, but narrative stories with which we are all familiar from novels and movies. A good story will contain realistic characters, details about the setting, and a plotline; as well as a collection of goals, motivations and obstacles to completion.

A simple way to elicit a story in an interview is simply to ask for one: people often have an urge to tell stories. For example, “Can you tell me a story about the last time you switched energy providers?”, “Can you share an experience about the last time you unboxed a new gadget for the first time?” or “What do you think was a turning point in your understanding of the system?” If your interviewee finds it difficult to recall a story, try seeding the conversation by focusing on a particular point in time, for example, “Can you recall the day when you first received your tablet device?” or “Tell me about a time when you called the tech support desk.” Asking people to recall strong emotions is also another good way to help people recall stories, such as, “What’s the most frustrated you’ve felt when using the system?”

If you run into a particularly reticent interviewee who finds this difficult, I recommend this structure for eliciting stories described by Whitney Quesenbury and Kevin Brooks in their book, 'Storytelling for User Experience’. Here’s the approach.

• Start with a question that establishes the activity you want to talk about. This question can be simply answered with a Yes or No. For example, “Have you ever [done something]?”
• Then ask questions that build up a picture of how this activity fits into their work or life. For example, “How often do you [do that thing]?”, “What makes you decide to [do that thing]?”, “Where do you generally [do that thing]?””
• Now ask questions to get them to think about a specific example. “When was the last time you [did that thing]?”
• Once they have a specific event in mind, repeat the situation (to be sure you have it right) and then ask for the whole story. For example, “Tell me about that.”

Let’s do this with an example where we have a particularly taciturn interviewee.

Interviewer: Have you ever upgraded your mobile phone?
Participant: Yes.
Interviewer: How often do you upgrade?
Participant: Not as often as most people. Maybe every 2-3 years.
Interviewer: What makes you decide to upgrade?
Participant: Getting new features, or a faster phone if my current one is out of date.
Interviewer: Where do you generally go to upgrade? A store, online, somewhere else?
Participant: I prefer to do it online, where there are no pushy salespeople.
Interviewer: When was the last time you upgraded your phone?
Participant: It was a few years ago now. I was fed up with my Blackberry and decided to move to an iPhone.
Interviewer: So you wanted to switch to an iPhone. Tell me about that.
Participant: I remember looking at various web sites like O2, Orange and so on but the contracts seemed so expensive. I’m interested in the lifetime cost of a phone, not the monthly cost, so I thought I’d look at buying a phone outright from Apple. Well…

So rather than memorise a list of questions before your next interview, instead try a story elicitation approach.

Jobs to be done

“Jobs to be done” is a framework developed by Clayton Christiansen for thinking about consumer purchases. Instead of thinking of people as buying a product, Christiansen characterises people as “hiring a solution” to do a certain “job”.

In one way, this reminds me of the old chestnut about people not buying a quarter-inch drill bit, but a quarter-inch hole. But by using the concept of a job to be done, Christiansen’s framework is even more goal-oriented: this is because people don’t want drill bits or holes: they want a bookcase on the wall. That’s the “job” for which you “hire” a drill.

For example, my last purchase was a USB hard drive for my computer. A traditional marketing depth interview would ask me for my opinions about the qualities of the product, such as its physical design, its colour, and its size. In contrast, a JTBD interview explores the causes of the behaviour: what job did I hire the hard disk to do? The answer was to backup the files on my iMac. A JTBD interview would uncover the specific point at which I knew I needed a new drive (my backup failed because my existing drive didn’t have enough capacity); the alternatives I considered (such as cloud-based services) and why I dismissed them (speed and price); the purchase process itself (in my case, on Amazon) and why I chose this particular model; and my feelings about the end result (I’m happy with the hard drive but I still have anxieties about losing data — should I backup my backup?)

Like the storytelling approach, this framework is a useful way to help users get beyond thinking in terms of tasks and instead get them thinking in terms of their goals.

A good JTBD interview will fully explore the purchasing timeline from 'first thought’ to the final experience. This means you’ll explore the point when the customer started passively looking for a solution (“When did you first realise you needed something to solve this problem?”); to actively looking for a solution (“When did you first start looking for something to solve your problem?”); to deciding between alternatives (“What kind of solutions did you try?”); and finally to experiencing the solution.

An interesting feature of JTBD interviews is that they acknowledge the foibles of human memory and so they borrow ideas from cognitive interviews to help people get into the mindset they were in when the purchase was made: for example, they will ask customers where they purchased the product, what the weather was like, how they travelled to the shop, who they were with and did they pay by cash or credit card. Although these questions are not relevant to understanding the purchase process, cognitive interviewing does help people remember events more clearly (and this is why they are favoured by police interviewers). This also makes the point that research is not just asking questions: with goal-based interviewing we are drawing on an understanding of human cognition to effectively "recreate the scene of the crime".

Similarly, rather than start at the beginning of this timeline with a question like, “When did you first start looking for something to solve your problem?”, it’s more productive to start later in the process with something more concrete: usually at the point of purchase. So a JTBD interview starts by asking questions around the point of purchase, since those memories are likely to be easier for people to recall, and then the interviewer moves backwards and forwards through the timeline as appropriate.

I started developing a worksheet to structure a JTBD interview, but then discovered that my friends in the Red Gate UX team had already developed one.

In the next article, I’ll explore another interview technique. Until then, try out one of these approaches and let me know how you found it in the comments.