V
The job market really values designers who know how to work with ambiguous problems.
Job descriptions usually describe this skill with nice phrases like comfortable with ambiguity, able to navigate uncertainty, or strong problem-framing skills.
But if we translate that into normal human language, it sounds more like this:
“We need a designer who can be given something unclear, preferably due yesterday, and somehow figure it out.”
I wasn’t always that kind of designer.
In 2020, I joined YCLIENTS, an online booking service used by beauty salons and other service businesses. By that point, the product had existed for years and had mostly been built by engineers, while the product and design functions were still taking shape.
To me, the whole thing looked like one enormous knot of ambiguity: a complex B2B product, dozens of connected user flows, an unfamiliar domain, processes I didn’t understand, and tasks where it was difficult to tell where they started or ended.
I looked at that knot and had absolutely no idea which thread to pull first. Eventually, I backed out and ended my probation period myself after about a month.
Over the next six years of my career, I had to get much better at exactly the skill I was missing back then: working with uncertainty.
Today, when someone comes to me and says, “Valeriia, we need to come up with something like this, it’s very important, and we need it ASAP,” I feel less terrified and much more curious.
Because now I look at these problems differently.
I love detective stories, and I like to think of an ambiguous product problem as a Hercule Poirot investigation.
Imagine the beginning of a classic murder mystery: there is a mysterious body in a locked room, a broken cup on the table, a missing will, five suspects in the house, and a gardener who is definitely hiding something. Everyone has their own version of what happened, half of the details seem completely random, and the reader already suspects the butler.
At first, it all looks like chaos.
But Poirot doesn’t stare at the room for five minutes and say:
“Looks like the gardener did it. Let’s build a prototype.”
He starts looking for connections between the clues. We can do exactly the same thing with ambiguous product problems. So it’s time to put on our pince-nez, mentally twist our moustache, and start investigating the case.
When designers are given a problem, the natural instinct is to start solving it: open Figma, sketch a few options, and finally turn something vague into something tangible.
Instead, I try to first understand what actually happened. Where did this task come from? Who initiated it? Which users are we designing for? What happens today? Has anyone tried to solve this problem before, and what happened? At this point, I also collect everything the team already knows: research, analytics, support tickets, and results from previous experiments.
And there is one particularly important question:
Which of these things do we actually know, and which are we only assuming?
In complex projects, facts and assumptions become mixed up surprisingly quickly.
“Users don’t understand this feature” sounds like a fact.
But how do we know?
Did we see it in user research? Does the data show it? Did users complain about it to support? Or did five people sit in a meeting and simply decide that this must be the reason?
A simple assumption-mapping exercise can help here: literally separate everything into two groups — “we know” and “we assume.”
Sometimes half of the mystery disappears at this stage alone.
In a good detective story, a murder rarely happens simply because the author wanted a dead body in the library.
There is a motive. Product problems have motives too.
Why does the business want to change something in the first place? Does it want to increase revenue, reduce costs, improve retention, attract a new audience, solve a systemic user problem, or achieve a strategic goal?
Or perhaps the CEO saw something cool in a competitor’s product and now wants the same thing? That’s a motive too, by the way. It just requires a slightly different investigation
Understanding the motive helps us do something very important: separate the actual problem from the solution someone has already suggested.
Quite often, what reaches a designer isn’t a problem at all. It’s already somebody’s answer to it.
Now we have the clues and the motive, but the investigation isn’t over yet. We need to connect the scattered facts and try to understand what is actually happening and which problem we are really solving.
One simple technique I like here is the 5 Whys: asking “why?” several times instead of accepting the original problem statement as the truth.
Let’s continue our interrogation:
— Users aren’t using the feature. Why?
— Maybe they don’t understand how it works.
— Why do we think that?
— They rarely reach it after registration.
— But does that mean they don’t understand it?
— Hmm. Maybe they simply don’t see any value in it.
And suddenly, the investigation takes a completely different direction.
If users understand the interface perfectly well but don’t see any reason to use the feature, another ten onboarding screens aren’t going to help.
This is what problem framing is really about: gradually moving away from ready-made solutions, challenging assumptions, and trying to identify the real problem.
The more precisely we define it, the less that enormous knot looks like a knot.
There is one more thing that is very easy to miss when working with an ambiguous problem: how will we know that we have actually solved it?
I try to agree on success criteria with the team in advance. It could be higher conversion or retention, fewer errors, a faster user flow, increased feature adoption, or fewer support requests.
Not every project has to end with a beautiful graph showing +17%.
If a product is still being built or we are at an early stage, success might mean validating a hypothesis through research, passing a usability test, launching a particular stage, or making an important strategic decision.
The important thing is to understand in advance what evidence will allow us to say: yes, we solved the problem that started this investigation.
Otherwise, three months later, the team might build a beautiful feature only to discover that nobody in the room knows whether it made the user’s life any better.
Now we can open Figma.
Because instead of:
“We need to make something like this, it’s very important, and we need it urgently,”
we now have a perfectly normal product problem.
We understand who has the problem and why the business wants to solve it. We know which things are facts and which are assumptions. We have defined what we are actually trying to change and how we will know whether it worked.
One big, scary piece of uncertainty has gradually turned into several smaller, understandable problems that we can decompose, prioritise, and solve.
And that is probably the most important thing I’ve learnt in the six years since I ran away from YCLIENTS.
Working with ambiguous problems isn’t a superpower that allows certain senior and staff designers to magically find the right answer. It is the ability to collect scattered facts, find connections between them, and turn something big and unclear into smaller, understandable pieces.
And in this situation, the best designer isn’t necessarily the person who comes up with a solution first. Sometimes, it’s the person who keeps asking the right questions for longer. After all, Poirot rarely solved a murder just by looking at the body.
So the next time someone hands you a completely unclear problem with a deadline of “yesterday,” don’t rush to open Figma.
Put on your pince-nez first.
We have a case to investigate.
Job descriptions usually describe this skill with nice phrases like comfortable with ambiguity, able to navigate uncertainty, or strong problem-framing skills.
But if we translate that into normal human language, it sounds more like this:
“We need a designer who can be given something unclear, preferably due yesterday, and somehow figure it out.”
I wasn’t always that kind of designer.
In 2020, I joined YCLIENTS, an online booking service used by beauty salons and other service businesses. By that point, the product had existed for years and had mostly been built by engineers, while the product and design functions were still taking shape.
To me, the whole thing looked like one enormous knot of ambiguity: a complex B2B product, dozens of connected user flows, an unfamiliar domain, processes I didn’t understand, and tasks where it was difficult to tell where they started or ended.
I looked at that knot and had absolutely no idea which thread to pull first. Eventually, I backed out and ended my probation period myself after about a month.
Over the next six years of my career, I had to get much better at exactly the skill I was missing back then: working with uncertainty.
Today, when someone comes to me and says, “Valeriia, we need to come up with something like this, it’s very important, and we need it ASAP,” I feel less terrified and much more curious.
Because now I look at these problems differently.
A Murder in the Product Backlog
I love detective stories, and I like to think of an ambiguous product problem as a Hercule Poirot investigation.
Imagine the beginning of a classic murder mystery: there is a mysterious body in a locked room, a broken cup on the table, a missing will, five suspects in the house, and a gardener who is definitely hiding something. Everyone has their own version of what happened, half of the details seem completely random, and the reader already suspects the butler.
At first, it all looks like chaos.
But Poirot doesn’t stare at the room for five minutes and say:
“Looks like the gardener did it. Let’s build a prototype.”
He starts looking for connections between the clues. We can do exactly the same thing with ambiguous product problems. So it’s time to put on our pince-nez, mentally twist our moustache, and start investigating the case.
1. Collect the Clues
When designers are given a problem, the natural instinct is to start solving it: open Figma, sketch a few options, and finally turn something vague into something tangible.
Instead, I try to first understand what actually happened. Where did this task come from? Who initiated it? Which users are we designing for? What happens today? Has anyone tried to solve this problem before, and what happened? At this point, I also collect everything the team already knows: research, analytics, support tickets, and results from previous experiments.
And there is one particularly important question:
Which of these things do we actually know, and which are we only assuming?
In complex projects, facts and assumptions become mixed up surprisingly quickly.
“Users don’t understand this feature” sounds like a fact.
But how do we know?
Did we see it in user research? Does the data show it? Did users complain about it to support? Or did five people sit in a meeting and simply decide that this must be the reason?
A simple assumption-mapping exercise can help here: literally separate everything into two groups — “we know” and “we assume.”
Sometimes half of the mystery disappears at this stage alone.
2. Find the Motive
In a good detective story, a murder rarely happens simply because the author wanted a dead body in the library.
There is a motive. Product problems have motives too.
Why does the business want to change something in the first place? Does it want to increase revenue, reduce costs, improve retention, attract a new audience, solve a systemic user problem, or achieve a strategic goal?
Or perhaps the CEO saw something cool in a competitor’s product and now wants the same thing? That’s a motive too, by the way. It just requires a slightly different investigation
Understanding the motive helps us do something very important: separate the actual problem from the solution someone has already suggested.
Quite often, what reaches a designer isn’t a problem at all. It’s already somebody’s answer to it.
3. Build a Theory of the Crime
Now we have the clues and the motive, but the investigation isn’t over yet. We need to connect the scattered facts and try to understand what is actually happening and which problem we are really solving.
One simple technique I like here is the 5 Whys: asking “why?” several times instead of accepting the original problem statement as the truth.
Let’s continue our interrogation:
— Users aren’t using the feature. Why?
— Maybe they don’t understand how it works.
— Why do we think that?
— They rarely reach it after registration.
— But does that mean they don’t understand it?
— Hmm. Maybe they simply don’t see any value in it.
And suddenly, the investigation takes a completely different direction.
If users understand the interface perfectly well but don’t see any reason to use the feature, another ten onboarding screens aren’t going to help.
This is what problem framing is really about: gradually moving away from ready-made solutions, challenging assumptions, and trying to identify the real problem.
The more precisely we define it, the less that enormous knot looks like a knot.
4. Decide What “Case Closed” Means
There is one more thing that is very easy to miss when working with an ambiguous problem: how will we know that we have actually solved it?
I try to agree on success criteria with the team in advance. It could be higher conversion or retention, fewer errors, a faster user flow, increased feature adoption, or fewer support requests.
Not every project has to end with a beautiful graph showing +17%.
If a product is still being built or we are at an early stage, success might mean validating a hypothesis through research, passing a usability test, launching a particular stage, or making an important strategic decision.
The important thing is to understand in advance what evidence will allow us to say: yes, we solved the problem that started this investigation.
Otherwise, three months later, the team might build a beautiful feature only to discover that nobody in the room knows whether it made the user’s life any better.
So Where Is the Design?
Now we can open Figma.
Because instead of:
“We need to make something like this, it’s very important, and we need it urgently,”
we now have a perfectly normal product problem.
We understand who has the problem and why the business wants to solve it. We know which things are facts and which are assumptions. We have defined what we are actually trying to change and how we will know whether it worked.
One big, scary piece of uncertainty has gradually turned into several smaller, understandable problems that we can decompose, prioritise, and solve.
And that is probably the most important thing I’ve learnt in the six years since I ran away from YCLIENTS.
Working with ambiguous problems isn’t a superpower that allows certain senior and staff designers to magically find the right answer. It is the ability to collect scattered facts, find connections between them, and turn something big and unclear into smaller, understandable pieces.
And in this situation, the best designer isn’t necessarily the person who comes up with a solution first. Sometimes, it’s the person who keeps asking the right questions for longer. After all, Poirot rarely solved a murder just by looking at the body.
So the next time someone hands you a completely unclear problem with a deadline of “yesterday,” don’t rush to open Figma.
Put on your pince-nez first.
We have a case to investigate.