An introvert’s guide to starting user interviews
Conducting user interviews can be incredibly valuable but also a bit scary to start
Product designers have a lot of techniques and tools in their back pockets when it comes to researching and understanding the people (users) they design for. A tricky thing to get designers to do is actually spend time having conversations with their user base — because let’s face it, a lot of us are introverts and the idea of having a Q&A with a stranger is terrifying.
I understand, I’m one of those people who gets nervous talking to strangers.
However, the benefit of stepping out of our comfort zone and engaging with the people who use our products far outweighs the awkwardness and Imodium-fueled moments leading up to those first few user interviews. I wanted to share in this post the revelation I had on the benefits of sparking scheduled live conversations with customers. This is really an effort to (hopefully) curb some fears and stop some of you from putting-off those first interviews like I did.
For a few years now I’ve been using amazing tools like UserTesting.com and Optimal Workshop, as well as tapping into some of the research teams within the company I’m at. As a product designer, my research sometimes comes in tiny waves and so it’s up to my team and I to lead and conduct our own surveys, usability tests, card sorting exercises, etc.
For the longest time, live conversations with our users were avoided. I say avoided because that’s exactly what I was doing. It’s easy to play the “I just don’t have the time” card, or “let’s use a survey instead”, but the reality I felt in my gut was that these excuses were holding me back from really connecting with the people who used the products I was creating.
I remember hearing from our director and other colleagues about how they had these amazing conversations with our customers (we call them members) and the sometimes tear-jerking moments that fortified our purpose in what we do. I also reflect a lot on when I first joined this particular product team and was brought to a fitness class with our members. It was the the most welcoming and exciting experience to see the people I design for in their element. I loved hearing their stories and how they got into the healthy lifestyle they live today.
I wanted to know and connect more with our people.
The Worries
I can see why some designers shy away from the word “user”, as it can sometimes be forgotten that these users are actually people. To me the wording is fine either way, just as long as we engage with our users as they actually are: people. Not numbers. Not statistics. People.
As much as I wanted to meet and talk to our members, I knew there was a certain something that was scaring me and holding me back: my fear of talking to strangers. You know, that reason a lot of us don’t go to happy hour mixers and networking events. The only problem was this scenario was something that could help my team and I almost immediately. But I had so many questions:
- How do I coordinate time with my users to talk?
- How do I get honest insight and not contaminate the conversation with my own views?
- What if I say something stupid or offend the person?
- What if I don’t have enough to report back on to the team?
- I’m so awkward on camera, what if I look like an idiot?
- I’m no researcher, what if I don’t ask the right questions?
With Live Conversations being a feature on our UserTesting.com account, I knew this was going to be the most effortless way to coordinate everything. Fortunately our contact at UserTesting.com was also extremely helpful and supportive of using this feature, so I had no excuse to NOT schedule something. It was so incredibly easy.
Now the big worry: what if I screw up the interview? Contaminate the conversation because I try to relate to the person too much, or show too much enthusiasm so that it sways their answers? The only way to conquer this was to just give it a try. Seriously, what did I have to lose?
The reality was there’s no better way to learn than to do — so if I messed up the first few times, no biggie. I’d learn from it and do better next time. There’s a massive pool of members and users on the site for me to tap into, it wouldn’t be that bad.
Spoiler alert: I did mess up a bit. During my first few interviews I jumped immediately into the questions instead of having some idol chit-chat to ease into the conversation. It wasn’t the most welcoming approach.
Ok, but what if I say something wrong and offend a person I’m interviewing? Eventually I decided this was a stupid worry because the people I’d be talking to were some of the most humble, kind, and pleasant individuals to be around: senior citizens (I wrote in a previous post about why they’re amazing to design for). And when it comes down to it, I’ve always been most comfortable talking to people twice my own age.
How would this be any different? Was it because it was work related? Rubbish. These were still the same glorious people I enjoyed chatting with in the supermarket checkout lines or at the fitness class I attended in my first days as a product designer.
By now I was to the tipping point, and with a new project coming up there was a perfect opportunity to simply talk to a few members and dive deeper into their “why” around a certain question. A survey just wouldn’t explain anything beyond what we already knew, and no other research method made sense. It was time to just get over the fear, throw away the excuses, and schedule those first interviews.
The First Interviews
To begin my user interviews I pulled from random bits of knowledge I had from the Interaction Design Foundation UX courses, techniques other product designers mentioned, and simple best practices from the UserTesting.com site.
I should mention that this is simply the approach I first took. Looking back, there’s some areas that might be a no-no for conducting user interviews. For instance, I did mention other users during an interview, trying to confirm their answers to a question with answers of others. This drove them to not think deeper about their own experience.
As Patrick Thornton writes in his guide, “How to conduct user interviews”, this is something you want to avoid, especially in framing up the question for the first time as it can make someone feel like they must answer a certain way or they could be wrong.
Outline your questions
I started by outlining the questions I wanted to ask around a certain topic, creating a semi-script to follow. One thing I didn’t want to do was to make this sound like some script I was reading. I wanted people to feel like this was a conversation where they could be totally honest, meaning I needed to be flexible on my questions and sound genuinely interested (not robotic).
This is actually an approach others take as well. Nichola Rushton does a great job explaining in her article, “Stop doing user interviews. Start having conversations” about why having a real conversation with your users gets much better results in the end.
Because I was tapping into the panel from UserTesting, I knew there was a chance I might get some people that were not actual members but fit the demographics of my user base. I created paths of questions for these people as well, that way I could get similar insight without awkwardly cutting the conversation short. I found out later that this was going to be immensely helpful as we sometimes breezed through the first few questions.
Schedule one interview
I generally like to do a “dry run” of every survey or user test I conduct to make sure there isn’t anything I’m missing, or that’s too confusing. For a live conversation, I scheduled one session by myself. Normally people can observe an interview or you’ll have one person conducting the interview while another takes notes. To avoid my fear of embarrassment (and because these sessions would be recorded on video) I decided to just let it be me and the member having a conversation.
This proved to be extremely helpful and made me feel less nervous about messing up during my first user interview. Later, I decided that it was actually possible to just conduct all these interviews by myself and take notes later after re-watching the conversation. It also helped with making the people I was interviewing more comfortable, as I made it clear nobody else was in the room.
I’m not saying this is the best practice, and I’m sure some seasoned UX researchers might be cringing at not having extra people to chime in and ask additional questions on-the-fly. For me and my team, this worked.
Accept the imperfections
The first time I re-watched an interview to take notes I cringed at my goofiness. I also started to get super critical on things I was saying, like “great!” as a response to everything…even bad things. Something strange happened though: I started to see that the person I was talking to got more and more comfortable as the conversation continued, and the results were amazing — I was getting great insight and my quirks or “mistakes” weren’t noticed by the person I was interviewing.
When you first start interviewing your users, you will most likely have lots of areas for improvement. In the end, if you’re getting good insight, having ah-ha moments here-and-there, and the people you’re talking to seem comfortable and happy; then you’re doing a decent job.
Remember earlier when I talked about how I jumped into the questions too fast? I not only observed that myself and noted it as a fix for me to work on in the next interview, but I also asked the design community on Twitter how they approach the chit-chat before diving into the questions. The answers were so helpful, but it ultimately came down to, “it depends!”. Does the person you’re interviewing want to jump right in, or do they need a little more effort in feeling comfortable with you.
Bottom-line, we’re always more critical on ourselves than anyone else. What you’re doing is most likely still very useful. It’s important to learn from your mistakes but I had to remind myself to not be self-destructive or too critical. I was the first one on my team conducting these interviews, so I was already a step in the right direction.
The Report
The final thing to note is just how much more time it takes to summarize your findings in these types of user interviews. I may not be as experienced as some of you reading this, but here’s my take so far on the reporting:
A survey or user test has key moments to pull from, and sometimes can have very similar patterns. Interviews are much different, even with keeping the conversation on track there can be much different motivators or answers to write down. They’ll have more context, so the documentation needs more of an answer.
I found that my typical lengthy bullets of notes with key takeaways was great, but there was no way others were going to read this thing. Instead, I’ve decided to take the approach of creating a sort of fancy Adobe InDesign-fueled PDF of slides that break out key takeaways and form an empathy map.
I realized something else through all of this though — my excitement around talking to my users couldn’t really be conveyed through the giddy enthusiasm I was projecting to the rest of the team. It really would help to have people in the room with you to see firsthand how these interviews go. There’s a certain appreciation you have when you’re either conducting or a part of these interviews with customers that can’t be transferred in a report or debriefing.
So get out of your comfort zone and start talking to the people you design for! It’ll most likely brighten your day and shed light on your users “why”.
