Lessons on creating better user research
As I’m nearing my six months at my first UX role, I wanted to reflect on a key skill that I am currently refining: user research.
We have already undertaken several user interviews and usability tests to define key problem areas within the selected products we are looking to review. However, it has taken time to understand how to create effective user research questions and understand what specifically we want to find out.
From doing user interviews for my voluntary case studies to researching users in my role on how they use systems and products, the one thing I have found difficult when doing this is asking the right questions to help define the hypothesis that is required for UX projects. This is down to myself finding it hard to ask questions spontaneously and understanding what the core problem was that doing user research was trying to solve.
On reflection of trying to solve this problem, it’s actually a skill that isn’t easy to get right straight away. It takes practice and by reviewing efforts constantly, you soon refine how you undertake user research.
With this in mind, here are five key learnings to take onboard when refining your user research techniques:
1. Research which type of users you are trying to help
This can seem like the simplest of tasks, but actually, it’s one of the hardest elements of user research: defining which users you’re going to interview. In organisations, there is barely just one user of the product. Assuming that one user needs to be interviewed and will solve the core problem is a big mistake. For example, at the beginning of my user research, I focused on internal users within a selected geographic area that had a wealth of experience within the system. This not only did this create some biases in addressing the research question we were looking to solve, but it assumed that every user acted in this way.
In order to address this problem for future studies, look into researching and breaking down key users within your organisation. Interview stakeholders within the organisation to see what data is held about users (such as demographics and customer comments). From there you will be able to map out the following user types, what their influence is on the organisation’s roadmap and define what key user needs can be researched in line with this need. Remember to break it down into the following:
Power Users: The could be internal users who use your product on a day to day basis or client users.
New Users: These can be users who are using competitors products, but can be used to help compare how your product performs against others.
Non-users: These can be internal stakeholders who don’t use the core product offerings but may be influenced through the implementation of system changes.
2. Ask for stakeholder input for refining questions
Another common mistake is not getting key stakeholders involved when looking at defining key questions and the type of research looking to be undertaken for the project in question. Sometimes it’s hard to involve others due to interference and fear of other input directing away from the original research brief.
However, stakeholders can provide you with directions and data that can provide the top three to five tasks assumptions that users are looking to use the system for completing their end goal.
As well, they can help with practice running a session as this will help to get better answers for the research.
3. Focus on active listening and understand the users “why”
Within moderated user interviews, it can be hard to just focus on asking the questions from the discussion guide. Using the 5 why’s (as defined from Sakichi Toyota) can help find a root cause to the issue, as well as personal motivations and pain points when using the project.
This is a learning lesson I learnt recently within one of my user research projects. Although we interviewed users on why they use the product and looking for recommendations, it only focused on what functions we could add to the product. On reflection, this actually didn’t address the user’s core needs, neither did it help to define the priority of the tasks required to add this feature affected other members of the team (such as Engineers, Customer Success and DevOps).
We actually went back and selected three users to do a deep dive analysis and used the 5 whys as a tool to define the key root problem, of which the key theme was surrounding communication and training within the tool. From this, we were able to create a problem statement that addressed the user needs more specifically and created a task analysis of the key functions required that could be tested and refined to meet those needs.
Although this experience meant that we might have had to put extra time into the user research process, going forward it has helped us to better define how we interview stakeholders and define key features we need to work on.
4. Bring out personal stories in relation to the product
Before starting out the user interviews, I normally have a personal conversation with the interviewee to not only put them at ease but to also help build a personal connection with them.
For example, I had an interview with a recent employee who had just started my company and she spoke about her onboarding story in relation to the product I was interviewing her for. Although this is not part of the interview process, I find this helps users feel more relaxed when answering the questions or task set, leading to users looking to diverge more into the issue through their own personal stories. This can help build empathy when looking at design ideas and bring to life the user journey that can define what key problem themes need addressing.
5. Focus on assumptions not outputs
My boss recommended a book to us called Continous Discovery Habits by Teresa Torres of which focuses on creating techniques to have regular conversations with customers, to define better product roadmaps. In one chapter, she highlights the importance of focusing on user assumptions (for example regarding our product area, assumptions might be “I would like more visual cues of understanding where I am in the system”, whereas an output would be “I would like a stepper tool to understand where I am in the system). As UXer’s, we should be looking to use assumptions to look at creative solutions that can address this user’s needs from various viewpoints, defining which solution with be the easiest to implement with the desired solution.
Remember as with everything with UX, it is an iterative process and although you may not get the right technique at first, through these lessons and continually refining how you undertake research.
Fancy a chat about all things UX and personal development? Feel free to book in a 30 minute chat with me with Calendly.
