User interviews are one of the UX tools we use the most to carry out product iteration. Knowing what solutions they provide, what problems they encounter in use or what pain points they solve can help us create solutions or improve existing ones.
Before the pandemic, we were already conducting many user interviews remotely, avoiding unnecessary travel for the team and thus speeding up deadlines for final conclusions, as planning could be more agile with less non-productive time (travel).
Given that one of the main missions of this blog is to share knowledge, we have compiled all the information we have in various posts to create this User Interview Guide which, we hope, will help you to understand what an interview is for, to plan it and to obtain the expected results.
What is a user interview?
An interview is a UX research tool used to obtain or verify information from users, as well as to validate business hypotheses.
We use the interview to find out what the user’s pain points are, what their expectations are or even what their wishes are. And, of course, we will ask the right questions to obtain all this information.
Note that with the interview we can also contrast information we already know, for example, through other tools such as the review of analytics or surveys.
Prior to the interview
First, you need to consider whether the interview is the right tool for the research you are going to conduct.
There will be times when tools such as heuristic analysis or a well-planned and executed A/B test can give you the information you need. Even reviewing the analytics in the case of a digital product can be an option to see potential points of blockage or doubt for the user.
There are many tools that can be used to gather information. Moreover, the interview has to make sense in your UX Research strategy.
If the interview fits the strategy, before you sit down to write questions, consider the objective you are trying to achieve. In reality, you don’t need to know what users do or what they want, but many other questions are often hidden and not easy to find out at first glance.
In order to set the objective of your interview you have to answer a couple of questions beforehand:
- What do you want to know about your users or what hypothesis do you want to confirm with concrete data?
- How can you use this information to improve your product design?
Your answers should always be specific and precise. Don’t make it your goal to find out about our users, because such a general question will get you nowhere.
Examples of objectives for your user interview:
- Find out how job seekers interact with mobile devices.
- What are the familiar behaviours when it comes to cleaning tasks in the home?
- Knowing the possible frictions in some areas of an online shop.
With all this in mind, you can start planning the details of the interview.
Online or on-site interview
At the beginning of this post, we have already discussed some of the advantages of remote interviews (such as avoiding travel or increased efficiency).
Although face-to-face interviews are still necessary, as they provide information on the non-verbal language of the user. However, all security measures must be strictly followed for the duration of the emergency situation. We would even go so far as to say that these measures should be maintained, both by users and interviewers, for some time after the end of the health crisis.
A tip for both cases: look for an environment that is as familiar as possible for the user. If the interview is face-to-face, it is best to hold it on the company’s premises. If the interview is remote, offer several options of the most commonly used online tools. Or even the telephone.
Profile recruitment and sample size
Recruiting your interviewees is always crucial. It is best to create several profiles based on both demographic criteria (gender, age, place of residence) and behavioural criteria (operating system, activities, type of use) and write them down in a document.
This document is called user recruitment screener and it is a guide to always have clear criteria to be used for recruitment. With it you will be able to facilitate recruitment and achieve better quality results.
It is also not necessary to create profiles that cover 100% of the target users: two or three is usually more than enough to obtain information without falling into repetition.
As for the size of the sample, it will depend on the project. We have worked in some sectors (medicine, administration) where a sample of between 5 and 10 users was more than enough. If you only have one profile, 5 users will allow you to obtain quite enough data to draw conclusions.
In other sectors (automobile, energy) the sample size has been close to 20 users, even more, such as in some global UX Research projects in which we have participated within the UXalliance.
You can plan all of this yourself or use one of the specialised UX research user recruitment agencies. You will need to take into account the associated cost and that users will usually receive compensation for their participation.
Build a trusting relationship with users
Once you have selected your users, they are categorised into profiles and the sample is relevant enough, it is very important to start building a trusting relationship with them.
This is achieved through a simple phone call or a video call to discuss certain details of the interview: schedule, possible requirements of the call, the estimated duration of the call and, of course, the possibility of answering any questions.
Concerns may include the use of personal data or your own image (e.g. if interviews are recorded). Even if the user does not ask, take the time to explain all the implications of personal data protection and confidentiality.
If we are able to explain in an easy way all the possible implications of the interview, the user will be more receptive and there will be no hesitation at the crucial moment when you start asking questions.
That is why this first phase is so important: planning is the best way to succeed.
Structure your interview
All interviews need to have a defined structure. A good script will allow you to gather the information you need without distractions, as well as allowing you to address certain topics as the interview progresses.
This script will allow you to avoid blocking situations and to continue the conversation even when the user does not respond to any of the questions asked.
The basic structure you should always keep in mind is as follows:
- Introduction: Presentation of the interviewer, objective and consent for recordings.
- General introductory questions: these will help you to gain the user’s trust and empathise with them.
- Specific questions.
- Closing the interview.
Preparing interview questions
When preparing questions, start with the most obvious ones. In fact, they are the ones that relate to the user himself:
- What motivates the user to use a solution like yours?
- How have users performed with the product so far?
- What matters most to users when using similar solutions?
Preparing questions as a team and opening up the process to everyone involved in product development is an excellent idea. It doesn’t matter if the questions they provide are timely or not: having a large number of questions will allow you to discard some as irrelevant at first, but you can use them later for further questions or have them as a safeguard in case the interview runs a little bit short.
In fact, this also brings us to another tip: don’t be short. If the estimated duration of the interview is one and a half hours, prepare questions for two hours or even more. There will be some questions that the user will not be able to answer or that will be answered at the same time as others, especially in a semi-structured interview with open questions.
From here, the best thing to do is to organise the questions in a logical order. You can use other tools for this logical order: journey maps or service blueprints can help you to organise your interview questions in a logical order.
Finally, see if you can add additional follow-up questions to get more information or even go into more detail. Sometimes the user may not give you a specific answer, but you can ask for details. In fact, the script is not in itself a strict document: it is merely a guide that the interviewer will use to address the subject matter of the interview, but will be free to go into more detail as the conversation progresses.
What to avoid at all costs
The answer here is easy: questions about the future (have you planned what you are going to eat tomorrow?) or full of technical words and internal jargon.
Humans are neither reliable nor good at predicting the future. A question such as “what are you going to eat tomorrow” does not add anything to the interview.
However, you can ask do you usually plan your meals in advance? as the answer in this sense can be open-ended and provide relevant information for the purpose of the interview.
On the terminology side, the user does not necessarily need to know certain commonly used terms, such as the hamburger menu. As with everything we do in UX, an interview needs to be easy to understand, inclusive and accessible.
During the interview
If you have worked well throughout the preparation phase of your interview, your users will arrive comfortable and relaxed, as they know what to expect and will be confident enough to answer your questions honestly.
In order to conduct the interview with your users, there are a number of basic tips you should follow:
- If the interview is face-to-face, make sure you have all the necessary safety equipment ready (PPE, gloves, gel, masks if necessary) and respect the necessary distance between people so that the user does not feel uncomfortable.
- Although it may sound repetitive, start the interview by explaining what the purpose is and what will be done with the data collected.
- Organise the questions to start with a few questions that are easy to answer and as open-ended as possible. This will allow the user to relax and reduce tension if necessary.
- Show the user that you have their full attention: take notes, nod and don’t forget about eye contact. In a video call, you can make direct eye contact by looking into the camera.
- Don’t be in a hurry and allow users to reason and respond. Talk to them slowly and calmly.
- Show empathy. This is one of the most important soft skills to work in UX and cannot be faked. This empathy can be active, showing concern for something that the user transmits, or passive, not asking questions again when detecting an uncomfortable situation.
Avoid leading and closed questions
In leading questions, the answer is already implicit in some way when formulating the question, which can damage the final result of the interview and not achieve the objective you are looking for.
If we ask the user why do you think the navigation does not work? the user will only refer to the navigation as a possible problem when it comes to analysing the information architecture.
However, if we ask how easy or difficult it was to find what you were looking for? the user no longer receives a specific piece of information in the question, which will facilitate a much broader and more elaborate answer.
Important: when establishing how the questions will be asked, avoid putting the focus on the user. The first question establishes potential user guilt (it doesn’t work because the user doesn’t understand it) and this can ruin the relationship of trust on which all interviews must be based. Although user shaming is a classic dark pattern, it should be avoided at all costs in interviews.
As for closed questions, they can be used to lead to a follow-up question or to get a very specific answer, but overusing them can give a sense of interrogation and make the user uncomfortable.
And what about after the interview?
With all the notes you have collected, you will need to proceed to the data analysis. Keep in mind that there are objectives and the data collected will be used to refute or validate the hypotheses.
Our advice is to convert the information obtained in the interview with your users in order to classify it into a series of codes that will later be used to draw conclusions that can be included in a report.
This coding will help you to understand different answers that refer to the same topic. For example, let’s look at these two answers from two different users:
- It was easy to find what I was looking for. The links at the bottom helped me a lot. And if not, I can always use the magnifying glass to type in what I need to find. Anyway, I think the website could be organised a bit better because there are too many things that are too much the same and sometimes I had to go back to where I came from.
- Whenever I’ve looked for something, I’ve always found it. The truth is that I don’t complicate myself too much and I use the search engine for almost everything because it works very well. I use it a lot on my mobile because it even detects spelling mistakes.
In this case, we can codify both answers according to the topic: search engines provide answers appropriate to the user’s needs.
From the first, we can also add: information architecture to be reviewed.
Translating the users’ answers into relevant information is essential in order to be able to prepare the interview results report. This report can have the following structure, similar to almost any other report you will present internally or to a client:
- Introduction: objectives.
- The methodology used: selected criteria and methods; script used during the interviews and the questions asked.
- Main findings: you can present this information translated into tables and categorised according to the order of the questions to facilitate the understanding of the report.
- Recommendations to be implemented, along with their priority or urgency.
- Annexes with all relevant information about the process followed.
Like any good report, it should be actionable: recommendations should be able to be converted into concrete actions in your product.
We hope this guide will help you to prepare your next user interviews, especially to plan them in order to get the information you need from your users.
This article is a translation of the following one published on our corporate website: