How to Prepare for a User Interview and Ask the Right Questions

Ditte Hvas Mortensen: What are some good tips for creating the right atmosphere for an interview? Ann Blandford: I think it is about making people feel comfortable, about building rapport. It's also about very practical things like is it quiet enough that you can record and expect to be able to hear the recording reliably afterwards?

About it not being an environment where people get too distracted – so, thinking through those things. We've done quite a lot of interviews over the years in coffee shops, for example, because they are a comfortable and safe public space, and you can have a coffee and a cake, and it feels fairly relaxed. But there are some coffee shops that work really well for interviews.

And you can be unobtrusive and find a table in a corner somewhere. And there are other coffee shops that are just impossible to run interviews in. And you want to think about whether or not the interview is going to be in a public space at all, if there are sensitive topics to be covered. In my case, that's particularly around things like health issues. You know, there are a lot of things that people perhaps *don't* want to talk about in a public space.

So, it's about finding a space that feels safe for both interviewer and interviewee, that feels comfortable, that is suitable for recording in, particularly if you're going to transcribe the whole lot. That might be slightly less important if you're only transcribing a little bit or if you're just taking notes. So, it's really about the *depth* of the interview, as well. Maybe sometimes you want to do interviews in the workplace so that you can have props like

the interview guide to hand or technology that you're talking about to hand so that people can show you things and how they do things as well as just talk about them. So, different kinds of places might be appropriate for different kinds of interview purposes and different kinds of interview topics and contexts. But always it's about safety, comfort and appropriateness and whatever dimensions that might include.

Ditte Hvas Mortensen: Thinking about questions, there's a certain sequence to how you best do it. So, maybe you could start by saying something about what the best way is to start an interview. Ann Blandford: For sure, the best way to start any interview is with opening questions that set people at ease, that assure them of what kinds of topics are going to be covered,

that give them a sense of what will be done with the data, though maybe that will be even before the interview starts, as I think about it. But it's about *setting somebody at ease*, about *helping to build rapport with them*. Obviously, each of us as an interviewer has our own personal style. And also every *interviewee* has their own personal style. And so, no two interviews are actually the same as each other.

I can't imagine ever running two almost identical interviews because they do so much depend on the participants – both the interviewers and the interviewees involved. But it is initially about setting somebody at ease, asking them comparatively innocuous questions – for example, what their role is in the organization if it's about a work system or their experiences of using a technology *like* the one that you're thinking about designing.

D.M.: So, it sounds like it's also pretty concrete questions. A.B.: Usually initial ones – it's best in my experience to make them reasonably concrete. One can move on to more abstract or more speculative questions later. Or, you know, questions that perhaps get at more sensitive feelings and values and emotions will come

later in a conversation when people have settled in and have started to feel comfortable in the situation, as opposed to, you know, starting with "So, how do you *feel about* _____?" – you know. That's not likely to set somebody at ease – if you kind of head straight into those things at the outset. And then, at the end, it's important to wrap up in a way that again leaves people feeling that they've said what

they want to say, that there aren't any topics that *they* thought were important as part of this interview, that they had an agenda, giving them a chance to articulate anything that you might have missed, and also giving them a sense of what's going to happen *afterwards*, you know: Are you going to give them a report back? Are you going to advise their managing director about new technology requirements?

What will be done with the data – what's the *value of the interview* for them? Some people really care about that; others perhaps less so. So, it's about being sensitive to what different people need. And in the middle – I mean, that's obviously the bulk of it – it's really about *planning it well ahead of time* so that you've made sure that you're covering all the topics that you're aiming to cover in

a rational and sensible order. As I've said already, people may sometimes answer and introduce topics that they've thought about already and answer future questions before you've even asked those questions. That requires you to be on your toes and think, "Oh yes, they've already answered that completely," or, "They've already *partly* answered that," and then, you know, picking up on what they've already said so that you're showing that you've been listening to them, and pursuing that topic a bit more later.

But it's about *making it flow as a natural conversation* as far as possible, while also *covering the topics that you want to cover*. So, it's important to get the structure so that it's a natural one that flows for most people – even if some people will run it differently. And part of checking that is about *piloting it* – you know – running through it with a friend or with somebody who at least should be able to *pretend* that they're a participant in that study first, to make sure that

you've got a coherent set of questions that are *comprehensible*, that are *using the user's language*, talking in terms that make sense to them and that they can engage with. So, you know, none of us gets interviews right the first time. It's usually worth trialing them out and going from there. D.M.: So, it sounds like you should try to follow the user's or the participant's

– if she brings something up earlier than you had expected, you just go along with it, or...? A.B.: That's my style, certainly, you know, because once somebody's in the flow if they're talking about things that you want to cover *anyway*, it just seems most natural, then, as a conversation to let them carry on on that line; and then, when they've finished, perhaps bring it back to make sure that you are covering everything that you wanted to cover

– because otherwise it starts to feel very disjointed and people may well forget the thing that they'd already half-started to say, and so you'll then have lost it forever. So, it's much easier if people can actually just carry on in the flow, as long as they're not going *wildly off-topic* for too long a time. And actually respecting participants can very often involve them going off-topic for some parts of it.

And you're gently trying to bring them back, and exactly how you do that probably depends on your interviewing style, actually. I personally probably let people run on a bit longer than perhaps some other interviewers would because I want to find an opportune moment to get people back on track. I think probably the worst one I had was – again, it was a little while back –

where somebody wanted to express a lot about the unions in their organization and was determined to tell me about industrial relations even though my focus was on *technology design*. They were seeing the introduction of new technology as being closely linked to other aspects of their relationship with management. And, of course, those weren't directly relevant to me.

But if I had just kept shutting them off, then I don't think they'd have talked properly about their attitudes to the technology, either; so, it was about respecting the other things that they felt that they wanted to say that were in *their* minds related, even though they weren't as directly relevant to the user interaction design – to me. So, they were less directly relevant to me. It might have taken me slightly longer to get all the information that I needed in that situation, than it would have done had they completely stuck to my script.

But on the other hand, it helped me to build rapport. I think it gave me better information. It certainly meant that I had a better relationship with the people I was interviewing in that setting.

Ditte Hvas Mortensen: In interviews, you often want to ask people about their past experiences or how they normally do something. But what are good ways of getting them to recollect correctly? Ann Blandford: People are typically not good at recollecting where you give an abstract question.

So, I'm going to use a hopefully very, very familiar example for pretty much everybody, which is *going shopping*. If you ask somebody how they go shopping, they'd probably give you a very short answer. You know, for grocery shopping – they'd probably give a very short answer like, you know: "Well I write a list. And then, I go around the shop and I pick things up and I put them in my basket. And then, I go to the checkout." If you ask them to describe exactly what they did the *last time they went shopping*

– the *most recent* shopping trip they did – they'll add a whole pile of other details, like, you know, that they got to the bread section and remembered that they hadn't picked up any bananas or whatever. And then, they discovered that they'd planned to cook some meal that had five ingredients, but they couldn't find the fourth ingredient in the shop, so then they had to rethink what it was they were going to cook.

And so, they put some other ingredients back, and then – you know. And so, you get a whole load of details that way that show that it's not such a linear process as we would naturally describe it if you just asked somebody a general question about going shopping. And shopping is a very mundane activity that most of us have to do one or more times every week. So, a lot of the activities are kind of things that we take for granted.

Therefore, asking people about a very specific instance of it is likely to give you a whole set of details that people wouldn't mention at all if you just asked them about the generalization. So, asking about specific instances – either the most recent or one that's memorable for some other reason often gets a lot of information that you might not have access to otherwise.

And the other way to get people to remember things is invoking incidents that are particularly memorable for one reason or another, things that people remember because they had some high emotional content. And often for technology design, they are the *big* things that happen, the *memorable* things that happen.

So, a while back, I did a study of how people use diaries and the different kinds of technologies that they used for managing their diary and their to-do lists. And I asked people about critical incidents that had happened in diary management. And people told me things like putting an event in the wrong year so that they *missed* an event because they'd accidentally put it in last year rather than this year.

And that caused embarrassment. And then, you could start to explore what it was about the design of the diary that had made that kind of error so easy for people to make. One participant told me about how he had left his digital – his PDA, his organizer – in his back pocket when he'd put it in the wash. That actually didn't tell me much about the interaction design.

But it was the thing that *he* remembered as being a particularly critical incident in relation to his PDA. And I guess what it did highlight was the challenges of having a backup and of reconstructing the events that had been in that PDA before it went for its swim in the washing machine. So, those kinds of things can trigger memories, and, you know.

You don't know what's going to come out from those, but often they're interesting – they're valuable. They tell you about things that didn't quite work in a design. Another example was when we did a study of ambulance control. We asked people about critical incidents. This is again going back a little way. And some people remembered really *major* incidents where *everybody* would know – you know;

it hit the national press, and lots of people would have been aware of that incident. But the controllers could talk about their own personal role and what information they needed and how they got hold of that information – you know: how they used the displays; how they worked together; how the technology supported them in making decisions and, indeed, sometimes how it *didn't* support them in making those decisions. One or two participants told us much more *personally pertinent* incidents

of, you know, a particular call that had come in that had had an emotional impact on them – like when a small baby was involved in an incident, you know, in some kind of medical emergency. And they clearly engaged a lot with that, and so could again talk about it in a lot of detail *because* it had an emotional significance for them – that made it more memorable and hence made their memories a bit more reliable.

So, critical incidents are often kind of negative in one way or another – and it's much more common that they're negative than that they're positive. And, of course, it's nice to find out about *positive* incidents as well because they tell you about *good design features* rather than just things that didn't work well. But, of course, HCI is often about trying to *improve* design. And so, it *is* about finding out about the things that don't work well for a system

and how they would support people through the more challenging situations that they encounter. So, I really start asking about a *memorable* incident rather than an emotionally-charged or challenging incident. And how they define "memorable" is really up to them. But then I will try to follow through with questions that enable *me* to end up feeling like I understand the course of the incident and the consequences,

particularly in relation to the use of technology in technology design and how technology might have helped better. So, I suppose I'm working with my agenda of what I'm trying to get out of it. So, I'm not really seeking to understand the depths of the emotions that they went through – because that has *ethical* implications, quite apart from anything else, but it's also *not* what's really generally most relevant for thinking about technology design.

So, I'm kind of keeping my interview script and what I'm trying to get out of the interview in mind the whole time, but the questions are free-form and situated.