UX/Product
Is that really a user problem?
User-centred design solves organisational problems by solving user problems. Is your team really doing that?
If you’re trying to adopt user-centred design in your project, the source of future failure can often boil down to the team not having solved any real user problems. Yes everyone is talking good words about being user-first, but are you being user-centred? There are three mistakes I see being made in this area…
- Not focusing on user problems at all
- Mistaking organisational problems for user problems
- Inventing problems users don’t have
1. No focus on user problems at all
Despite having the intent to be better for users, many projects will go through the motions of a user-centred process without sufficient focus on defining the real user problem(s) they are trying to solve.
Example — the aimless redesign
Here is a fictional conversation which is very reminiscent of a number of projects I have discussed.
Me: “So you’re redesigning your sign-up flow?”
Potential client: “Yeah, the current one is really bad.”
Me: “What’s bad about it?”
Potential client: “Everything, it’s just really clunky.”
Me: “Do you know specifically what things need fixed about it and what effect they are having?”
Potential client: “Not specifically, we just know it could be a lot better.”
I call this the type of project the ‘aimless redesign’. Something is being reworked without any objective evidence about what is currently bad about it and what the benefit of the redesign will specifically be. The team are just going to change a bunch of things as part of a total overhaul, then hope for an improvement. Sometimes they get that improvement. Sometimes they make things worse, or do a mix of both.
To flip a project like this around to become a user-centred design project, I would suggest finding evidence of the problems users are experiencing and what the effects of this are. Then try to fix those problems in the simplest way possible. A full redesign usually isn’t required.
Instead of calling it a redesign, it should be a period of focus on the problems in that area. This brings us to a potential ‘red flag’ about project names.
Red flag — The solution is in the project name
The previous example belongs to a type of project where the solution is baked into the project name. In my experience this can be a strong predictor of disappointing results or the fizzling out of the project. It is very difficult to get any other result than achieving the thing that is in the title, no matter how hard the team pretends they are open to other solutions. Achieving the thing in the title becomes the primary success criterion.
Examples of such projects I have been involved in have been…
- The <commodity type> basket project
- The <app/website/journey> redesign project
- The conversational search project
- The one-click purchase project
The project often has an intended outcome and the project sponsors have either deliberately or inadvertently defined a solution for it already. A one-click purchase project, for example, can come from the desire to remove avoidable friction from purchasing. The implied outcome is to increase purchase conversions. But the project has begun life with a defined solution baked into it.
Sometimes your project is to achieve an industry, regulatory or technical requirement, in which case naming the project after that requirement is exactly what you would do. For example “AWS migration” or “2FA”. These projects can use user-centred techniques at points, but are not user-centred design projects. Nor should they try to be.
Opportunity-centred projects
I don’t necessarily suggest naming projects after the user problems you are aiming at. One successful project often solves a number of user problems anyway. The description of real user problems can also get quite long when you try to write them down (we’ll get to that).
The whole project needn’t be user-centred in fact. Instead I would suggest employing user-centred design to solve one or more real user problems in that space, with a view to exploiting the opportunity concerned.
I prefer projects names where the opportunity is in the title. For example the name given to the fictitious redesign from the conversation above could be “Improving sign-up flow”.
2. Mistaking organisational problems for user problems
Many projects teams believe they are solving a user problem because success would mean positive outcomes for users. For example, if your target users knew how financial advice really worked, then they would want to use your service which does financial advice a better/cheaper/faster.
Your users not understanding something or having a misbelief about something is not a user problem. Unless that is, they are trying to understand it and can’t.
You can use user-centred design techniques on the design and build stages of these projects, but there is a risk of them falling flat with users, because you aren’t necessarily providing anything that they actually value.
3. Inventing problems that users don’t feel they have
Sub-optimal is not (necessarily) a problem
One example of this third mistake is one I made myself a lot in my early career. When I saw something about a participant’s life or workflow which was sub-optimal, I decided it was a user problem. Research participants themselves were unconcerned and had no need for anyone to rescue them from their sub-optimal lives.
These days, before I consider something a user problem, I look for awareness of a problem or struggle from users.
Misunderstanding is not (necessarily) a problem
On one product I worked on, a rating score was often being mistaken as something it wasn’t. Successive product managers tried to fix this problem as a priority. None did. The rating was steering users in a positive direction, toward better outcomes. Users were making better choices albeit on a slightly mistaken belief. Misunderstanding the specific meaning behind the rating was not a user problem.
Our job is not to make people understand, our job is to make things work better.
Your problems, reworded as theirs
More normally, this third mistake manifests itself as projects where organisational problems are flipped around to sound like user problems. For example, when was the last time you worried about the lack of personalisation in your ads?
Tech companies love to word their organisation-focussed initiatives as something that sounds like a user problem. You can find yourself working on a project with an outright laughable name as a result. The project behind this (above) may well have been called the “personalised ads project” rather than the more accurate “sell the more expensive ads” or “get more user data” project.
OK, so what is a user problem then?
The user is aware and cares
It’s a user problem when the user struggles. They might not know the root cause of the problem. But they are aware of the struggle, the concern they feel or thing they are trying to achieve. Here are two examples.
User problem 1 — you could base an entire company around a problem like this
Some credit card customers experience a large increase on the advertised rates after they have made on application. They believe there are better options out there. However they can’t understand what the real rates of alternatives will be unless they apply for all of those as well. They are wary of how making numerous applications affects their credit rating. As a result they can’t truly compare all the real rates they will be offered. They often choose products they aren’t very happy with.
User problem 2 — this is just one of a series of interface-level improvements you can make to an experience as part of a wider project
On the setup screen, users are asked for their address. But many believe they are only being asked for their postcode. Those people experience confusion and delays when they try to submit the form, because they believe they have answered all of the questions it asks of them.
Notice how neither of these are short descriptions. User problems are often hard to explain easily. I realise I’m giving the impression you need to write down and agree every problem you are solving. It is sometimes helpful, but I only recommend it when there is some doubt or lack of shared understanding of what the team is trying to do. If you don’t understand why the team is doing something, then you are probably not alone. When this happens, get the user problem(s) written down and agreed.
Specific and descriptive
If you are going to write down and agree the user problem(s) you are focussing on then I suggest getting quite specific and descriptive.
If you Google the term “Fly UX” you can see the portfolios of a large number of newcomers to the world of UX. They have all done the same accreditation and all gone through a number of user-centred design techniques to develop a new flight booking app for a fictional airline.
Reading through them, I am struck by how little evidence there is of having received good feedback on defining the problem they are solving. “Most flight booking apps have bad UX” is not a well-defined user problem to work on (I will try not to take offence) because it is neither specific nor descriptive. It is a very broad problem space rather than a user problem you can focus on fixing.
[My comments here are not aimed at the students, but the lack of decent feedback they got for their thousands of pounds spent. Assuming they had course mentors, those mentors didn’t help them with this. Their future employers aren’t currently good at it. So how are they going to learn it?]
Unless you align on the specific user problems you are trying to solve, you are going to lack the focus required to make anything actually better. You end up changing things for the sake of it or because you don’t personally like them.
They don’t always come quickly and easily
The difficult truth is that nailing down the user problem(s) you are going to solve isn’t always quick. It is literally the first half of the double diamond. In practice however, the project often starts and 3 weeks later the team are building something without a clear focus on what they are trying to achieve.
They spoke to some users, they looked at competitive offerings, they did some empathy and experience mapping. Now it’s time to start designing the thing that solves an undefined user problem.
In the rush to build something, the real user problems evident in the research are sometimes overlooked. “We did the discovery step (box ticked) now let’s build something”.
You can’t force a discovery. All you can do is explore until you make one.
Spotting real user problems
It’s easier to spot real user problems when the problem hasn’t been defined before you go looking for it. If you already have a problem in mind and are seeking to validate it, most of the people you speak to won’t have that problem. In fact you might find that nobody you speak to does. This doesn’t mean the problem doesn’t exist.
Proving or disproving a pre-defined problem with UX research is very difficult and the wrong way to look at things (in my mind). This is why I believe so much user research is being carried out back-to-front. Instead start with users, discover their problems and then try to fix those problems.
Begin with a problem space
I suggest looking in ‘problem spaces’ for undefined problems or researching problems you know exist with people who have that problem.
A problem space is a quite tightly defined area of users’ lives in which you believe you might be able to solve problems. For example here are some problem spaces I have researched in the past
- Choosing a destination for a weekend break based on the price and availability of flights
- Engaging a financial adviser to help with your retirement
- Researching potential software to use at work
- Searching online for used cars to go and view in person
- Generating traffic for your blog
Ideally you would observe people while they actually did the thing you are researching. But this isn’t always possible. Instead you can speak to them about how they did it recently. When you see a problem or problems around a similar theme recur in your research, then that is a good indication of a problem worth working on.
Seek further evidence of the problem’s existence from additional sources of data. Preferably this should be behavioural data. This means digging into analytics and running behavioural experiments, over just defaulting to surveys.
Are we allowed to solve this problem?
When identifying user problems you could feasibly try to solve, it’s important to consider your users’ workflow and their motivation to solve the problem. Here is a real example of a user problem from our first problem space.
When searching for flights for a weekend break, some users find it difficult to select a destination to research further, based on the price of the cheapest flights (eg. Paris from £39). The cheapest flight prices are usually at unfeasible times for a weekend break. Choosing a destination based on the prices of feasible flights across a number of destinations takes a lot of research and effort. Users tend to research fewer destinations than they are prepared to consider due to the effort this takes.
This is a real problem from real research, but not one that just any business should necessarily try to solve. During the research, participants all stuck to their habitual approach for searching flights. There was no evidence of anyone trying to solve the problem in a different way. The solution therefore, should fit into their current workflow. This means only the sites/apps they use for searching flights can really solve this problem for them, or the solution needs to appear in front of them before they get there (on Google results for example).
Here is another problem, this time from how bloggers generate traffic.
Some very engaged bloggers, try lots of new ways to generate more traffic for their blogs. Approaches that work become very competitive, very quickly. So their existing approaches quickly become obsolete. These bloggers try to stay ahead of the game by spotting traffic generating opportunities early. They attend events with leaders from their field and consume lots of online content, constantly striving to find the next new way of generating traffic.
This example is an ongoing struggle and is different from the first one in that there is evidence of users trying to find better approaches. There is wider scope for innovation here. High motivation in these specific users, means you can develop an entirely new solution to their problem. They are already looking for better solutions, so you could convince them to try a new one.
Be pragmatic
If your project isn’t user-centred, is purely for organisational benefit and isn’t motivated to solve any user problems, then don’t pretend it is. Doing so is just a waste of time. Much of the process you would apply to a user-centred project can be dropped. It won’t make anything better and everything just takes longer as a result.
Formative techniques like usability testing should be your focus. Generative techniques will be largely pointless. The thing you are being asked to make is being made and that isn’t up for debate. The user-centred techniques you adopt should minimise how much the thing you are being told to build, sucks for users.
Some further reading
I regularly recommend Laura Klein’s post on intent to solve when discussing the subject of user problems and gaps in user needs. It focuses on identifying problems for the creation of new products.
I also wrote about innovation and user flow which touches on very similar themes.
About the author
I’m David Hamill. I help organisations take better decisions through lean but meaningful UX research. If you liked this post, you can read some more below. You can also take a look at my YouTube channel.
Design
- Using evidence and instinct in design
- Design guidelines for mobile date-pickers
- Getting real about delightful design
