September 18, 2019
Have a great idea for an app that will revolutionize the world and make you a successful businessperson?
Or perhaps you already have an app, but you’re thinking of tweaking it or adding some extra features the users will definitely find indispensable?
Well, hold your horses. Are you sure your app will sell? Will it fit the market? And consider the tweaks—are they really what your users actually expect?
Struggling with these sorts of questions is nearly a given in the early stages of the development process. But it doesn’t have to be, because there is a tried and tested way of answering all of them. What’s this way, you ask? It’s running UX interviews.
Because interviews, by their very nature, focus on questions, let’s take a similar tack and go through the most frequently asked questions about UX interviews. I interviewed a UX Specialist and Product Designer, Karolina Saniewska who was more than happy to throw a handful of examples drawing from her own experiences in the matter.
Karolina Saniewska: UX interviews, which is an abbreviation of “user experience interviews,” are part of UX research. UX research, in turn, is a much broader term, encompassing systematic investigations into user needs and behaviors, and performed in order to improve the user experience of a given application or a piece of software. UX research combines a variety of techniques, tools, and methodologies to discover potential problems, draw conclusions, and reveal information that may be valuable in the process of software design and development.
The techniques and methods of UX research include interviews, personas, and usability testing and they can be deployed during the ideation or validation stages of the development process.
The definition of UX research, constantly-updated by the Interaction Design Foundation, includes such vital statement:
UX research helps a design team inform the design of products and services, validate its assumptions, and—ultimately—reduce the cost of delivering a successful product.
User interviews collect user feedback and are offered to clients at the generative stage (ideation) of the development process, or when a client decides to change or add functionalities to an existing app.
In the course of such an interview, a researcher asks users questions about the topic of interest, with the goal of exploring that topic. Unlike focus groups, which involve interviewing multiple users at the same time, user interviews are one-on-one sessions.
Furthermore, user interviews are not a quantitative research method, meaning they will not yield specific numbers. But because we’ll be exploring user needs, we won't really have a need for numbers, such as percentages of people who like a given functionality, etc. Here, it will be more important to gauge whether people actually need these functionalities or not. Naturally, later down the road, it will be possible to deploy quantitative methods to dig deeper into the problem and explore it in greater detail, measuring the scale. But first, we need to know what to measure.
KS: The primary purpose of these interviews is to glean the needs of potential or real users. Therefore, we can deploy them at two stages of app development:
This is the typical approach when it comes to UX interviews. Most experts recommend running these interviews before any work on the product is done. While performing UX reviews for one of our Clients, for whom we were building a journey-planning app called “fromAtoB,” we asked the target group about their recent travels and their preferred methods of traveling and planning trips. Instead of looking to find solutions, we asked general questions to establish the most pressing needs that travelers want to be taken care of.
Here, we verify whether existing users actually experience the need we want to take care of with our new feature, or whether our hunch about an existing feature being unnecessary has any basis in reality.
Please note, however, that the interview does not include any contact with either the app or its interface. Again, at this stage, we ask about the general needs of the users, try to gather feedback on their behaviors and preferences, and explore the subject in more general terms. To gauge the usage of currently implemented solutions, we could use user tests instead. But these are two separate research methodologies and should not be conflated.
KS: First, we need to recruit a group of potential (or real) users. It’s a key stage of the whole process. We gather as much information as possible regarding the client’s target audience, the problems the client wants to solve with their app, and identify people who actually suffer from said problems. Then we add any segments we consider important into this group. In short, we work together with the client to figure out their prospective audience.
In the case of fromAtoB, we knew that the group included travelers and commuters, hailing from different age groups, who traveled at least twice a year. Because the app was intended for the German market, we reached out to an external German research agency, which made sure that the group was selected very precisely.
Another option involves using social media groups. When a client knows that their target audience spends a lot of time browsing or posting a specific Facebook group, we can publish a survey there and ask whether they’d like to take part in our interview.
People usually like to get involved in similar efforts—they’ll have an opportunity to express their opinions and receive a small reward for doing so.
Every group might be additionally segmented, producing as many as four distinct groups—a number usually sufficient to diagnose the needs of your users—with up to six people in each one.
For example, when examining travelers, we had one group with people who only traveled by airplane, and another with people who only traveled by train. Those two groups differed significantly in their behaviors. So, all in all, we interviewed 6 “train travelers” and “6 airplane travelers.
KS: The UX team prepares a custom scenario for each client, with a different set of questions, defined by the area they want to examine and the client’s needs. Then, the scenario is consulted with the client.
The interview looks more like a conversation, without simple yes-or-no questions or fishing for the correct answer. It’s also recorded on video, so the interviewer can keep eye contact with the interviewee and maintain a natural flow in the meeting.
An individual interview can last up to one hour. The atmosphere is friendly, but professional, stripped of undue familiarity. It's best to ask open questions and listen to the answers without doing anything that might imply that the answer was what we expected, nodding for example. Additionally, we want the interviewee to talk as much as possible.
KS: We try to ask about personal, real-life experiences. When we interviewed travelers, for example, we asked them what their last trip looked like, how they planned it, and to give us examples of how they felt at the time. In short, we ended up asking a lot of “Why” and “How” questions.
At the close of each interview, we usually ask users to fill out a rudimentary survey to collect basic information about their age, gender, education, etc.
KS: Easy as this may seem, the person conducting UX interviews should be prepared really well, both in terms of soft skills and UX knowledge. It’s best when a company conducting such research employs a qualified UX researcher or a research agency.
In software agencies, that role is often taken by product design teams. See, design is not only about the colors and visuals, but mostly about the application’s usability.
KS: The client usually knows a lot about their target group (eg. thanks to data from Google Analytics or pre-built user personas), and can provide comprehensive information about the users. Such knowledge is indispensable when working on target groups.
Obviously, it’s also the client who points out certain areas they would like to have researched, so they present the need.
The UX team collects these expectations and information, and then drafts the interview scenario, later consulting it with the client.
After the study is completed, the client is presented with the recorded interviews along with a comprehensive report containing the UX team’s conclusions and recommendations. In short, the client doesn’t take part in the interviews directly, but remains in close collaboration with the interviewers.
KS: The researchers collect all the interviews and then go through them once more. It's also good practice to have the recordings reviewed by another person and then discuss the conclusions together.
While reviewing the interviews, the researchers take notes, assigning key conclusions to certain areas they had planned to examine beforehand. Then, they interpret the results for specific areas and check whether some answers were consistent across the interviewees.
The most important part, though, might actually be the UX team members discussing their impressions and interpretations of the interviews together. Taken together, all of the above make up so-called qualitative methods of analysis in UX interviews.
Design Team discussing UX interviews' results
Detailed interpretations along with recommendations are then sent to the client.
KS: Sometimes, the conclusions suggest that the client should not go forward with the development of a given application, and sometimes they prove that the client’s original concept indeed held great promise and should be developed further.
KS: Imagine that one day you come up with a great idea for an app, then you invest money to build it, and then it turns out after launch that nobody wants to use it much. Maybe because they don’t have to. Maybe because they never had a need for such an app in the first place. Or maybe because the group of prospective users whose potential problem you wanted to solve had already devised a way of solving this problem and their solution suits them better.
Wouldn’t it have been wiser to ask first? Wouldn’t it have been better to get to know the context from the perspective of the potential user?
Well, this is exactly the role that user interviews play in the development process. If a conclusion drawn from these interviews indicates that your dream application or a new functionality is completely unnecessary and unwanted, because the users don't actually need or want it—it will save you money you would have otherwise spent on development and allow you to invest your time elsewhere.
But the interviews may also help us discover an actual niche or figure out that the problem lies somewhere else.
The greatest advantage of doing UX interviews, however, lies not in their ability to save you money and time, but in offering you access to user feedback you can actually use to improve your existing app and introduce such features sought by the audience that you might not have otherwise figured out on your own.
You cannot understand good design if you do not understand people; design is made for people
— Dieter Rams