Join over 150k subscribers to get the latest articles, podcast episodes, and data-packed reports—in your inbox, every week.
SUBSCRIBE TO OUR NEWSLETTER
October 6, 2020
Overcoming bias and being prepared for any kind of user interview.
Anything that will help people to understand how to get to the heart of an issue, including unknown influences on that issue, is alright by me. Too often I see people hone in on one issue, but ignore the processes and thinking that got them into that issue in the first place. Design thinking encourages you to think through and around the problem at hand, leading to a holistic approach to a solution.
If you have a passion for learning the whys of user behavior toward a product or situation, you can succeed without an advanced degree in UX. This passion will drive you to make sure you ask questions the right way to avoid biasing your participants. It will also drive you to understand where your product managers and other stakeholders are coming from.
Thinking they know how to ask unbiased questions. They often don’t. I’ve seen countless product managers ask the equivalent of ‘We’ve been working on this feature for months. It’s supposed to help you do your task. What do you think about it?’ I’ve also seen people assume they know their users because some research was done years ago and perhaps they go and visit a few customers each year and make faulty assumptions based on that and then, because time, money and resources have been invested, they refuse to challenge or validate their hypothesis.
There’s more psychology in UX than people are willing to admit. Your demeanor with your participant will decide if they are at ease with you. If they aren’t at ease, you’ll have a tough time getting feedback. Your reactions, if your participant can see them, are important to note and control as much as possible. Participants want to provide useful feedback, and if they think they are pleasing you, they could continue with feedback that might not actually be entirely true for them. But it’s also important to not be too clinical, as you need to establish a rapport to get great insights. When it’s time to present findings, psychology comes into play again. Who is your audience? What’s most important to them? What are they afraid to find out? You need to understand them so you can structure your presentation/report accordingly.
I’m a planner. I make sure I have my discussion guide handy and I review the participant information to ensure I understand who they are in relation to the research topic. I also fill up my water bottle and make sure my pen has ink, since I like to take notes sometimes during the session. Also, I like to give myself 15 minutes in between sessions for a break and/or time to talk to stakeholders to see if they have any changes in the script or design which we need to implement before the next participant.
For interview guides, notes, recording, prototypes, etc. Word to build my discussion guides, Excel for notes if I’m not in person (Put the questions in the far left column and each participant across the top, that way you can scan the answers once it’s time to write the report).
When I’m in person, I’ll jot some things down on a notepad or the discussion guide. For recording, I’ve used Morae, but with so many stakeholders and customers being located around the country, more and more companies are switching to Webex, Zoom or GotToMeeting for recording.
I don’t create prototypes, but I’ve used PowerPoint, Invision, PDFs, and Axure to showcase prototypes. I’ve also used my phone for SMS with stakeholders while I was in the room with a participant. It’s a good way to get additional questions in real time.
My main trick is to start relaxed myself. I tell them my job ‘User Experience Researcher’ and how that’s just a fancy word for someone who talks to people, like yourself, all day. I also make sure to tell them I’m not aligned with the product in any way other than to tell the product managers what I learned during the sessions. Also I tell them to share the ‘good, the bad, and the ugly’ with me, because I not only want to know what isn’t working, I want to know what is working so we don’t mess with it when we are trying to improve things. I make sure to ask them if they have any questions or concerns before we start with the test. During the session, if they are quiet and there’s not a lot to read, I like to ask ‘So what are you thinking?’. That usually gets them talking a bit more.
Since we are distributed, we use an Office 365 Excel document to take notes during the session. We encourage all our stakeholders to add their notes as well. Once the study is over, I take those notes and put together a PowerPoint presentation that distills our learnings. Sometimes, we present at our weekly design meeting (open to all in the company and attended by many stakeholders) and field questions from them. We always present the findings to the immediate stakeholder team, though. The next step is to archive the report and all associated study documents (notes, videos, prototypes, discussion guides, etc) on Sharepoint so anyone in the company can access it. We have started our own insights library where we use GitHub to store insight bites. We tag each so they are searchable. We are hoping to use this to make it easier for our stakeholders to answer questions about previous research as well as help newcomers to understand what we already know about our products and customers.
If you'd like to be interviewed for Other Side of the Table, reach out to email@example.com.
Want to contribute in another way? Check out our guidelines here.
Ready to launch a research project and easily recruit quality participants? Get started here.
VP, Growth & Marketing
Left brained, right brained. Customer and user advocate. Writer and editor. Lifelong learner. Strong opinions, weakly held.