Definition
A user need is the outcome a person is trying to achieve, stated independently of any solution. Someone does not need a notification system; they need to not miss a delivery. They do not need a dashboard; they need to know whether anything requires their attention this morning. Phrasing needs this way keeps the solution space open, because many designs can satisfy one need and the obvious one is not always best. Needs also come in layers: the functional outcome, the emotional state around it — anxiety, impatience, embarrassment — and the social context, such as needing to appear competent to a colleague while doing the task.
Why It Exists
The concept exists because teams reliably build the wrong thing when they skip it. Requests arrive already shaped as solutions: from customers who describe the feature they imagine, from sales who repeat the last objection they heard, from executives who saw a competitor's release. Each of these encodes an assumption about the underlying problem, and the assumption is often wrong or partial. Separating need from solution creates a checkpoint. It also gives a team a way to compare unrelated proposals, because two features that look nothing alike can be evaluated against the same question: does this get the person to the outcome faster, more reliably, or with less anxiety?
Examples
- →A request for more export formats that turns out to be a need to share a result with someone who lacks an account.
- →A demand for a faster search that is really a need to find one recently used item, better served by history than by speed.
- →A parent needing to know a child arrived safely, not needing a real-time map of their location.
- →A clinician needing confidence that they have not missed an allergy, not needing more patient data on screen.
History
The idea descends from human factors work, where designers studied what operators had to accomplish rather than what equipment offered. Requirements engineering in software formalized elicitation but often captured stated requests rather than underlying goals. Usability practice in the 1980s and 1990s put the task at the center: Jakob Nielsen's usability engineering and task analysis methods evaluated designs against what people were trying to do. Alan Cooper's goal-directed design argued explicitly that users' goals, not the tasks they currently perform, should drive product structure. More recently the jobs-to-be-done framing popularized by Clayton Christensen and others restated the point for product teams: people hire a product to make progress in a situation.
In Modern Design
Most teams now gather needs from several sources at once: interviews and field observation, support tickets, search logs, session analytics, sales calls and churn surveys. The risk has shifted from having no data to having too much of the wrong kind. Behavioral data shows what people did inside the product that exists and says nothing about what they abandoned or never attempted. Stated preferences in surveys are unreliable predictors of behavior. Good practice triangulates: qualitative evidence to understand why, behavioral evidence to understand how often, and explicit assumptions written down so they can be checked. Teams also write needs into shared artifacts — problem statements, job stories, opportunity trees — to keep them visible during delivery.
Real-World Example
A team running an expenses tool received repeated requests for bulk upload of receipts. Observing actual use showed employees photographing receipts through the month but submitting everything on the last day, because each submission required selecting a project code they often had to look up in another system. The need was not faster uploading; it was avoiding the lookup. Remembering recent codes and suggesting one based on calendar entries removed most of the delay, and bulk upload turned out to matter little once submissions stopped being batched. The requested feature was a workaround for a problem the requesters had stopped noticing, which is the usual shape of the gap between request and need.
Key Principles
- →State needs as outcomes, not features, so the solution space stays open.
- →Treat every request as evidence of a need, not as the need itself.
- →Look for the workaround — people build them around unmet needs, and they point straight at the problem.
- →Consider emotional and social layers alongside the functional outcome.
- →Behavioral data shows what happened inside your product; it cannot show what people gave up on.
- →Write assumptions down explicitly so they can be tested rather than absorbed as fact.
Why it matters
Understanding needs is what prevents expensive, well-built failure. A team can execute a feature perfectly and still waste months because nobody checked whether the request reflected the real problem. It also changes who benefits: designing to stated requests tends to serve the loudest and most confident users, while designing to observed needs surfaces the people who never complained because they simply stopped using the thing. In public and essential services, that difference decides who is served at all. For the designer, needs work is the bridge between research and decision — it converts what people said and did into something a team can argue about and act on.
Then vs Now
Then
Requirements were elicited as written requests and specifications, and success meant delivering what the document said.
Now
Teams triangulate interviews, observation, support data and analytics to state outcomes, while writing down assumptions so they can be tested rather than assumed.
Try it yourself
Take any feature request you have heard recently — at work, from a friend, or in a product's public forum. Write it down verbatim. Then ask why the person wants it, and write the answer. Ask why again, four more times, forcing yourself to stay with outcomes rather than solutions. Stop when the answer becomes a goal that no single feature obviously satisfies. Now list three different designs, one of which is not software, that would meet that goal. Compare them against the original request and note what the request would have cost you had you built it directly.