Whether you’re new to the practice or a user research veteran, there’s always something to learn. So when researchers Maish Nichani and Steve Portigal got together to talk, we were delighted to listen in. In the following two-part series, Maish and Steve take turns discussing some of the oft-overlooked aspects of the craft.
Over the course of his career, Steve Portigal has interviewed hundreds of people – families eating breakfast, hotel maintenance staff, architects, radiologists, home-automation enthusiasts, credit-default swap traders, even rock musicians. He’s also the founder of Portigal Consulting, where his work has informed the development of dozens of products and services. In his new book “Interviewing Users: How to Uncover Compelling Insights” (recently published by our friends at Rosenfeld Media), Steve sheds light on his seemingly simple but rigorous practice.
Maish Nichani is a UX practitioner and principal at Pebble Road, an enterprise UX consultancy. He and Steve are friends. Prompted by the release of Steve’s book, the two of them get together to really discuss aspects of their work. They had a whole book to go on, after all!
Included in the first half of the transcript are the differences between interviewing and day-to-day conversation as well as what Steve describes as the “tipping point” that occurs during research. Later this week, we’ll present a the second half – a sort-of reverse interview – in which Steve asks Maish what he thinks about the current and future state of the profession. And if that wasn’t enough reason to check back in, we’re also running a contest, giving away three copies of Steve’s book. Details below!
- Thanks, Steve, for taking the time to chat! What is hardest part, you think, for newcomers to grasp when it comes to interviewing users?
- I don’t think people really grasp that there’s a big difference between talking to people – something we do every day – and leading an interview. Some people decide to treat interviews exactly like conversations, whereas others decide to act like what they think “real interviewers” do (e.g., a list of questions that are read from a sheet of paper and don’t ever turn into an interaction). Both groups are missing out. Developing an understanding of the ways that interviewing inherits some aspects of normal conversation and the ways in which it differs is what separates newbies from those with a bit of skill.
- What is an appropriate response to give clients who insist on specifying aspects of your research methodology?
- Whenever a client approaches me and has already specified the approach we should take with their study, that’s usually time for a conversation. Sometimes teams create a research plan as a stake in the ground when what they actually want is feedback and a recommended approach. Sometimes, though, their plan is a good one, and we might just suggest one or two changes to see if they are amenable. I can’t count the number of times I’ve received a detailed request, exclaimed “what?!” and then had a really excellent conversation to better understand the reasons behind it. Obviously, no one should take a project where they don’t believe the method is going to produce results. An examination of a prescribed approach is one of the first tests of (the potential for) good collaboration.
- A common stakeholder complaint regarding user interviews is that they take too much time. How do you respond to clients who insist on lean research?
- It’s a red flag when someone approaches me with schedule concerns. Whether it’s their version of a lean process or not, I want to be sure that it’s feasible to address their issues with the given resources. Otherwise, it’s a project that’s going to fail – and no one wants to take that on!
I provide a “typical,” phased research schedule in the book:
As well as a version with highly compressed phases:
- My job is to help clients be mindful of the tradeoffs they’re making as they build a project schedule. The more time we spend, the more complex issues we can explore and the more certainty we will have about our conclusions. It isn’t always necessary to reach “the ultimate depths of complexity” with “the ultimate heights of certitude,” though. Clients should adjust the schedule while being aware of the tradeoffs.
- In your book, you suggest interviewers use “transitional rituals.” What are these rituals and why are they important?
- In the same way that interviews are not the same as everyday conversations, the time we spend with research participants is separate from the time we spend doing our “regular jobby stuff.” Transition rituals help interviewers switch contexts, providing a more objective interview. For me, this sometimes means assembling the materials and equipment, checking that I have the documents, etc. That’s sufficient. For someone else, they might want to remind themselves that what they are about to do is focus on the participant. That also has the benefit of reminding them to let go of the stuff-at-the-office – the report they have to give, the meetings they missing, etc.
- You go on to mention a certain “tipping point” that happens during interviews where the interviewee shifts from giving short answers to telling stories. Can you shed more light on that?
- Almost all interviews (if done well) get to a point in which the interviewer receives a great deal of information without feeling as though they’re “pulling” it out. For some interviewees, this happens in 30 seconds, for others it might 30 minutes, 60 minutes, or more. Ultimately, it’s an unpredictable element. While it doesn’t always happen, oftentimes, when running an interview, I have the realization “Oh, now we’re there!”
- Are transcripts of interviews necessary? Do memos or notes suffice in some situations?
- Notes taken during or before an interview are filled with inaccuracies. It’s just beyond human capacity to fully capture everything. You need an audio or video record. Whether you later transcribe those (my preference) or just watch them again is up to you, but notes are not the same as the definitive recording of the interview.
- How do you identify insights when going through interview data? In other words, what makes an insight an insight?
- Insights come from successive refinement. I like to have conversations with my team throughout the research process about what we’re hearing. That way, when we’re actually going through the data, it’s not the first time we’ve reflected on what is interesting. Later I go through data with two filters on: the first is looking for specific things that I’ve already identified as areas to understand; the second is looking for things that strike me as interesting. But going through data is just about gathering individual data points; it’s when you put them all together into something new (e.g., synthesis) that you start to be able to report an insight. As far as defining the term, ugh; I’ll let someone else worry about it!
- Last question! What are some tips for design teams to spread the use of research findings inside their organization?
- In short, it’s best to look for opportunities to share findings throughout the process [Ed: notice a pattern?], not just when you’ve got “findings.” I cover this in more detail in my presentation “Championing Contextual Research in your Organization.”
That’s all, folks! Thanks again, Steve and Maish, for sharing your knowledge with us. Here’s a summary of Steve’s points:
- Leading an interview is very different from everyday conversation. This subtle difference makes all the difference.
- Methods-first briefs (in which a client prescribes a process) provide opportunities for researchers to meet clients and understand their approach.
- Research can’t be rushed. Time is commensurate with outcome.
- Transitional rituals provide time to remove our own hat and wear our participant’s.
- Tipping points indicate states of flow during an interview, a natural outpouring of information.
- Always record interviews when you can. Don’t depend on memory or scribbled notes.
- Insights come from two points of view: what’s specified as part of research and what’s personally interesting!
In Part 2, later this week, we’ll share the “reverse interview” in which Steve Portigal asks Maish how he and his team work to hone their skills over time and as well as how research might be stored in the future.
UX research - or as it’s sometimes called, design research - informs our work, improves our understanding, and validates our decisions in the design process. In this Complete Beginner's Guide, readers will get a head start on how to use design research techniques in their work, and improve experiences for all users.
During my years in an agency, I've seen the spectrum of tool experimentation. I've heard passionate user experience designers argue in favor (and equally as often, against) Axure, Balsamiq, UXPin, Invision, Photoshop, you name it. We've tried it. Usually, the outcome is something out of Goldilocks and the Three Bears: the tool is too robust, or too simplistic, too slow, or too buggy, and no one's happy.