IT: +39 338 62 46 214
How to Lead UX Work When Nobody Knows What They Want
There’s a specific kind of meeting that every UX lead eventually learns to dread. You’re sitting at the table, the project has just been kicked off, and someone — usually a product manager, sometimes a stakeholder, occasionally a well-meaning executive — says the words: “We’re still figuring out exactly what we need, but we wanted to get design involved early.”
You nod. You say that’s great. Internally, you wonder what you’re supposed to do with that.
Unclear requirements are not an edge case. They’re the default state of most interesting projects. The difference between a UX lead who struggles in this environment and one who thrives in it isn’t experience or talent — it’s knowing what role design actually plays before the requirements exist.
The trap: waiting for clarity that never comes
The most common response to unclear requirements is patience. You wait for the product spec to solidify. You ask for “just a bit more context” before starting. You prototype cautiously, hedge your directions, and avoid committing to anything that might be “wrong” once the requirements finally land.
Here’s why this fails: in ambiguous projects, requirements don’t arrive fully formed after a waiting period. They emerge through the process of making. The act of sketching a user flow reveals assumptions nobody knew they were making. A low-fi prototype placed in front of a stakeholder produces more clarity in 20 minutes than three weeks of requirements workshops.
If you wait for clarity before designing, you’re opting out of the thing that creates clarity. The UX lead’s job in an ambiguous project is not to execute a brief. It’s to make the brief possible.
Idea 1. Make assumptions explicit before making decisions
When requirements are unclear, everyone on the team is operating on assumptions. The product manager assumes the user is a certain type of person. The engineer assumes a certain technical constraint is fixed. Nobody has said these things out loud, which means nobody can challenge them.
Your first job as UX lead is to surface the assumptions and write them down. I create a simple assumption log at the start of any ambiguous project. Each row has three columns:
- The assumption — stated clearly, in plain language
- Confidence level — high / medium / low
- How we could validate it — even a rough idea is enough
Low-confidence assumptions become your immediate research questions. High-confidence ones become the constraints you design within. The act of writing them down also has a social function: it gives the team something concrete to react to, and reactions to a list of assumptions produce far more useful information than answers to the question “what do you need?”
Idea 2. Design the question, not the answer
When requirements are unclear, the instinct is to narrow down to one direction and defend it. More often, in genuinely ambiguous situations, this is premature convergence — and it costs you.
Instead of arriving at a review with one refined direction, bring two or three rough concepts that each represent a different answer to an underlying question the team hasn’t made yet. The concepts aren’t alternatives to choose between aesthetically. They’re probes. Each one embodies a different bet:
- Concept A assumes users want to do this task independently and need speed
- Concept B assumes users need guidance and are willing to trade speed for confidence
- Concept C assumes users will delegate the task to someone else and just need to review the output
When you frame them this way, the conversation stops being “which one looks better” and starts being “which of these assumptions is true?” That’s a much more productive conversation — and it usually produces the clarity you were waiting for.
Idea 3. Use research as a steering tool, not a validation tool
In most organizations, research is treated as a phase. In ambiguous projects, this model breaks down — because you often don’t know enough to design a proper study upfront, and waiting until the end to test means you’re validating decisions that are already expensive to change.
What works better is treating research as a steering tool you use continuously, in small doses:
- Instead of a 3-week generative study, run 4 × 30-minute conversations with users about their current behavior — no prototype, no tasks, just “walk me through the last time you did X.”
- Instead of a formal usability test, put a rough sketch in front of one real user and ask them to think out loud while they try to do something.
- Instead of a survey, sit next to a customer support person for an hour and listen to incoming tickets.
The goal in each case is the same: reduce the cost of your current assumption. You’re not trying to prove anything. You’re trying to find out if you’re pointed in the right direction before you invest more.
Idea 4. Make the invisible visible — for everyone
The hardest thing about unclear requirements is that the confusion is often invisible. Everyone nods in meetings. Everyone says “sounds good.” And then three weeks later, when you show work, it becomes clear that four different people had four completely different images in their heads of what was being built.
A few tools that consistently help:
- Journey maps as alignment tools, not deliverables. Sketch a rough one in the first week and use it as a provocation: “Is this the journey we’re designing for? What’s wrong with it?”
- Vocabulary lists. A shared document where the team defines key terms. What do we mean by “user”? What counts as a “task completed”? What’s the difference between a “notification” and an “alert” in this system?
- Concrete scenarios over abstract requirements. Instead of “the user should be able to manage their account settings,” write “Maria, a procurement manager, needs to change the billing email before the end of the month because her colleague who had the old address just left.”
When you make understanding visible, you also create a record. Invisible assumptions get revised invisibly. Visible ones get debated.
A note on when to escalate
All of the above assumes a certain level of ambiguity that is normal and productive. There’s a different kind of ambiguity that isn’t — when the project lacks requirements not because it’s early, but because there are unresolved conflicts at the stakeholder level being handed down to the team as “figure it out in design.”
Part of your job as UX lead is distinguishing between the two. Productive ambiguity responds to the tools above. Structural ambiguity requires a different conversation — usually with the person who controls the brief, not the people executing it.
Knowing when to escalate doesn’t come from a framework. It comes from paying attention to whether the uncertainty is shrinking as the team does more work, or staying constant regardless of what you learn. If your assumption log keeps filling up but never gets shorter — that’s the signal.
Summary
🔹 Make assumptions explicit — write them down, assign a confidence level, decide which ones need validation first
🔹 Design the question, not the answer — use multiple concepts to surface the decision the team hasn’t made yet
🔹 Use research as a steering tool — small and continuous beats large and occasional
🔹 Make shared understanding visible — journey maps as provocations, vocabulary lists, concrete scenarios
Unclear requirements aren’t a problem design needs to wait out. They’re an invitation. The teams that get the most from UX in ambiguous projects are the ones that learned — usually through painful experience — that design thinking works best not when it executes a clear brief, but when it creates the conditions for one to exist.
Awesome Works
Awesome Works
Related Posts
Use any form
Design impactful user experiences with ease—everything you need is at your fingertips.
Feel free to reach out for a project inquiry, a coffee chat, or a consultation. Let’s explore how I can help you achieve your design goals. Whether it’s crafting impactful experiences or discussing innovative ideas, I’m here to collaborate and bring value to your vision.