Eventually, after innumerable sessions of coffee and whiteboarding, they figure out that they should build a product to track morning workout activities. Being seasoned entrepreneurs, they hire a UX specialist to do the necessary research.
The UX specialist does enough research and study, talks to users, and tests prototypes. However, despite all this, their product is rejected by the market.
So what went wrong?
What was the problem with the user research? Was the data not sufficient? Did something go wrong with prototype validation? At least that should have generated better insights.
Let’s deep dive into a few user research methods that can get you better insights for your UX design decisions and help you avoid an expensive and demoralizing failure.
1. Frame the right problem.
This is the most important part of the UX building process. Are we solving the right problem? We often have a subjective, biased view of our problem as our personal views and experiences can colour our thoughts. Or we don’t spend enough time brainstorming about the problem and quickly jump to solutions.
The very famous “slow elevator problem” comes to mind here. What we learn from this example is quite simple.
If you don’t frame the problem statement correctly the entire product can fail. The point of reframing the problem is not to find the “real” problem but, rather, to see if there is a better one to solve.In fact, the very idea that a single root problem exists may be misleading; problems are typically multicausal and can be addressed in many ways
2. Connect the problem with a story.
Let’s take a bird’s-eye view of our problem statement. Can we bring more clarity to the problem statement? Can we split our problem statement in such a way that the triggering event or situation, the motivation, the goal, and the intended outcome are articulated clearly? This is where the concept of “Job Stories” comes in.
The core idea of job stories came from the Intercom design team and is pretty straightforward: place your design problem in a job, from targeting event to motivation and goal and the intended outcome.
We at the Bizom design team adopted job stories as part of our design process for two reasons.
- To get more clarity about the problem
- To get more clarity about the expected outcome
Let’s have a look at how you can play with job stories.
Place your design problem in a job, listing the targeting event, motivation, and the intended outcome. The frame will look like this:
When _____ I want to _____, so I can _____.
If we were to convert Mr X’s problem into a job story, it would look like this:
When I’m doing my morning workout, I want to track my activities and performance, so I can be motivated.
3. Look for the story while interviewing users.
Listening to your users is the most important part of the design process. While talking to them, be a good listener and ask them about the context of their problem. Delve deeper for details, observe behaviour and perceptions, and ask follow-up questions wherever possible. Objective yes or no questions regarding problems or features are of little use here.
At Bizom we build things for the CPG / FMCG companies and it’s very important for us to observe and understand user behaviour and connect with their stories. To ensure this happens, folks in the design team go to the market and spend time with customers. Each visit brings more context to the story and more clarity on what we are doing.
4. Use the Experience Sampling Method (ESM).
Research participants are interviewed several times a day to note their experiences in real-time. Through experience sampling, you will get valid qualitative data which are personal and subjective.
Read more about experience sampling in this book.
5. Record prototype validation sessions.
Indeed we have enough tools to share our prototype with users and understand the usability of the product. Most tools like InVision, Marvel, and CanvasFlip have inbuilt recording tools where you can actually get user interaction data. These tools help designers to get qualitative data from the recruited participant even from a remote location.
We must start our design process with clear KPIs and an understanding of what we want to achieve. Before jumping to solutions – these can be a feature, functionalities, or anything else – let’s step back and cross-check: are we thinking about the right problem in the first place?
Let me know if these tactics helped you with your next project. Also, let me know if you have more studies or thoughts regarding this. Cheers!