Interviewing as a User Researcher – UX Collective

To start, we, as user researchers, are a weird niche. We don’t really have too many tangible deliverables we can show people, at least ones we exclusively worked on, we can’t always share insights we’ve gathered at previous companies, our user interview sessions are often confidential and anonymous so we can’t share those and, most times, showing someone a discussion guide example doesn’t give them an actual idea of how you perform interviews.

Thinking back to the (many, many) interviews I have taken part in, I have compiled a list of important topics to bring up or give examples of. Of course, this is merely my experience being generalized across numerous variables and situations. However, if you are preparing for your first, or fiftieth, interview, reviewing these ideas may help during the interviewing.

Start by showing enthusiasm and try to maintain that throughout your entire interview. There is a common idea that researchers should be excited about problem-solving, conversations and challenges. We should bring a spark to a company that helps others get excited about research. If you are enthusiastic about your job, and are personable during your interview, most companies can use this to judge how you may act in a day-to-day environment

It is very important to highlight how you have incorporated teamwork into and collaboration in you user research practice. Who have you worked with before? Was it just the product team or did you work across different departments? What was it like to work with others? What were the challenges you have faced? Some of the joys? This is a time I like to reference specific moments in my career. I usually will also bring up how I have managed to get buy-in from team members, as that tends to bring that question naturally into the conversation

Similar to teamwork and collaboration, it is important to bring up your skills in communication. This can include many different examples, such as sharing research insights to teams and executives, conveying the value of user research across an organization, or speaking up when you see a need for research

I often say and believe I should treat colleagues similarly to how I treat users because, in a way, my colleagues are users of my research. With that, I have to understand what they need and want from me, what they are expecting and any barriers or fears they are facing. I talk through an example of when a team came to me with a very confusing project idea. Instead of getting pigeon-holed into their initial questions, we were able to take the time to discuss what they were really looking for and expecting. I empathize with my colleagues as much as I do users. I don’t expect internal stakeholders to be perfectly articulate when describing what they want from user research

Most companies will want to know how I approach problem-solving, of course, since that is a huge chunk of my day-to-day job. This point may be similar to the one just above it — in order to approach a problem, you have to understand where that problem is coming from and have full context. This means, not jumping directly to a solution but, instead, taking the time to speak with everyone involved in order for you to have a proper and deep understanding of the problem in front of you. Even if you are 95% sure you comprehend what someone is requesting from you, there is little harm in double-checking. You can chat about timelines here, as well, how understanding the problem can ensure reliable and useful results are delivered as quickly as possible

Give your interviewer(s) concrete examples that reference the past. If they ask you a question, instead of speaking to the skill you have, reference a previous project or moment that highlights the skills they are asking about. By doing this, interviewers are more likely to think of you as a human, just like themselves, and they are better able to relate to what you are saying (maybe it will trigger a memory for them, which could jump start a conversation)

I will briefly sprinkle in tools I am familiar with, as I’m brining up examples. This gives an extra boost of credibility, especially if you talk through a challenge you faced (such as remote synthesis sessions with team members) and how you took the time to find a tool to help (mural)

If they don’t outright ask you, I try to reference why I am excited about the specific company and opportunity. For example, I tend to talk about how the opportunity could be a great challenge for me, get me to the next level and provide a solid learning experience. Although I do reference how the company or job is different or unique, I do also talk about how there are similar components to what I have done in the past, so I will be able to effectively meet the job requirements

Please,please, please ask your interviewers questions, it can be anything, really, but, especially as a user researcher you must ask questions. It can be about the role, the company, the culture, what they like/would improve about the company, it could be about their dog, just ask some questions. Be the curious researcher I know you are, even in the interview process

Take deep breaths and make your interview more of a conversation. Also, remember, you are interviewing them as well. If something doesn’t feel right, don’t always blame yourself.

Exercises/tasks during the interview process

I have seen a few types of exercises or tasks given during user research interviews, but they are generally all relatively similar: “if X team came to you with X problem they wanted to solve or question they wanted to answer, how would you respond? What would your approach be?”

This can be very overwhelming, especially when you are trying to think of your entire process, from end-to-end, in thirty minutes, and then considering about you will be presenting said thought process to a group of people who already know the answer they want to hear.

I believe the biggest reason for these tasks is to understand your thought process. With that in mind, try not to jump right into a solution. Often, I find, there is not as much information as I would like to begin forming a research plan. I always start by brainstorming questions I would have based on the prompt. I often ask if there is prior research done on this topic and note that I would like to have further meetings with the team to really understand their desired outcome of the research. Thereafter, I jump into forming a research plan based on the given information.

I create a research plan because I feel like it includes an overview of how I think about problem-solving and my overarching approach. I am usually able to fit in everything, as well, and I typically dive into more detail as I am presenting. For example, I like to include topics such as objectives/goals, anticipated timeline, target audience (touch upon recruiting, if possible), both qualitative and quantitative methodologies, discussion guide (sample questions or sample tasks), which stakeholders I would include, expected outcome (and expected challenges, if I have time), synthesis and how I would present the insights once the research is done. Once I have this skeleton filled in, it makes it much easier for interviewers to understand my overall approach, and we can dive into the detail behind each section when I present.

An additional note: send a thank you email.

Again, this has just been my experience when interviewing for user research roles and I’m sure I’ve missed some information (as we sometimes do during interviews), but I’m hoping it can serve as a guide to prepare you and make the process less stressful! Happy interviewing!