The #1 question to ask on a UX project
Cut through the noise and get to the real design problem
Have you ever been briefed on a project, only for it to change half way through?
Have you delivered what a client or team said they wanted only to be met with a new or different question or problem?
Have you ever been weeks deep in research only to discover that the team is solving the wrong problem for the wrong users?
It’s probably because you didn’t get a really good answer to the most important question on a UX project.
Why this is happening
It’s easy to get excited when you get briefed on a shiny new project. You want to leap in and start designing solutions, right?
Wrong.
In fact one of the most important thing I get to teach young UXers is the ability to pause the certainty and the assumptions (#NeverAssume) and ask more questions.
And thanks to a clever UX chap I met a few years ago, I discovered the killer question that will stop everyone — you, the design team, the client, the stakeholders everyone — in their tracks.
OK, so what is it?
What you need to find out is not what people are asking for, but what the project needs. Because it could be a lot more complex, or a lot more simple, or completely different than you think. And no one wants to waste their time on the wrong brief.
How do you find that out at the beginning of project? Ask this simple question:
What is the problem we are trying to solve?
Why does this work?
Asking this outright and repeatedly, and playing back what you are hearing, focuses your client and team on agreeing what the brief really is.
- It makes people stop waffling and instead form a specific statement of intent
- It consolidates what can be a long list of requests and ideas from multiple stakeholders into a simple problem-to-be-solved that the whole team can agree on
- It reveals mismattch between stakeholders who have all assumed that they are aligned when they’re not (again, #NeverAssume)
- It gives you verbatim to play back throughout the project, demonstrating how everything you and your team is doing is working towards solving The Problem
- It gives you a north star that you can use — and change — if your project or The Problem changes for any reason
- It protects you from the worst parts of scope creep, or at least ensures you’re not responsible for it.
The problem statement
The most important thing to do having answered this question to everyone’s satisfaction, and before the project gets underway is to:
- Write it down
- Share it
- Reference it (repeatedly)
A way to phrase this is — We are <designing or documenting> a <something> for <these users or stakeholders> who have <this need or problem>.
We are <designing> a <something> for <these users> who have <this problem>
This change from brief to “The Problem We Are Trying To Solve” could look like any of the following statements:
Example 1
- Brief: We need a new sign up flow
- Problem statement: We are designing a sign up flow for new users who would otherwise use Competitor Product X to create their shared accounts.
You now know the purpose of the flow, the user mental models, competitor examples, and have the beginnings of the type of functionality needed. You also know you’ll need to align with marketing on product benefits statements and the wider campaign journey.
Example 2
- Brief: We need to present the user research to the board next week
- Problem statement: We are writing a very high level summary presentation of user research findings to date for senior executives to build empathy and unlock budget.
You now know it’s a super-high level summary that will take you a lot less time than documenting years’ worth of research. And your audience will have a limited attention span. OR you might want to allow yourself more time to make a more emotive and engaging video highlights reel.
Example 3
- Brief: We want a journey map
- Problem statement: We need to map the current state end-to-end journey and pain points so that stakeholders can understand the extent of the product problems and prioritise fixes.
You now know the strategic importance of this, the scope, that you’ll need time to understand the pain points and that you’ll need to be able to evidence them to stakeholders so that they can size the issues for prioritisation. You’ll also have some information design challenges in ensuring it’s visually simple but rich in detail. Enjoy!
Strategic UX Designer
Using this approach will not only save time and money/resource, it will prevent later confusion and conflict and add value to any project by helping the team and stakeholders successfully communicate their needs.
It also demonstrates your individual ability to identify priorities, focus a team and deliver results.
Who wouldn’t want to work with a UXer like that.
With thanks to Paul Dellow for teaching me fings. 👍
Hello 👋
Did you know, you can 👉 subscribe for free to get notified of any new articles I write. Woot.
I’ve even made a ton of helpful lists, depending on what you’re most interested in.
