Starting with “now”: a user problem-solving approach
Better defining, storing and discovering user problems
As a UX designer focussed on quantitative methods and measurements, I’ve been focussing a lot on UX outcomes and how to incorporate them in our design process, shaping the work towards a more user-centric approach. From my experience, I found that this activity requires a clear definitions of the users problems to work at best. This post focuses on creating an approach around user problems: defining, storing and socialising them within the team and then designing activities to discover new ones.
Better user problems for better UX outcomes
A UX outcome is basically a projected (measurable) experience that represents the positive change we generated with our designs/interventions. It’s the representation we improve something that before was causing some issue to the user.
This approach suggests to start at the end and work backwards, building a UX outcome before building the product, shifting the focus from delivering a feature to deliver a user value. This outcome will guide the team and the design towards the most valuable solution for the user, and it will help define how to measure the success of the change generated once the solution is launched in the most effective way.
That all makes sense, except for one thing.
To generate great UX outcomes, we must have great user problems to start with.
It all starts with those pain points, barriers, impediments, stumbles and how much knowledge we need to have about them before working on solutions.
It’s as simple as that.
If we’re not sure about what’s happening at the moment and what actually is wrong with our UX, how can we envision a better version of it?
I then realised I had to concentrate more on defining better the “now” before shaping the “end”, in line also with the priorities of the design thinking approach.
What is a user problem?
Although very simplistic, I am choosing to consider a user problem just as something that gets between the user’s goal/task and its completion.
This approach might sounds too basic, but for the scope of this discussion (i.e. an approach to better guide the definition of a UX outcome), I have chosen to keep things simple and consider all user problems as a single concept, before differentiating them later.
Investing more time and focus on this piece of knowledge, including how to represent, socialise and discover it, might give value on many levels, and can help both product and design.
This post proposes a user-problem-solving approach, that starts with defining a reusable structure for user problems, a way to store, socialise and use this information within the teams, and activities to discover and measure these types of critical situation.
Step 1 . Defining a user problem structure
With all this in mind, my goal was to represent these insights in a way that was actionable and applicable in many contexts.
What is the minimum piece of information about user pain points that would be complete enough to build good UX outcomes from?
What is the best framework to use to capture this information in a way that is most usable (and re-usable) across teams and situations?
I think any team can define their structure of user problems, as long as it works for them as a tool to generate UX outcomes.
The structure that I found very useful started with the POV statement (user, need, goal), but incorporates other information to make this insights to work as standalone points (so you store this information in a repository and use it in a workshop, for example, and you don’t need other documentation to describe further the situation).
This is a possible core structure for user problems definition:
[user type] need [need] so they can [goal], but [situation] because [root cause] and this results in [attitudinal/behavioural outcome].
[Situation] What does the user actually experience? What happens?
[Root cause] What is the reason for this situation to occur?[Attitudinal/behavioural outcome] What are the consequences of this problem?
Does this result in a behaviour that we can observe? Or is it resulting in a change in the user’s perception and feeling?
This is a structure that allows me to think immediately about the UX outcomes, because quite quickly you see the consequence of the problem that we want to change.
In order to prioritise this knowledge, I then added other parameters — from the usability problems rating — that would have helped team members to look at them in a defined order.
Frequency / Recency. How many users are impacted by this? How often are they impacted?
Severity. How bad is the consequence? Does the user recover from it?
Confidence. How much we know about this situation? How much do we know this problem exists?
Some of these parameters can also give us an indication about how urgent is this problem to solve, not just from a UX perspective, but from a commercial one too.
How much is this problem costing us? How much money can we gain/save if we solve it?
Finally I added other information to better categorise identified problems in terms of actions/next steps to take.
Type. Is this a usability problem, or a bug in a specific page? Or is it an unmet need that is shared in the user group and for which there is no solution yet?This would tell us if the solution needs to be thought about within the context of the existing product, or if it’s an opportunity for a brand new feature/product, or even if it won’t never being solved.
Domain. Could the problem be related to the wording of the message, the visibility of the actions, or any other UX principle? Or is it not dependent on UX at all? This categorises the root cause and hints at the solution space.
To represent these findings, I found it useful to adopt a learning card format, which allows us to add the quote/text from the original study and see quickly the number of user studies that back up that piece of knowledge.
Here’s an example for a user problems for researchers who hit a paywall in a scientific publisher website, using the core structure.
Step 2 . Identify the knowledge gaps
Once the structure is defined and we can start pulling information from our past studies and defining it in this format, it might become clear where more research is needed to complete our user problems definition.
This is when we look at the insight we have collected and see if we have other questions to answer in order to refine and complete this insight.
Maybe we’re not sure about the outcomes/consequences of the problems we have, or we need to refresh some of our knowledge because we discover some user problems randomly and we’re not confident about the people impacted. Perhaps we realised that we have lots of usability problems and very little knowledge about the unmet needs of our users in general.
Step 3 . Store and socialise user problems
When our set of user problems are defined, we don’t have knowledge gaps to fill and we feel that we have a clear representation of the “now”, it’s a good idea to make this knowledge searchable and therefore sharable with teams and stakeholders.
This information can be quite powerful: communicating issues, especially with our products, usually grabs people attention. Using the natural language helps to express better the situations and allows everybody to empathise with the users.
We want to be sure that everyone gets the message: this information is an opportunity we can’t miss and it represents issues that are our responsibility to solve.
We also need to make it retrievable and easily accessible for the other team members.
What I’d suggest is to create a repository of user problems, for teams to independently use it and interrogate. The tool used is not important, you can incorporate this information into your existing research repository or create an independent library just for this scope. When it comes to repositories, I found pretty simple just using Google sheets connected to Google Data studio, for example.
The important thing is that the teams know that this knowledge around user problems exists, it’s described in detail and it can be retrieved and used.
Obviously the knowledge needs to be bulletproof so that it cannot be misinterpreted and misused: teams need to know how to use this information.
Storing this knowledge will also give another advantage: you can cross check the problems criteria and discover patterns. Maybe a user type has a specific issue related to language, or you might discover that two problems in different parts of the journey might have the same root cause.
Eventually, you can also keep track of the solutions implemented for these pain points and their success, so you can identify the ones that are more impactful as they have solved more than one user problem.
Step 4 . Make use of user problems
This information, once defined, stored and shared, can be used for workshops, brainstorming, sketching sessions, stakeholders conversations, and obviously to create UX outcomes and team objectives.
If the structure is complete and appropriate for your scope, the information can be use independently in several contexts, without the need to use other reports or documents.
If detailed enough, it should answer all the important questions by itself.
If clear enough, people will use it willingly.
The goal is to make the teams “marry” the user problems, giving them a good knowledge of these critical situations, make them own those problem spaces, so they can better envision the UX outcomes and they can consider solutions from a user prospective.
More knowledge = more alignment.
When the user problems are shared and discussed at the same time as the objectives, the work will be more focussed and effective at changing that critical situation.
Step 5 . Plan to discover
First of all, the analysis performed at the beginning would have identified additional studies to conduct to fill the knowledge gaps in your core problem definition.
Additionally, after you defined a user problem structure that works for you and your scope, you might want to reuse it as format/framework for the insights that you collect from future researches.
Even if you’re not planning to do research to specifically discover new user problems, you might encounter them anyway while you look for answers to other research questions. In this way your collection of users problems will naturally expand.
That is going to give you a base of all problems discovered so far, but this is just a part of the overall picture.
If this structure works for you and you want to create a programme around the user problems knowledge, you might also want to initiate specific pieces of research to discover new user problems that you don’t currently know of.
This is where you might plan specific studies depending on which type of problems you are looking for (usability problems, unmet needs, technical issues, etc.), and for which space (a specific page, journey, website, etc.) you are defining the method for.
Step 6 . Measure them
Once all identified problems are mapped, you can kick off a programme to measure (some of) them with analytics metrics and even recognise signals of new ones.
With analytics metrics we can measure some information around user problems:
- User errors; they represent the recognisable deviations from the “happy path” of experience. For example, the user misspells a word, or clicks on a link by accident. Looking at the problem structure, these can be both observations of the current situation (what actually happens) or a signal of the behavioural outcome/consequence.
- Other current situations and behavioural outcomes; these might be difficult to pinpoint to a specific user problem as some of these events/actions can be shared across other critical situations, or even be part of a positive experience.
For example, some airline customers are experiencing a problem with the check-in system and cannot reserve their free seat; a few of them pay to not get a bad seat, even if they’re entitled to a free one. We know that this is the consequence of the problem, but we can’t associate it with this measure, as some other customers naturally upgrade during the process and we’re not able to distinguish the two groups.
An interesting use will be to measure any extreme outcomes/consequences, also called user frustrations, that are easily recognisable among other analytics events.
You may see cases of rage clicking, thrashed cursor or excessive scrolling, or other activities that can be flagged as emotional response from users to a frustrating situation.
As said above, these cannot be easily related to a specific user problems, but they can be representative of critical situations that we know and can monitor, or can even signal some new user problems to investigate further.
It would be useful to incorporate frustrations in a framework like HEART , when applied to a specific journey/key actions, to highlight signals of undiscovered user problems.
Conclusions
User problems are the prerequisites to envisioning a better UX.
If we don’t define them in a way that works for us, our UX vision can be vague and therefore too subject to changes. That means the solution won’t probably solve the real issue.
If we adopt a programme to better shape and use this knowledge, we can use it as an opportunity to work with teams and empower them to be more focussed in their user-centric solutions.
