Lessons from starting up user research

It has been a long time since I’ve done a user interview. Months. I felt so out of touch, and I was desperate to get back into user research.

When I finally succeeded in recruiting a participant a few days ago, I was elated. Okay, so it was someone I met on the London IA Ning group, but nevermind – she had still some experience in a domain I was keen on doing some research in.

I based my interview method roughly on the interview method outlined in Holtblatt’s Rapid Contextual Design book, which I was also reading for this month’s UX book club. Unfortunately, the book describes an interview method that’s suited more for researching existing corporate processes, which didn’t quite fit the work I was doing – understanding a completely new domain for which there wasn’t an existing application for. Thus, I focused the interview strategy on understanding the subject area – shared ownership.

Here’s an outline of the questions I roughly had in my head (I didn’t prepare a script, because I wanted it to be more open and conversational):

  • How did you get into car sharing?
  • What motivated you to do it?
  • Can you explain the process of what’s involved? (activities)
  • What tools/devices/media did you use/consume in your tasks and activities?
  • Can you tell me the various social aspects about the whole thing, if any?

Actually, this is a pretty bad list of questions. When I was going through the data, I realized that I had missed out some very important questions, like –

  • were there any problems you experienced in any way? how? why?
  • can you explain to me in detail (about a particular activity)?
  • how often did you schedule the use of a car? why?
  • asking questions about the user’s technical abilities and expectations
  • a storyline of a typical scenario of a common activity
  • what did you enjoy most about using the service? why?
  • what activity was particularly easy/user-friendly to perform? why?

I could probably go on, but the thing was – I used this interview as an opportunity to fail, because I needed to learn from my failures and reveal my blind spots. Of course, I didn’t try my best to fail – I tried my best to do the interview, but I needed to know how I could improve.

This became more apparent when I went through and talked my colleague through the things I learned during the interview. This is where more than one person in a research process can be extremely useful. One of the key things we looked for were gaps in the research – things we failed to address during the interview or research sessions. This helps planning for subsequent interviews and research.

I learnt in this exercise that interviews in user research isn’t just about learning about users (which is like ethnography). In fact, it’s more about problem solving, except that the user may not even know he or she is experiencing a problem. When problems aren’t obvious, it can seem very hard to convince yourself that there are problems to solve, but problems always exist. There’s always something you can do to make a user’s life better.

Leave a Comment

Your email address will not be published. Required fields are marked *