What is a user interview?
Every day, you probably would have said something along the lines of:
“Hey, how’re you doing at work?”
“What would you guys want for lunch?”
“How is the COVID-19 situation is still so bad everywhere?”
“Mom! Why are you acting like this?”
But are any of these questions considered suitable for a user interview? Well, it depends! According to the Nielson Norman Group, the World Leaders in Research-based Experience, they say that
A user interview is a UX research method during which a researcher asks one user questions about a topic of interest (e.g., use of a system, behaviors and habits) with the goal of learning about that topic.
Putting aside the part about the researcher, all of us at some point would have done this – asking people to understand better about a subject matter.
- This subject matter could be for your personal curiosity e.g. Bruh, what’s the kind of girl that you would like?
- The subject matter could also be for understanding user personas and user needs for a project e.g. If I want to make a revolutionary walking stick, who would be keen on using it and how do they use their existing walking stick?
If it’s the latter then you can say that you are conducting a user interview, since that would be considered a research topic. By looking into a research topic, you are a researcher in a role, even if it’s not in your job title .
User Survey vs User Interview
If you’re asking many people at once for a research topic using broad questions, then you are doing a user survey. A user interview is more of an in-depth 1-1 non-interrogative conversation between the interviewer and the interviewee. The part of non-interrogative here is very important, because you want to actually understand facts about your target audience as they are, and not influence them to give you answers that you want to hear.
So user interviews are very unlike job interviews – Cough cough
As a developer, why should you bother with user interviews?
As a developer, it is important for you to understand truly:
Note that many of the examples here will be more relevant for developers working on their indie side projects or developers that are working in startups.
1. What is the problem that you are trying to solve?
- Are you able to translate a problem/business context into technical requirements?
- For example, if you are given a vague task “to track who has visited your site”, do you know what are the technical tasks you have to do to deliver this goal? What exactly is the problem here? And Why do we need to track the visitors?
2. Who are you doing it for?
- People are way more fascinating than just belonging to age groups. They have different preferences and different lifestyles.
- For example, different users have different ways of interacting with technology.
- Some users prefer to spend their time entirely on the computer when it comes to extensive usage of an application e.g. typing out an essay, some would prefer to still be able to access the application to look at certain content on the phone while they are on transport. Some just rely on their phone for everything regardless of space and time.
- For this example, if we just look at user behavior based on the device that they used and how frequently they use certain devices to access the application, the first technical requirement that you might think of might be responsive design. In an ideal world, you would be trying to implement responsive design for everything. But if you have evidence from your user research results to back that you do not need to optimize your responsive design as much, that would mean that more of your man hours can go into other features that your target audience actually cares about more.
3. Why would they want your solution?
- The part on YOUR solution matters a lot because there will definitely be competitive alternatives on the market
- A way of putting yourself into your users’ shoes would be to imagine that as a developer, why should you create a design system from scratch when you can just use existing design library packages like MUI out there?
- Obviously, you can say that your product would solve something that those alternatives don’t address – just like why you would create your own solution with your code from scratch – but would the shiny features that you have to alleviate the real pain points of your users?
An often missed out point would be that as developers, we also tend to have some form of assumptions about all these 3 questions – what the problem is, who our customers are, and why our solution is good. So we would try to answer them ourselves – which is an OK strategy for a start to make a Proof of Concept (PoC) or a Minimum Viable Product (MVP). But as you progress further in your project, and you still don’t talk to anyone from your target audience, you would start to realize a big difference between the market’s expectations and your product.
But what are these assumptions, and why would we be swayed this hard?
Assumptions that developers make from personal bias
This is something that everyone has, regardless or not whether you are a developer. We put people into boxes where we assume certain people just do certain things for certain reasons, even when sometimes we have never talked to those people individually before. It is an inevitable judgmental instinct that humans have. Personal bias cannot and should not be removed – everyone has their own right to think of things the way they want – but it is crucial to be actually aware that you have such predispositions.
An example is when we hear about people complaining about the same problem repeatedly, as developers, we tend to assume that they are either helpless or that they are trying to avoid the problem. After all, problems in real life are like bugs in our code – why would you allow them to persist and fester?
Being the overly helpful problem-solvers that we are, we would then pre-emptively give a solution to the problem that we perceived from their complaints. In trying to solve the problem our way, we might end up missing the point of why they are still facing the problem. The cause and the problem that we perceive from their words could be vastly different from the full picture of their situation.
Does that sound familiar? I too am personally guilty of this sometimes with my friends.
That’s why it’s pretty important to have a deeper 1-1 conversation with our target audience rather than deriving problems from the face value of casual complaints.
Fixation on technical details
Another issue would be that sometimes as developers, we are too fixated on technical implementation details. This tends to be a result of your mindset and your personal goal for working on a project is just for that project to be a stepping stone for you to learn technical skills rather than actually trying to solve someone’s problem.
Sometimes because of this fixation on technical details, we would also unintentionally filter out features that our target audience might actually be concerned about, in favor of stuff we think would be cool to implement and will be helpful for them before we even have any conversation with them
In the End
A developer’s assumptions, along with their fixation on technical details often serve as a double-edged sword when it comes to solving problems. On one hand, we improve in our analytic thinking and problem-solving skills when it comes to technical problems, and on the other hand, sometimes we lose connection to the end-users and why we are even trying to solve the problem. It is thus important for developers to take an effort in trying to conduct user interviews to come up with a better grasp of the problem context and take iterative steps rather than incremental steps to reach the goal of their project.
All of these hold true if we even have an opportunity to conduct a user interview with our target audience. The truth is, we do and will have the opportunity to conduct such user interviews. The world is big, but also small enough for you to reach out to your target audience and opportunity sources.
In the case where you are working in a company that already has excellent UXUI designers that are more professional to conduct the user research, and you would usually just translate their mockups to code, it won’t hurt to ask to look over the user interview results that they have gotten together with them. You could possibly bounce off great ideas from both the technical and creative sides in coming up with a better user experience and interface before embarking on its implementation. You would also have a better understanding of the trajectory that your designer has in mind for the product, and plan a more scalable technical architecture for it.
On a side note, while user interviews tend to be 1 person questioning and 1 person answering, sometimes the interviewee sometimes would ask questions back to clarify what or why you’re asking. Be respectful, be objective, and don’t lead the interviewees to give certain answers (or questions like below ).
For an example of a user interview that I did to come up with iterative steps for my side project, you can refer to my previous article where I showed a voice recording and the next steps that I have come up with for my side project.
