User interview basics No.1 Listening sessions

Practicing UX research while working on a new product or product updates is the key to building usable products that can be delivered fast and fit the market. Stakeholders are full of ideas, product owners are full of ideas, designers are full of ideas… but none of what we ideate has value if it didn’t come as an educated insight about the needs of the people who will (or will not) use the product.

Having a feature requirements list that we nail in terms of best practices of UX patterns and technology development can be all for nothing if the people who should use our product just don’t need the feature as we ideated it. This is probably the hardest part to really understand for both the stakeholders and the project teams, possibly due to the lack of continuous practice of UX research that could provide the understanding and make a world of difference when it comes to the success of the project. 

To avoid producing beautiful designs from the “requirements list” that no one needs or wants, we can validate our ideas before we rush to decisions. We do it by using the right UX research methods. 

One of the easiest ways to understand people’s needs is to ask them the right type of questions at the right time — this is where user interviews come into play and, depending on the project phase, we can use the type that will give us the most benefits.

Benefits of user interviews

User interviews are mostly used in the format of qualitative research methods for gathering an understanding of other people’s thoughts and purposes by open listening or using structured questions. There are three general types of user interviews that can help us depending on the phase of our product development.

  1. Unmoderated interviews a.k.a. Listening sessions – problem space focused method (foundational/exploratory) and the protagonist of this blog. This interview type is used early in the project before we can say that we know what problems need to be solved and to get the foundation to even have an opinion.
  2. Semi-structured interviews – solution space focused method (generative to evaluative). We use these interviews early in the project, but after the problem space is validated to generate “how might we” ideas.
  3. Structured interviews – solution space focused method (evaluative). We use them late in the projects to evaluate design solutions that are based on previous research steps.

 

In this blog, we will look at the unmoderated user interviews, also known as listening sessions, since this method supports validation of problem space.

The problem behind the problem

Missed opportunities resulting in unwanted products or budget problems can lay in the wrong interpretation of the problem we are solving (which defines the scope).

As we’re afraid of uncertainty and of not knowing, our brains jump to conclusions before we even allow ourselves to think about “what is the real problem we are solving with this product”. If we have an idea of the solution, we feel safe — that is how we get blinded and deafened by biased brains and miss all valuable pieces of information.

 

The paradox of that is next:

  •  when we want to avoid some bad outcomes (like breaking the budget or missing the product-market fit) we focus more on this fear then on what our real job is (the set of unbiased steps of standard practices which, if done properly, will result in all good outcomes we want)
  • by being afraid of the wrong outcomes (bad decisions), we want to overly control them without the awareness that just by controlling a little less (which can also be helpful for not going crazy) and applying the right practices at the right time, we will get the most of the good outcomes we want (by avoiding it, we’ll get where we initially didn’t want to be)

Because of this, UX/strategy research is oftentimes skipped, sometimes treated as an “extra cost” that may not be meaningful for launching the MVP or even butchered to fit the fast paced agile environment. Businesses want their MVP products out as soon as possible to test the market, and they want to pay less for product development so they don’t lose a lot of money if there’s no product-market fit. The fear is valid, but the response is oftentimes wrong. 

Let’s invoke the paradox part again – by not going through this thorough UX research of the problem space, we miss the opportunity to find out what would help our users and what they would actually pay for (product-market fit) in a crowded market, before we even start spending money on the development. Luckily, user interviews can be looked at as a less costly method to get a better sense of what people need, we just need to listen carefully.

What are listening sessions

The unmoderated interview is a professional way to say “we will have an open conversation about your problems and purpose – how you do your thing, and why”, so this is why we call them listening sessions. In this type of an interview, we’re here to listen with empathy, so it is not much of an interview. Yes, we do need to facilitate the conversation, but not with our idea of how the conversation should be (how others should think), but based on the insights we’re getting from the person we are talking with — as we talk. 

The same way as you would talk with the friend that wants to tell you what happened to her at the job today. You wouldn’t start guessing and leading your friend to answers you wish to hear, you would just listen deeply to what was her problem today. And also, you would encourage her to let it all out, accepting her truth without modeling it to fit your view (what empathy is in the core).

If you do a proper job of being a respectful friend, you would be there for her to listen, and not for you to show how smart you are by guessing the solutions or showing off that you know how to handle those types of problems. Afterward, if you honestly want to help your friend, you would take some time to structure what you hear to get a sense of her problem. Maybe you would even invite her for lunch a few days later, where you would ask her more questions inspired by what you heard and slept on a couple of days ago (the equivalent of semi-structured interviews). 

This is why the most important thing to do while conducting listening sessions is to conduct it with an honest need to listen to someone’s problems — with deep empathy and acceptance of other person’s reality.

When to use listening sessions?

When starting with the product, it is important to wait for the conclusions until getting the basis for them. It is normal to start having ideas about the product we are working on from the start, but if we know little or nothing about the needs of the people we’re building it for, we need to get a broader sense of the problem space (which is always). The tricky part is that ego lets you think that you understand something before you actually do. 

To test this on yourself, ask yourself “do I have the hypotheses” before conducting any meaningful problem space-focused research method. If you do, say hello to your ego, here it is and you should question it. 

 

You might have a sense of first problems, but digital products are solving problems within problems, which you cannot know if you didn’t explore deeper before you created your opinion. This is when we can use listening sessions to get valuable insight by purely listening. As the name suggests, for this type of interview we won’t be preparing questions and structure, because we don’t know what the structure is in the first place — it is too early. If we think we do, we are probably wrong. Rather, we will have the underlying topic in mind and let the conversation show the structure.

Benefits of listening sessions

To get a better sense of the benefits of this method, we can look at the next hypothetical example. Let’s say you are working on a product for school management where most of your audience are teachers. The stakeholder’s idea is to have a set of features (popularly known as “this is the requirements list we need to have”) that would help teachers to keep track of their projects. If this feature list is only an idea and the problem space is not validated, you want to talk openly to the people who will use the product and get a better understanding of their job. For example, it might look something like this:

  • The interviewer asks a slightly leading question to kick-off the conversation: “So, tell me about you and your job a bit, what do you do?”
  • The user answers: “I’m an elementary school principal and I’m working at the school with 300 kids, from kindergarten to eighth grade. There’s a lot going on every day. I am responsible for working with the teachers and coaching them, implementing the school strategy, tracking our student and teacher scores, tracking the progress of our school projects,… there’s a lot of responsibilities I either overview or implement.”
  • The interviewer asks an open question inspired by the answer: “How do you manage those responsibilities?”
  • The user answers: “Well, I overview a lot of different data, some of it I get from the teachers, some I collect myself. The key is to stay organized and have people who do their jobs responsible. Everyone has a lot of work to do every day, me and the other teachers create good strategies, but when it comes down to put those strategies in practice, oftentimes other responsibilities take our focus, and we start missing the deadlines, forgetting to do something and stuff like that. I like to be the “go-to person” for my team if they need help with the implementation of strategy, but it does take a lot of my time and often, the results are not that great. I like the feeling of getting stuff done and getting the benefits for all of us from that, it helps our school to get better each year because that means our students have better education, which makes me happy. Sometimes it’s hard, but it is all worth it in the end so I don’t mind.”
  • The interviewer asks an open question inspired by the answer: “How do you manage the organization with your team?”
  • The user answers: “I use a good old planner and calendar to keep track of the deadlines. If we know the deadlines, we can work on the strategy for delivering on time. We as a team of teachers have regular sync meetings where we look at the calendar and go through everything that needs to be done or commenting on the progress and if there are some roadblocks.”

 

 

This conversation could be very different if we were to ask closed or leading questions. Here is another version of the same conversation:

  • The interviewer asks the leading, closed question pre-framed by the information she had before: “You are a school principal, right?”
  • The user answers: “Yes, I’m an elementary school principal.”
  • The interviewer asks a leading, closed question: “What’s the number of people you are working with?”
  • The user answers: “I am leading a team of 5 teachers. That team leads 30 other teachers.”
  • The interviewer asks a leading, closed question inspired by personal experience: “Is this frustrating sometimes?”
  • The user answers: “Well… I don’t know, I guess it could be. Yeah, I can imagine a day where it could be frustrating. You have a strategy for getting better results, and then when you fail to do so, it can be frustrating, yeah.”
  • The interviewer asks a leading, closed question inspired by the idea she drafted as a solution: “Do you think that having a tool with strategy improvements suggestions would help your work be done better?”
  • The user answers: “Well… I guess it could be helpful. Yeah, why not.”

If you look at the first example, you can catch the insight that this school principal has a good strategy, it is just time-consuming to follow it through due to a lot of responsibilities. To get to a specific point, we can majorly affect other people’s thinking and responses if we are not careful with the questions we are asking. By this, we can either get the wrong information, implanted in the person by our bad moderation skills, or we can get correct information, but not the one that opens the problem space. If we don’t get the correct problem space blueprint, we will start solving the wrong problems and it will show in a form where users are just not using our product. 

So, what we want to focus on is:

  • Keep open, unbiased ears and brains (self-deception, self-confirmation biases on the horizon)
  • Don’t suggest or lead the person you are talking to — you want that person’s story, not to confirm your idea (confirmation bias and framing bias on the horizon)
  • Stick to open questions if you are fresh in this, and if you feel you can guide a person a bit more (framing/priming bias on the horizon), you can ask specific questions if you smell the insight coming 
  • Don’t over-confirm the person on the other side out of fear, one “mhmmm” every now and then can do well if you want to reassure you are listening
  • Practice this in regular conversations 🙂

How to conduct a listening session

Listening sessions in their full glory should be predicted a few steps before. As a first step, we always need to know what business we should support with the product we’ll be working on, so we need a business strategy, no matter what. It is not rare that strategies are based on ideas, not on rational strategy and usable metrics, so this is the first step to tackle, but not the one I will talk about in this blog. 

Secondly, we need to know who to talk with, which in the ideal cases is tackled by task-based audience segmentation. If audience segmentation is done properly, we will get a validated starting point for sourcing direction. Let’s invoke the real world back, oftentimes we won’t be able to get the budget for this, but you can still do guerilla versions and brainstorm who would be those real people you could talk to, and how many user groups there are to talk to based on common sense or interview with the client. Either way, we would need to source at least 5 people per user group to participate in the listening session.

 

Remote work is no problem at all regarding the conduction of listening sessions. It is much easier and more beneficial to do listening sessions remotely. People you are listening to will be more relaxed in their own environment, especially if the session is audio-only. Even though body language is useful in understanding people, it is not needed for this matter. We wish to hear the person’s thinking process, so by using audio-only, we will have a better focus on exactly that. 

It is good to raise self-awareness on why we are asking open questions. It is so we don’t frame or prime other people to what we think about the topic, but also to really understand that we need to build the idea by first listening deeply. To do this more organically, rather than having a constant pressure of reminding ourselves to ask open questions, it helps to generally raise awareness about how much we really don’t know. 

This helps us to go into a natural state of being interested and open to listening without prejudice.

The listening session should be recorded since our focus will be on listening and asking questions we’ll want to analyze later. When we get to the analysis part, we might catch some of the tools or practices that help these people while working, like the “good old planner or calendar” that our imaginary user said. The key is to map the thinking process and actions, but also the underlying purposes of people we are building a product for, and to match all solutions we might work on (features list). If there’s a good match, the next step is to chunk it into smaller portions that the product team can discover deeper and deliver good solutions. But… oftentimes, we will have a mismatch, which can either go in the direction of updating the overall business strategy (good) or trying to compromise and rethink at least some of the features (realistic). The advice is to advocate the compromise and try to visualize this mismatch to get the point right.

Who do we need on the team?

For listening sessions, it is not crucial to have fellow researchers as a part of your team, since these sessions are 1:1 practice and you will have the recording at the end to analyze. What is much more important is the skill of listening and a level of personal empathy. Those two factors play the biggest role, but the cool thing is that you can practice it every day. Think about how you are listening to your colleagues, friends, family… Every conversation is a great way to sharpen your skillset, and your closest people get to have a good listener around.

Where you can use the team’s help is in the preparation for these sessions, and later in producing the outputs. In an ideal world, you would always have the benefit of a team, but since we live and work in the real world, we often need to cut down the expenses to get the chance to conduct the research. 

Preparation for this is knowing the business strategy which is a collaborative process with the product manager. 

Your research team can help with: 

  1. the definition of a task-based audience segmentation 
  2. the process of brainstorming and building proto-personas
  3. the process of sourcing 

Once you get to the listening sessions, it is OK to do it by yourself, but you can have one person by your side so you can overlook them for personal development or to help you out as your tech support. 

What we’re focused on while conducting listening sessions are the guiding principles and purposes of the people we are talking with. After the session is conducted, we will need to transcribe the most important and insightful parts of the session to be able to analyze them. Here, you can get a team member that can take some of the recordings and pull out the meaningful parts, but be sure that this person has some experience with this. Ideally, this would be done by the person that was conducting the sessions to ensure the same level of thinking consistency. 

This insight we gather from the analysis can be grouped into mental maps/models that will show us how different people have different needs from the same thing – this would be open for a team approach, but you can do it by yourself. 

From this insight, we can get a better sense of what is the purpose of the product (or a feature) we need to build, what problems should be addressed and for who are we solving them – we do this by matching the real need and purpose with a feature. Operatively, this could be supported by the team that can also work on making simple visualizations and presentations that clearly show how much we support the users with the current solution ideas.

To sum it up

Advocate problem space validation to the stakeholders and product managers, stress how important it is. Listening sessions are a less costly technique with which we can research people’s real needs early on to find out if we have a product-market fit before we even start developing the product. 

Use listening sessions to validate or update the business strategy that needs to be backed up by the product you need to develop. 

Practice listening and empathy in everyday situations to boost your skillset, so that you can be in the zone when you conduct the first one.

If you search for more mindset and practical advice, I would highly recommend my personal hero — Indi Young, and her blogs, lectures and most of all her books. She has a big experience, great understanding and knowledge on how to approach the problem space and advocate good practices of UX research that can help you do your thing.