Fall in love with the problem
Are you solving the right problems?
We’ve all been there: you’re working on a solution for a couple days only to realise you’re having doubts. Is this the right problem to be working on?
Turns out, everyone else in the room with you feels the same. But nobody has been brave enough to say anything about it.
As a designer, it’s your job to solve problems in an elegant way: to find a useful and delightful solution for your target users’ problem.
This requires that you spend a lot of time crafting the solution. So much so, in fact, that you risk falling in love with the solution, rather than the problem.
When you’re in the middle of a design sprint or workshop, you will not have the option to rewind the last couple of days to redefine the problem, if you have fallen into the gone-too-far-haven’t-said-anything trap… even though that’s exactly what you should do.
The costs of continuing on this periled path are high.
Slow down, tackle the problem first
One of the most overlooked ways to combat this challenge of not having a proper problem defined is to slow down before going into the next design sprint — or any kind of design session that involves you collaborating with your team on a solution.
Instead of relying on a special time that has been carved out to define the problem in the design sprint agenda, work with your product manager a few days ahead of the session to discuss the problem.
Not only will your product manager appreciate your interest, but you’ll be able to dig deeper into the problem space, have an opportunity to do some preliminary research, and learn how to write down a problem statement.
Before you start any kind of design workshop, you should always know what problem you and your team are going to try to solve. You don’t need to go overboard with it either.
“Great designers realise you can’t know everything and are comfortable with high levels of ambiguity. “— Andy Budd
As long as you and your product manager have worked together on the problem and you both agree with the direction you need to go, then everything else gets much smoother.
This way you are set up for success when you get to “problem definition” on the design sprint agenda and use the time effectively to go deeper and understand the problem space, rather than debating things that could have been easily resolved beforehand.
So, how do you define the right problem then?
Here are two techniques that have helped me when I had to take the lead in driving the problem space forward.
1) Identify the problem
The first thing you need to do is find what the problems are and where they occur. You can gain more insight by looking at the following areas:
Research
What data already exists in your team that has been done from user research, customer interviews and usability testing (even surveys).
Roadmap
Probably the easiest way to get started “for free” is by looking at your team’s roadmap. However, you’d need to watch out for if your roadmap is defined with features/solutions, which you must rewrite as problems.
Duct tape
“Duct tape” refers to the hacked together solutions that your customers have already created to solve their own problems.
These solutions are often complex and not ideal, but their value outweighs usability and experience, which is a strong signal that there is an opportunity for improvement. Looking at your customer’s duct tape will give you deep insight into the real problems that are worth solving.
2. Frame the problem
One of the pitfalls I see teams walk into, my own included, is we try to write down problems in the form of a framework too early, instead of just writing down the problem.
So, when writing down a problem for the first time, try to include the following:
- What is the problem?
- Who experiences the problem?
- When does the problem occur?
If you’ve at least tried to write down the problem and are still struggling, try out the guidelines from frameworks.
My favourite “templates” for writing down problems comes from a book “Making it Right” by Rian vd Merwe who’s a product manager. In it he shares a simple structure to write down a problem: “user has problem when trigger”.
If you’re not familiar with frameworks that help define problems make sure to check out:
Here’s an example where things didn’t go so well…
I was participating in a design sprint where a big team of designers, product managers and developers were creating a vision for one of our products that could impact the way we develop software in the industry. Two days into the sprint we had already mapped out the user’s journey and defined the problems as “how might we” statements.
In the afternoon we had a check-in to get feedback and discuss our progress with the broader team. The head of product looked at the problems we had written and asked “…but what is the problem you are solving?”
Even though we thought we nailed our problem statements, the problem was we just wrote our solutions as “how might we” statements — which didn’t capture the problem at all.
Not being able to articulate the actual problem makes it harder for others to understand what you are trying to accomplish. More importantly — it makes it difficult to come up with a solution that actaully solves the problem.
There’s nothing wrong with using the “how might we” framework, but first try to simply write down the problem.
Conclusion
We should learn to say no and get comfortable with delaying design sprints — or any session that involves more than three people’s time when the goal of the session is to brainstorm or come up with solutions.
Don’t be afraid to ask what problem the group is solving. When there’s no clear definition of the problem, ask the team to spend some focused time ahead of the sprint to write down and articulate the problem— even if that means you have to postpone the design sprint.
Did you enjoy this post? Want more of the same? Consider following Designing Atlassian.
