Requirements vs. user needs

If you've sat in enough workshops you've probably heard someone say "the requirement is a search filter" or "you'll need a dropdown for that" in the same breath as someone else saying "the user need is to find the right case quickly." Nobody stops to ask if those are the same thing. Usually they're not, and the gap between them is where a lot of digital delivery quietly goes wrong.

Confusing requirements with user needs is one of the most reliable ways to build something efficiently that nobody actually wanted or shifting old problems onto a new system.

Two different questions

A user need is a statement about a person and their goal, independent of any solution:

As someone renewing a licence, I need to know whether my application has been received, so I don't chase it unnecessarily.

No mention of email, dashboards, or notifications. Just the person, the goal, and why it matters to them.

A requirement is a statement about what the system must do:

The system must send an automated email within 24 hours of submission.

That's one possible answer to the need above. It's specific, testable, and buildable, which is exactly why teams gravitate toward requirements early. They feel like progress. But a requirement is already a decision, and if it gets written down before the underlying need is properly understood, you've skipped the step where you find out whether it's the right decision.

Why the confusion is so persistent

Most digital delivery inherits its instincts from procurement and contract management, not from service design. Contracts need requirements, fixed, unambiguous, sign-off-able things. So requirements get elevated to the status of ground truth, gathered in a "requirements gathering" phase, and treated as inputs rather than outputs. This is normally compounded in the public sector when budgets have to be aligned with a specific statement of work.

The trouble is requirements gathered this way are usually just assumptions wearing a formal hat. Someone senior says "users will want a PDF export," it goes in the requirements doc, and eighteen months later the export feature has a 2% usage rate because what people actually needed was to share a specific view with a colleague — which a shareable link would have solved with none of the PDF rendering pain.

Requirements tell you whether you built it right. Needs tell you whether you built the right thing.

User needs resist this shortcut. They have to be discovered, through research, not assumptions, which is slower and less comfortable in a kickoff meeting. That's precisely why they get skipped.

What goes wrong when you skip straight to requirements

• You optimise for the wrong thing. A requirement can be delivered perfectly and still fail the person it was meant for, because nobody checked it against a real need.
• Scope becomes negotiable in the wrong direction. Without a need to anchor against, requirements get added ("while we're at it…") or cut under time pressure based on who shouts loudest, not on user impact.
• You lose the ability to say no well. If a stakeholder asks for a feature and all you have is a requirements list, you can only push back on cost or feasibility. If you have the underlying need mapped, you can say "here's a cheaper way to meet the same need" — a much stronger conversation.
• You can't tell good delivery from bad delivery. Requirements met = ticked box. Needs met = the service actually works. Teams that only track the former can hit 100% delivery against a spec while the service fails its users.

This is precisely why the GOV.UK Service Standard leads with "understand users and their needs" as point one, ahead of anything about technology, architecture, or delivery approach. It's not a nicety, it's sequencing. Needs come first because everything downstream, including requirements, should be traceable back to one.

Requirements should be a translation, not a starting point

The healthy relationship between the two runs one way only:

If your requirements are more stable than your needs, something has inverted. In practice, this means:

• Every requirement should be able to answer "which user need does this serve?" If it can't, question why it exists.
• User need statements go in the discovery and research artefacts and stay there as a reference point through delivery, not just as a discovery-phase exercise that gets archived once the backlog exists.
• Service blueprints are useful here because they surface user needs at each touchpoint and show the current requirement meeting it side by side — making the gap visible rather than assumed.
• When a stakeholder hands you a requirement, the useful move isn't to accept or reject it — it's to ask what need it's trying to meet, and check whether that's actually the best way to meet it.

The practical test

A quick way to check whether you're looking at a need or a requirement: try removing all mention of technology, UI, or process from the statement. If it still makes complete sense, it's a need. If it collapses into nothing, it was a requirement all along.

"Users need a mobile app" — remove the technology and there's nothing left. Not a need.

"Users need to check their application status while away from a desk" — still coherent. That's a need, and a mobile app is just one possible answer to it.

Holding this distinction isn't pedantry — it's the difference between building things that work and building things that were merely specified. Digital delivery needs both requirements and needs, but only one of them should ever come first.