μεταcole

User Interviews: How to Get Permission for Video/Audio Recording

Posted in research, UX by coleman yee on April 22, 2016

If you’re a UX researcher conducting user interviews, you’ll probably face this issue: you want to take a video or sound recording of the interview (or some other user research activity) so you to get permission from the interviewee. But when you ask for permission, there’s always a chance that the interviewee will say no. You want to ask permission in a way such that you’ll maximise your chances of getting a yes.

Without enough thought, most of us might ask this way:

We would like do a video/sound recording for this interview. Is this okay?

Short and sweet, but it’s way too easy for the interviewee to go “well… not really…” and you just lost your chance to do the recording.

After years of trial and error on hundreds of interviewees, this is what I’d now say:

What you say to us is important to us, so we’d like to take notes. To make sure our notes correctly represent what you say, we would also like to take a video/sound recording. Of course, the recording is confidential and will not be shared around. If you have no objections, we’ll proceed with the questions?

Explanation

Let me explain the thinking behind each phrase, so that you can repurpose this for your own context:

What you say to us is important to us, 

Provide a rationale, including a bit of truthful flattery. People are more likely to agree if you provide a rationale. And we know how effective flattery can be. (I stole this phrase years ago from Jan Chipchase.)

so we’d like to take notes.

Start with something small that they will agree to (almost everyone is ok with notes)…

To make sure our notes correctly represent what you say, we would also like to take a video/sound recording. 

…so that it’ll be easier to say yes to something bigger (allow video/sound). This foot-in-the-door persuasion technique often used in sales.

Of course, the recording is confidential and will not be shared around. 

Quickly assuage the concern they might have – assure them of confidentiality. The “of course” hints to them that you understand their concerns.

If you have no objections, we’ll proceed with the questions?

This is phrased so that it’s easier for them to let us proceed than to say no (they just have to say “OK” or nod to let us proceed) – we’re nudging them to say yes while giving them complete freedom to say no.

Phrased this way, those who really don’t want to be recorded will still say no, and we have to respect that. But those who are less adamant, who would have said “well… not really…” using the first opening would more likely allow you go ahead.

Feel free to use this or modify it for your own context.

If you have other ways or techniques to increase the chances of getting a yes, I would love to hear from you.
Or if you’d like to learn more about user interview techniques, do get in touch.

Tagged with: , , ,

leave a comment

Which Comes First: Design or Research?

Posted in design, research by coleman yee on June 8, 2007

Since I’m into design (I’m a Design Consultant after all), I was pretty interested in PingMag’s interview with Ken Okuyama. While he’s mostly into product design (he’s behind the lovely design of the Enzo Ferrari), and I’m more into information and experience design, there’s always something I can learn from other design fields.

What stood out to me the most was how he typically starts his design process:

I put everything in my brain down on paper, stick all of it on the wall and judge objectively the best possible solution for the problem. Then I start the research after. Not before. Once you know, you cannot go back to “your ignorant yourself.” But the ignorant yourself is the best creative partner you have.

Where I work at PebbleRoad, we normally do it the other way round – keep an open mind and do the research first to find and understand the problem, before embarking on the design.

Humanized described our design philosophy very nicely in a recent post on interative:

Coming up with a solution is often the most straightforward part of the design process. That isn’t to say that creating the solution is easy, or doesn’t require a deep knowledge and honed skill set. It’s just to say that when you have a set of requirements and a well defined problem, you know where you stand and where you have to get to. It’s mostly straightforward. Much harder is the implicit problem of figuring out exactly what the problem is in the first place. If the problem is vague or ill-defined, the design solution will be too.

So far this has worked well for us, and it makes sense too, since we don’t really want to design something for the wrong problem.

But Okuyama has a valid point about “your ignorant yourself” being the “best creative partner”. Is that the key to the really groundbreaking and mind-blowing designs?

Something to think about, and something I’ll definitely try out in my next project. But that would never work if we forget his qualifying statement, which I deliberately left out from the quote above:

You also need the courage to adjust your original idea once it’s proven to fail.

3 comments