3 Tips for Easier User Interviews
As designers, we’re not experts on research — but sometimes we need to do it anyway. Here’s what I’ve found helpful in approaching it.
Hey there! I’m Nicole, and I’m a product designer. I write this newsletter to share my experiences and lessons learned through my work as a product designer.
We’re all familiar with product designer job descriptions. Among the reams of expectations about wireframing and prototyping, partnership and collaboration, flows and user journeys, one additional bullet point is furtively tucked in: “experience conducting research.”
This expectation is useful. Our role is neatly situated to close the loop: we know the user experience, so we can use research to identify problems to solve through design. And because we’re positioned between all other roles in product development, we can circulate findings broadly and deeply.
But the expectation is also aspirational. Realistically, much of research falls outside of a designer’s purview. Generative research can expand into multiple product areas beyond a single designer’s reach. Operational tasks, like recruiting participants, require artful handling to avoid diminishing a project’s usefulness. And in agile, the biggest challenge is time. When you’ve carved out slots in your calendar for the wireframes, prototypes, partnership, and more, there’s not much left over for research. How can we mitigate these drawbacks, so we can maximize the value that research provides?
Recently, I finished interviewing about a dozen users. Though I’ve led research projects before, this one presented many other firsts: finding the right users from a pool of thousands, coordinating incentives, and distributing the research results to over a hundred team members. The territory was unfamiliar, but I relied on the same approach I’d found successful with past projects. And it worked: we successfully interviewed users and walked away with informative, applicable findings. In this article, I’ll outline what that approach looked like.
If you’re embarking on research for the first time or if your past projects have been not-so-great, this approach will cover the tenets of a productive research project — while leaving enough flexibility for whatever firsts you might be dealing with.
#1: Prepare everything before recruitment
When starting a research project, it’s tempting to rush into contacting users. Maybe your stakeholders were reluctant to budget time for research, so you feel pressed to show value as soon as possible. Maybe engineering is waiting on designs already. Or maybe you’re just excited to talk with real people who use your product. In any scenario, it’ll be a much better use of everyone’s time — yours, your team’s, and your users’ — if you prepare your materials in advance.
What are these materials? At a minimum, the following items are helpful for any kind of research project:
Research Plan
Your research plan is the glue for your project; it does the hard work of holding the whole effort together. With a sensible plan, you won’t have to figure out what should happen once you complete one step and move onto the next, nor will you have to constantly remind stakeholders of what you’re doing.
Your plan should detail what you’re trying to accomplish (your research goals), what you want to validate (your hypotheses), and how you’ll accomplish those goals (your research methodology). Any and all other information related to your project can reside within your plan, or your plan can link off to them.
🍎 Further reading: Project Management for User Research: The Plan
Discussion Guide
To make the most of every interview, plan out what you’d like to say and how you’d like to say it — and write it out verbatim. (That might seem like overkill, but it standardizes the interviews. Plus, you won’t forget any points.)
Introduction. This should be a brief elevator pitch about you, your role, and how the interview will proceed. The purpose here is two-fold:
It communicates to the user what to expect for the rest of the interview.
It helps them feel comfortable in giving feedback. A few simple statements like “There’s no right or wrong answers, as I’m looking for your candid thoughts. Don’t worry about offending me,” creates a safe environment for honest reactions.
List of questions. Think through where you’d like the conversation to go, then design the questions to guide it there. I recommend starting with broad questions before narrowing into specific ones. For example, if you’d like to know how users use a feature in your B2B product, you can start with a few questions asking them about their unique business and why they use your product.
Conclusion. Thank the user for their time, emphasize how helpful their feedback is, and mention any next steps for their participation incentive. This indicates to the user that they’ve completed the interview and you’re now wrapping it up.
🍎 Further reading: Writing an Effective Guide for a UX Interview
Recruiting Assets
Because recruitment can be the most demanding part, keep notes about your process as you progress. This is also valuable for others who might need to do something similar (described below, in section #3).
Your notes could include a data set of potential interviewees, a spreadsheet used to track participants, and email templates to make your communication faster (described in the next section).
🍎 Further reading:
Recruiting and Screening Candidates for User Research Projects
234 Tips and Tricks for Recruiting the Right Users as Participants in Usability Studies
#2: Communicate frequently and specifically
Convincing users to get on a video call with you requires tenacity — and a lot of communication, usually via email. My 11 interviews required over 90 emails, and a juggling performance of names, information, and dates. But I wasn’t expecting this to be the case when I started the recruiting process.
Initially, I thought communication would be straightforward. I’d reach out to the user, they’d either respond or not; if they did respond, we’d schedule time and have the interview. If not, I’d find another user.
But I quickly learned that the process is far from linear, even for the most enthusiastic of users. One lesson came early on, after a few users booked their time slots. In the days leading up to their interviews, I assumed they’d see the event on their calendars and remember to show up. So when it was 15 minutes after the interview had started, and I was sitting alone in a too-quiet Google Meet with my notes poised, my smile deflating, and my patience waning, I was forced to come to terms with reality. They weren’t showing up. And it was probably because I didn’t remind them.
So I fixed the gaps in my communication. I sent proactive reminder emails and I followed up with users who didn’t respond to my initial outreach. I was polite but persistent. To my relief, the problem solved itself. The users showed up!
The process that I found successful, true to its iterative nature, is as follows:
You’ll notice a few things about this diagram:
Every communication, if not responded to, necessitates follow-up. Users will usually appreciate the gentle reminders. If they keep ignoring your emails, you can shift your focus to other potential participants.
Rescheduling is common. Out of the 11 users I interviewed, 4 users needed to reschedule. Two users even rescheduled 3 times. But I’ve found that rescheduling is better than canceling the interview altogether. Keeping the same user in the workflow described above is preferable to starting over with an entirely new user.
Each outreach should be specific and concise. Users are short on time and context, so each of your messages should indicate why you’re reaching out and what you need from them. For example: “I’m confirming that you’ve scheduled your interview for Tuesday, August 30 at 12:30 PM” is specific in purpose and concrete in detail. Similarly, “This will be a video call on Google Meet,” is an important distinction, as users might think the interview will take place over the phone. Think through what your users might need and tell them that, before they ask.
#3: Iterate based on feedback
Getting another perspective before, during, and after your research project will identify any parts you might have overlooked. Here are a few feedback sources I’ve found valuable:
Feedback from team members
If you don’t have the luxury of consulting with a research expert in your company, there are other people you can rely on.
In the research projects I’ve done, I’ve found it most helpful to solicit feedback from my manager, product manager, and other designers. Each person can provide insights from the perspective of their unique role. Your manager can advise on the project overall: logistics, the audience you’ve chosen, and your methodology, for example. On the other hand, your product manager and other designers can provide more focused feedback about your research plan, audience, or questions.
Feedback during user interviews
Even though you’ve planned out what you’ll ask the user during the interview, you won’t know how effective the questions are until you try them out.
Because of this, I recommend keeping an open mind about your questions during the interviews. If a question confuses the user, maybe it’s not clear. If a question veers the conversation in an unwanted direction, maybe it’s too vague. If the interview ends 15 minutes early, maybe you need more questions.
For a controlled experiment, you should maintain consistency with the questions across users as much as possible — but that shouldn’t come at the expense of wasted time or unproductive interviews.
Feedback after your project
Documenting your project will crystallize your learnings. I’ve found it helpful to keep detailed notes of how I did each step in my process: what worked well, what didn’t work well, and what I’d do differently next time. I store this mini “case study” somewhere other team members can find and access it, like alongside the research findings or in another shared repository.
With that, you won’t need to start from scratch the next time you need to do a research project. And if others on your team want to embark on their own research, sharing your documentation with them has the benefits of propagating your own work and making their lives easier. Best of all, you can iterate on your research efforts over time — mitigating the drawbacks while maximizing the value that research provides.
What have you found helpful when conducting research? Leave a comment below! 👇
I hope you found this newsletter useful! If you’re interested in reading more, subscribe here for free and share it with a friend. You can also find me on Twitter (@wontonface).
Have a topic idea or request you’d like me to cover? Submit it here.