UX stepping stones: Defining problems
User experience is difficult to define, as it incorporates more than just solving problems. We spend just as much time defining problems as we do solving them. There are many strategies available today to be able to run problem validation, some quicker and easier than others. Depending on the type of business problem/strategy at hand, and how defined the problem statement is, you’ll want to pick and choose certain types.
Types of problem validation
Problem validation is a fancy way of saying defining a problem. GitLab defines problem validation as a type of research “to provide decision makers with a well understood and clearly articulated customer problem” (GitLab handbook). If you do not have a strong sense of the problem statement you are solving for, it is best to start with “generative research” (GitLab handbook) first. This allows you to waste less time solving a problem that isn’t well defined and that you have low confidence in. Generative research answers questions such as:
Is there a problem? What is it?
Who are the users?
What are the users’ mental models as they relate to the problem(s)?
If you do have a problem statement to start with, you can jump into “descriptive and informative research” (GitLab handbook). This way, you’ll gain more insight into the context of the problem and get a better idea of what you’ll be trying to solve through design. Descriptive and informative research answers questions such as:
What are the pain points today?
How do users feel about it?
How is this done today?
Why is it done this way?
Choosing a problem validation method
Once you’ve figured out the type of problem validation that you fall into, either generative research or descriptive and informative research, you can nail down the method you’ll use to conduct the research. A best practice to follow is to start with a discussion guide that captures the problem statement (if you have one) and questions you have. A discussion guide can be written in a google doc, word doc, really anywhere that can be shared with the rest of your team as well as used to take notes during sessions. Some of the necessary parts of a discussion guide include:
Goals and objectives of the research project (not sure what the difference is between goals and objectives? Check this documentation out)
Warm-up questions to ask participants: These should be easy questions about the participant and their job. This will allow the participant to get used to answering questions.
Exploratory questions to ask participants: Make sure to group together questions into common topics. It is always better to have too many questions than not enough. Make sure to highlight the most important questions, the ones that need to be answered in order to move forward, so that you don’t forget to get answers for them.
Contextual inquiry
During these interviews, researchers watch and listen as users work in the user’s own environment, as opposed to being in a lab. Contextual interviews tend to be more natural and sometimes more realistic as a result. They are also usually less formal than lab tests and don’t use tasks or scripts (Usability.gov). Contextual inquiry is good to carry out if you want to understand what tools users use, how their space is set up, and how users perform in their natural environment. This method will help you expand a theory, challenge a dominant view, propose a new theory, redesign a product, and more.
In-depth interview with potential users
In-depth interviews are also considered individual interviews. In individual interviews, an interviewer talks with one user for 30 minutes to an hour. Individual interviews allow you to probe their attitudes, beliefs, desires, and experiences to get a deeper understanding of the users who come to your site. You can also ask them to rate or rank choices for site content. These interviews can take place face-to-face, by phone or video conference, or via instant messaging system (Usability.gov). In-depth interviews are good when your overall purpose of the research is to empower people, motivate change, increase visibility and scrutiny, and apply a critical lens.
In-depth interview with stakeholders
In-depth interviews with stakeholders are also considered individual interviews, and mirror similar objectives and goals to those with potential users. Stakeholders are occasionally easier to get access to, compared to users, and are often communicating with users weekly. They are also experts in their domains and have a lot of experience with the technology. They are a great resource to reach out to.
Diary study
A diary study is a research method used to collect qualitative data about user behaviors, activities, and experiences over time. In a diary study, data is self-reported by participants longitudinally — that is, over an extended period of time that can range from a few days to even a month or longer. During the defined reporting period, study participants are asked to keep a diary and log specific information about activities being studied. To help participants remember to fill in their diary, sometimes they are periodically prompted (for example, through a notification received daily or at select times during the day) (Nielsen Norman Group). Diary studies are a great method to use when you want to witness how users complete tasks over an extended period of time. It will also give you insight into the customer journey that are typically experienced within your product.
Participatory design
Participatory design is an approach to design that invites all stakeholders (e.g. customers, employees, partners, citizens, consumers) into the design process as a means of better understanding, meeting, and sometimes preempting their needs (UX Magazine). In this method, the end users co-design with the designers/researchers, which in turn, allows them to have more control and preference over the solution they end up with. This method gives you a lot of insight into how users would like to solve the problems themselves.
User journey mapping
A journey map is a visualization of the process that a person goes through in order to accomplish a goal. In its most basic form, journey mapping starts by compiling a series of user actions into a timeline. Next, the timeline is fleshed out with user thoughts and emotions in order to create a narrative. This narrative is condensed and polished, ultimately leading to a visualization (Nielsen Norman Group). Journey mapping is a great place to start when you want to evaluate the whole experience from the user’s point of view, and highlight any gaps where improvements can be made.
User story mapping
User Story mapping is a powerful way to visualize how people are using your product or feature holistically and organize individual stories to that journey. A story map can even be annotated to indicate which user stories need to be included in each release, making it a valuable tool for PMs and Designers to use during planning. Much like a User Journey Map, a Story Map outlines a workflow and breaks it into individual steps (GitLab handbook). This method is great to use when you want to further break down a complete experience, so it is easier to iterate through. The benefits of user story mapping are very similar to those of journey mapping.
Kano model and feature prioritization survey
Using the Kano model can help you to make more informed decisions when prioritizing features from your backlog and to better understand why these features do or don't resonate with your users (GitLab handbook). In a similar manner, you can use a feature prioritization survey to help better prioritize features for an upcoming release based on direct user feedback. This is a good method to use when you have a number of features you’d like to implement, but want to do so as efficiently and impactful as possible.
Summary
In the end, there are various problem validation methods to choose from. The best place to start is with a problem statement, or realizing that you don’t have a problem statement. Other variables that will help you select a method are the time you have available, resources, and connections. Remember to always make sure the problem is well defined before you start ideating solutions. It will not only help you get a more concrete solution, but it will also help your team stay on track and leave less area for scope-creep. If you have more questions about how to carry out the various methods, there are plenty of materials with more information, especially the ones that I linked above throughout the blog!