Be uncomfortable with ambiguity
“Get comfortable with ambiguity” is one of those phrases that turns up in every design leadership job advert. I think it’s almost right, and the small way it’s wrong matters. The goal is to be willing to be uncomfortable in ambiguity, for longer than feels natural, because that discomfort is doing useful work.
Discomfort is a signal, not a problem to remove
When a brief is vague, or the problem isn’t yet defined, or two senior people clearly mean different things by the same word, you feel a pull. The pull is towards resolution: pick a direction, draw a screen, do something. It’s a good instinct in most of life and a dangerous one in early design, because acting dissolves the discomfort without resolving the ambiguity. You feel better, and you’ve learned nothing.
The discomfort of an unresolved problem is information. It’s telling you that you don’t yet understand what you’re being asked to solve. Rush past it and you’ll design a confident, polished answer to the wrong question. That is far more expensive than a few more days of not-knowing, because by then there’s code, stakeholder buy-in, and sunk cost defending it.
The expensive instinct: premature closure
Psychologists call the urge to resolve uncertainty quickly the need for cognitive closure. In a design team it shows up as a rush to the artefact: jumping to wireframes before anyone can state the user goal, turning a fuzzy request into a feature list because a list feels like progress, or treating the first plausible solution as the solution.
Premature closure is seductive because it produces visible output. A wireframe looks like work in a way that “I’m still not sure what problem we’re solving” does not. But a wireframe built on a misunderstanding is negative progress: it now has to be unbuilt, and it has quietly anchored everyone’s thinking around the wrong frame.
The discipline is to keep the problem open on purpose, letting it stay uncomfortable until you actually understand it.
Sitting in it productively
Being uncomfortable with ambiguity should be active rather than a matter of wallowing in it. A few things I try to do before I let myself reach for a solution:
- Name the ambiguity out loud. “We’re using ‘dashboard’ to mean three different things.” Making the fog explicit is often half the work, and it gives the team something concrete to resolve.
- Separate the two kinds. Some ambiguity is resolvable: you can clear it with research, a conversation, or a definition, and you should. Some is irreducible, genuine uncertainty about the future or about people you can’t fully predict, which you have to design around rather than away. Spend your energy resolving the first kind and stop torturing yourself over the second.
- Stay in the problem space. Resist the gravitational pull towards solutions. Ask what the user is actually trying to achieve, what would have to be true for this to work, who is not in the conversation. (Two lists help here.)
- Make the uncertainty cheap to explore. Sketches, throwaway prototypes, and small experiments let you probe an ambiguous space without committing to it. The point is to learn enough to narrow the ambiguity honestly, not to produce a deliverable.
Why it’s a leadership skill as much as a personal one
The reason this matters most for design leaders is that teams take their tolerance for ambiguity from the top. If you visibly twitch towards closure, rewarding the person who produced a screen over the person who clarified the problem, everyone learns to perform certainty they don’t have. Decisions get made early and defended late.
A leader who can stand in front of stakeholders and say “we don’t know yet, and here’s how we’ll find out” gives the whole team permission to do the same. That is a refusal to convert discomfort into false confidence, holding the door open just long enough for the real problem to walk through.
So no, don’t get comfortable with ambiguity. Get good at being uncomfortable in it, and at noticing the precise moment the discomfort has taught you what it came to teach, and not a moment before.