Using user needs in decisions
Decisions helps teams identify whether User Needs is the right place to be working and, once they are, which part of the block will be most useful given their situation. It is designed to be scanned quickly, find the situation that matches, follow the guidance, and move forward.
When to use user needs
User Needs is the right starting point when a team has signals but cannot agree on what they mean, when decisions keep stalling because the underlying problem is unclear, or when research and metrics exist but are not connecting to action.
If the team is debating solutions before the problem is clearly defined, User Needs is almost always the right place to begin.
Recognizing Your Situation
1. We have feedback but can't agree on what it means
Teams have interviews, support tickets, analytics, or usability findings — but different people are drawing different conclusions from the same data. Stakeholder opinions are filling the gap that evidence should be filling.
What to do: Start with Techniques to build shared interpretation. Use the Four Ways to Evaluate and the Recognizing Patterns table to organize signals around recurring conditions rather than individual opinions. Then move to the Playbook to structure what you find into a user need output the team can align around.
2. We know something is wrong but can't locate the problem
Metrics are weak, users are dropping off, or satisfaction is low — but the team cannot pinpoint what is actually causing it. The problem feels real but diffuse.
What to do: Use Techniques to apply observation and process mapping across the full workflow, not just the screens where drop-off appears. Look for the patterns table entries that match what you are seeing behaviorally. The problem is usually one layer below where the team is currently looking.
3. We're reacting to feature requests instead of understanding what users actually need
The team is fielding a backlog of user requests, stakeholder asks, and product hunches — but it is not clear which ones reflect a real underlying need and which ones are surface preferences or internal assumptions.
What to do: Use Techniques — specifically Wants vs. Needs and the Laddering method — to reframe requests around the conditions driving them. Then use the Playbook prompt structure to separate features from needs, and the Characteristics of Strong User Needs to evaluate whether what the team has identified is operational enough to act on.
4. We've identified a need but aren't sure if it's the right one
The team has a user need statement but it feels too broad, too solution-framed, or not grounded in enough evidence to confidently move forward with it.
What to do: Use the Characteristics of Strong User Needs in Techniques to evaluate the statement against the strong vs. weak criteria. If the need is too vague, return to the Playbook inputs table and check whether enough signal types are represented. A need supported by only one source usually needs more evidence before it can guide decisions.
5. We have multiple needs emerging at the same time and don't know where to start
Research has surfaced several legitimate user needs across different layers. The team is struggling to prioritize and risks spreading effort too thin or addressing the most visible need rather than the most foundational one.
What to do: Use the Playbook's Multiple User Needs section and the three prioritization questions — which need is blocking the others, which has the strongest evidence, which connects most directly to a business outcome. Then use References to understand how the competing needs relate to each other across layers before deciding where to focus first.
6. We need to explain the problem to stakeholders
The team understands the user need but is struggling to communicate it in a way that creates alignment rather than debate. Stakeholders are gravitating toward solutions before the problem is agreed on.
What to do: Use the Playbook's Primary User Need Output table to structure the problem clearly — evidence, behaviors, roadblocks, why it matters, why it fails. The structured output is designed to ground stakeholder conversations in observable evidence rather than opinion. The Example User Need Summary is a shorter format for presentations or async reviews.
7. We know the need but aren't sure how to measure whether we're improving it
A user need has been identified and the team is ready to move toward measurement, but it is not clear which UX metrics will actually reflect whether the experience is getting better.
What to do: Go to References and open the individual need page. Each page contains behavioral and attitudinal metrics selected specifically for that need, along with heuristics for evaluating current performance. Use the From User Needs to Measurable Signals section in Techniques to connect the need to a measurement approach before moving into the Metrics block.
8. We're setting up an AI Skill for this block
The team is building or refining an AI Skill that uses User Needs and needs to understand which parts of the block the skill should draw from, what inputs it needs, and what output format it should produce.
What to do: The Playbook is the primary source for input formats, prompt structure, and expected outputs. References provides the definitional layer the skill uses to classify needs consistently. Examples provides the worked examples and pattern library the skill uses to calibrate output quality. Use all three together when configuring a skill for this block.
Quick Reference
<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 445px;"><colgroup><col style="min-width: 25px;"><col style="width: 420px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Situation</strong></p></td><td colspan="1" rowspan="1" colwidth="420"><p><strong>Start Here</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p>Can't agree on what signals mean</p></td><td colspan="1" rowspan="1" colwidth="420"><p>Techniques → Playbook</p></td></tr><tr><td colspan="1" rowspan="1"><p>Can't locate where the problem is</p></td><td colspan="1" rowspan="1" colwidth="420"><p>Techniques — Observation, Process Mapping</p></td></tr><tr><td colspan="1" rowspan="1"><p>Reacting to requests instead of needs</p></td><td colspan="1" rowspan="1" colwidth="420"><p>Techniques — Wants vs. Needs, Laddering</p></td></tr><tr><td colspan="1" rowspan="1"><p>Need statement feels weak or too broad</p></td><td colspan="1" rowspan="1" colwidth="420"><p>Techniques — Characteristics, Playbook Inputs</p></td></tr><tr><td colspan="1" rowspan="1"><p>Multiple needs, unclear where to start</p></td><td colspan="1" rowspan="1" colwidth="420"><p>Playbook — Multiple User Needs, References</p></td></tr><tr><td colspan="1" rowspan="1"><p>Need to align stakeholders</p></td><td colspan="1" rowspan="1" colwidth="420"><p>Playbook — Primary Output, Example Summary</p></td></tr><tr><td colspan="1" rowspan="1"><p>Don't know how to measure improvement</p></td><td colspan="1" rowspan="1" colwidth="420"><p>References — Individual Need Page, Techniques — Measurable Signals</p></td></tr><tr><td colspan="1" rowspan="1"><p>Setting up an AI Skill</p></td><td colspan="1" rowspan="1" colwidth="420"><p>Playbook + References + Examples</p></td></tr></tbody></table>
That's Decisions. The structure is: a short orientation, eight situation-based entries each with a clear what to do, and a quick reference table at the end for scanning. Ready to move to Examples when you are.
