A user need is not just a design requirement. It points the work in a direction.

That direction matters. If a need closes down the solution space too quickly, it may already be too narrow. Small changes in wording can change which solution types become imaginable, testable or dominant.

Interactive sketch

User needs are vectors, not labels

Change the need and watch the solution field rotate. The wording changes what the work can imagine, compare and test.

Current need

I need to understand my options.

Vector from user need to solution field Need anchor Solution field

This is mostly a cognitive need. It points towards explanation, orientation and language clarity.

Red flag

Users rarely need to understand something for its own sake. GOV.UK guidance treats “understand” needs as exceptional because they are often hard to test and can hide the real thing the person needs to do, decide, access or resolve.

Need direction

Comprehension
Comparison
Judgement
Access
Agency
Continuity
Redress

Solution field

Plain-language guideFAQGlossaryPeer storiesService mapComparison tableTrade-off mapAdviser conversationDecision supportEligibility checkerEvidence checklistReferral routeAppeal routeFallback planAdvocacyReview point

Why this matters

I need to understand my options and I need to evaluate which options are realistic for me sound close, but they are not the same need.

The first is mainly cognitive. It points towards explanation, plain language and orientation.

The second is about judgement under constraint. It points towards comparison, trade-offs, eligibility, risk and support for deciding what is realistic.

That is why user needs are not just labels. They are vectors.

When the need changes, the implied obligation changes. When the obligation changes, the solution field changes.

This is only a sketch, but it shows a practical risk in user-needs work: weak wording does not just describe the work badly. It can close down the space of possible responses.