Doing User Research as a Web Developer
At CrowdRiff, we are always looking for ways to improve our product, either by improving existing features, or by developing entirely new ones that will help our customers perform the tasks that are important to them. We are constantly innovating, and much of that innovation is driven by direct customer feedback and findings from our user research practices.
Working on the development team, this research informs everything that I build. Over the past year, I have become more interested in how this research is conducted, and have become more directly involved in the user research that drives our product development.
What is User Research?
Essentially, user research involves placing the user at the centre of your design process. It usually involves a combination of qualitative and quantitative research methods that help you and your team better understand your user’s goals and motivations. User research ideally takes place throughout the development cycle, and begins well before you have written a single line of code.
Generative Research:
Generative research is the research that happens early in the process. This is the “learning phase”, where you can explore new and big questions that might not have an existing framework. At this stage in the game, you don’t quite know exactly what problem you are trying to solve. This type of research allows you to find the opportunities for innovation.
This stage of research could include ethnography — observing and understanding how people live their lives/do their jobs, from their perspective. It could also include contextual interviews — observing while a user works. Through observation, you may uncover needs that your user has, but maybe cannot articulate.
Evaluative Research:
On the other hand, evaluative research happens throughout the development process. This is the phase of research where you measure and validate. At this stage you are typically testing a specific idea, design, or assumption. This type of research is generally more familiar to developers because it involves testing and evaluating your existing solution with users. Examples include testing prototypes, A/B testing, etc.
“Despite there being many different user research techniques, the common thread between them is spending time with your users.”
— Arin Bhowmick
VP Design, IBM
Why Do User Research?
User research is essential to gain a better understanding of what is really important to the people who use your product. It is also a great way to uncover and address any existing biases you might have. As a developer, we can have the tendency to build things in the way that makes the most sense for ourselves. User research forces us to step outside of our opinions and focus on what provides the most value for our user. User research can help guide your design process, ensuring that you are building products that are easy and enjoyable to use, and that all development decisions benefit your users.
Jobs To Be Done Theory
A framework that we use at CrowdRiff, to help us get to the bottom line of our user’s needs, is a widely-used theory called Jobs To Be Done. The JTBD theory stresses that users are driven by their motivation to reach a point of progress. At the heart of this theory is that customers “hire” products to achieve a particular outcome. If we focus on this theory, we can communicate value through what the product experience can enable customers to get done, rather than what the product is.
Over time, customers will face new challenges, and desire new goals and outcomes. Your product should grow and evolve with them. Design and develop your product to deliver an ongoing feeling of progress.
JTBD doesn’t outline what you should build or how you should build it. Instead it focuses on:
- What customers are struggling with
- What they do and don’t value in a solution
- How they imagine their life being better when they have the right solution
At CrowdRiff, we tend to frame JTBD in sentences using the following outline (designed by the team at Intercom) as a guide:
When [triggering event], I want to [goal or motivation], so I can [intended outcome].
Below is an example of a JTBD that we developed for a recent project, that focuses on the goals/motivations of a Content Creator or Blogger:
When writing an article or blog post (the triggering event), I want to source and download effective visual content (the goal or motivation) that will inspire potential customers (intended outcome).
In this example, the value/point of progress for the user comes when they are able to inspire potential customers through visual content. Our team has found this framework helps to clarify what we are ultimately trying to help our customers achieve through the use of our product.
We can’t build the products of tomorrow, when we limit ourselves to the needs and expectations of the products of today. Instead, we should focus on what never changes for customers: their desire for progress.
— Alan Klement
Author: When Coffee and Kale Compete
A Simple Research Framework
I recently attended a conference held by UX Research TO where Rob Hayes, founder of Foundation PM, outlined a simple research framework that any organization can follow if they want to do more with user research:
- Identify your assumptions. Of those assumptions, which are the most risky should we be wrong? Can we investigate these assumptions first?
- Build up a series of questions based on the unknowns you want to uncover. These questions can help shape the discussions you will have with users.
- Develop a discussion guide. This will be serve as a template for your discussion with your users. Ideally the conversation should be free-flowing, and you should give your user plenty of time to talk.
- Interview 4–6 people. This is kind of the sweet spot if you want to make speedy progress and iterate quickly. Anything less will not give you enough data points to move forward, but interviewing too many people might slow down your progress. Leave time at the end of your discussion for the user to ask any questions and address anything you might not have covered.
- Identify and prioritize 3 key takeaways or insights. What information can we use to move forward? Your insights should be clear and concise so they are actionable for your team.
I have found the process of interviewing customers is invaluable to my development process. The insights that I gather from speaking to our customers has helped me contribute more effective feedback during design reviews, and has allowed me to share key insights with the rest of the team.
Easy Tips For Developers
Although developers don’t always have the opportunity to speak directly with customers on a regular basis, there are many people on our teams who can be amazing resources. One of the best tips I‘ve been given is to grab a coffee with the people who are closest to your customers. Whenever possible, meet with the people who are speaking firsthand with your customers everyday. If possible, sit in on a Sales call, or a Customer Service training, so you can hear firsthand from potential or current customers. This can help you answer key questions such as:
- What are the reasons customers buy your product in the first place? This can help you continue to deliver value to your customers.
- How would they describe your product/product features? Speak to your customers in language that has meaning for them.
- Are there any key pain points customers have been experiencing lately? Prioritize these issues and address them as soon as possible.
- Are there any product requests customers have? Consider including them in your product roadmap!
It is important to always keep in mind that you are building a product to solve real problems for real people. Shiny new features are only valuable if your customers are able to achieve something that is important to them. Remain objectively curious and check your biases at the door. Happy researching!
