User needs are the least-taught and most-audited artifact in the design history file.
Search the web for how to write them and you get vendor blog posts a paragraph long, a withdrawn 1997 FDA guidance that half the links 404 on, and a lot of confident advice that quietly contradicts itself. Meanwhile the consequence of getting them wrong is not a red mark in a review — it is a design validation activity, years downstream, that cannot answer the only question it exists to answer: did we build the right thing?
Bad user needs do not fail loudly. That is what makes them expensive.
This article is the method we teach, with the standards that back each step.
1. What a user need actually is
The three-layer stack
- User need — what the user must be able to accomplish, in their language, in their environment.
- Design input — the engineering requirement derived from that need, verifiable against the design.
- Design output — the thing you built, plus its acceptance criteria.
Two different questions run down this stack:
- Validation asks did we build the right thing? It tests against user needs.
- Verification asks did we build the thing right? It tests against design inputs.
Collapse the layers and you lose the ability to answer either question. This is the single most common structural defect we find.
The unit of design validation is the task
Here is the reconciliation that makes the rest of this tractable.
ISO 13485:2016 clause 7.3.7 frames design validation against user needs and intended use. That framing is document-shaped: needs go in, evidence comes out, and everyone argues about whether the trace matrix is complete.
FDA’s human factors posture is task-shaped: the unit of analysis is a user, performing a task, in a use environment, and whether they can complete it without a harm-producing use error.
Make the task the unit of validation and both frames collapse into one:
- A task is the smallest thing a user actually does, so it is a user need expressed in its natural unit rather than a paraphrase of one.
- Tasks are observable. You can watch one succeed or fail in simulated use. “User needs met” is not observable; task completion is.
- Critical-task analysis already exists in the human factors world and is already risk-linked. Your validation coverage argument becomes a risk argument instead of a paperwork argument — which is the argument you actually want to have with a reviewer.
- The trace cleans itself up: user need → task(s) → critical task where harm is possible → validation evidence. One spine, two standards, no second authoring pass.
The corollary is the most useful filter in this article: if a stated user need does not decompose into at least one observable task, it is probably not a user need. It is a marketing sentence, or a design input that wandered upstream.
Need → action → system response → outcome
A well-formed need sits in a chain. The user has a need; the user takes actions; the system responds with functions; together those produce the desired outcome. Design validation is the activity that relates all four. If you cannot draw that chain for a given need, the need is not finished.
Each user need fans out into user actions and system responses that converge on a desired outcome — and the outcome traces back to the need. Note that the system can act first, with the user responding (Function 2.1).
What the standards actually require
- ISO 13485:2016, clause 7.3.3 requires design inputs to include functional, performance, usability, and safety requirements according to the intended use. Note that “usability” sits alongside functional and performance. It is not optional and it is not a UX nicety.
- IEC 62366-1:2015, clause 5.1 requires a use specification covering the indication, patient population, part of the body, intended user profile, use environment, and operating principle.
- AAMI HE75 states that usability objectives should be established on the basis of defined user needs and requirements — the linkage is expected, not invented by you.
- FDA General Principles of Software Validation, section 6.2, anchors validation to defined user requirements. Undefined ones cannot be validated, which sounds obvious until you read a real DHF.
That IEC 62366-1 use specification is largely the same content as a well-written user needs set. More on that below, because it is free money.
2. Where user needs come from
Six legitimate sources
- Contextual inquiry — watch the actual user do the actual task in the actual place. Not a survey. Not a focus group in a conference room.
- Clinical and procedural literature for the indication and the surrounding workflow.
- Predicate and competitor devices, including their complaint and MAUDE histories. Other people’s use errors are free research.
- Your own postmarket data — complaints, service records, support tickets, observed use errors.
- Regulatory and standards obligations that constrain what a user may be asked to do.
- Business and reimbursement stakeholders, labeled honestly as such and not disguised as clinical need.
Define the user before the need
You cannot write a user need without naming the user. Most bad needs skip this step and default to “the user,” which means the document has five different users hiding behind one pronoun.
IEC 62366-1 clause 5.1 forces the question: intended user profile, training, and use environment. Distinct user groups get distinct needs — clinician, patient, lay caregiver, service technician, IT administrator.
A lay caregiver in a dim bedroom at 2 a.m. is operating a different device than a nurse in a lit procedure room, even when the part number matches.
Write the user profile table first. The needs then very nearly enumerate themselves.
User needs are not stakeholder needs
This distinction gets conflated constantly, including in our own earlier drafts.
| User need | Stakeholder need | |
|---|---|---|
| Definition | What users must accomplish to get the right outcome from the product | Business goals and constraints that shape the design |
| Example | The radiologist needs image enhancement performed on DICOM-format images | The company needs the product legally marketable in the US and EU |
| Who | Patients, clinicians, radiologists, customer sites, service technicians | Partners, installers, regulators, payers, the company itself |
Keep them in one backlog if you like, but label the type. They validate differently, and a regulator-driven need is not a use-error risk. Laundering a business constraint into a clinical user need is how validation protocols end up testing things no human being does.
Develop needs across the whole lifecycle
- Define the product lifecycle first: installation, deployment, onboarding, use, service, retirement.
- Build the use workflow. Document each major step, manual or automated, and the desired outcome of each step.
- Conduct voice-of-customer research and fold in the needs that surface only from observation.
- Cover users and stakeholders across that entire lifecycle, not just the clinical moment.
- Then decide how each need allocates to the system of interest.
Most needs sets we review cover step 4 of a twelve-step lifecycle beautifully and ignore the other eleven. Installation and service are where the unglamorous use errors live.
3. How to write one
The anatomy of a good user need
- Name the user group explicitly. Not “the user” if you have five user groups.
- State the capability or outcome, not the mechanism. No solutions in the need.
- State the conditions that matter — environment, urgency, gloves, lighting, distraction, connectivity.
- Be singular. One need, one idea, one validation objective.
- Be traceable to a source, so that “how do you know?” has an answer.
- Be validatable by a defined method — which is not the same thing as quantified.
Verifiable does not mean quantified
This is the most common false rule in the industry, and it does real damage.
There are four evaluation methods: Inspection, Demonstration, Test, and Analysis. Only Test demands a numeric acceptance criterion. The other three are fully legitimate.
A user need validated by simulated-use demonstration is verifiable. It needs no number. Forcing numbers onto user needs is how teams invent fake thresholds that nobody can defend and that no clinician recognizes.
Quantification belongs downstream, in performance design inputs, where it can actually be measured. Keep functional needs and performance requirements separate; never merge them into one statement.
“The clinician needs to confirm dose delivery without looking away from the injection site.”
That is a good user need. It has no number in it. It is validated by demonstration in simulated use. Anyone who rejects it for lacking a threshold is asking you to make something up.
Rewrites: before and after
| Weak statement | Why it fails | Rewritten user need |
|---|---|---|
| The device shall have a 2.8-inch OLED display. | Solution, not need. Locks the design at the wrong layer. | The clinician needs to confirm delivered dose without looking away from the injection site. |
| The device shall be easy to use. | Not validatable. No user, no condition, no outcome. | An untrained lay caregiver needs to complete a first dose using only the quick-start guide. |
| The system shall not lose patient data. | Negative phrasing; no observable passing condition. | The clinician needs recorded session data to remain retrievable after an unplanned power loss. |
| Alarm shall be audible at 85 dB. | Performance requirement wearing a user-need costume. | The nurse needs to detect an occlusion alarm from the adjacent room during normal ward activity. |
| The device shall comply with IEC 60601-1. | Regulatory obligation, not a user need. | Keep as a separate standards-compliance design input, traced independently. |
Phrasing rules that survive audit
- Write positively. State what must be achievable, never what shall not happen. “Shall not” statements have no bounded passing condition and are not INCOSE practice.
- One need per statement. The words “and” and “or” are usually a split signal.
- No solution nouns — no display, no button, no algorithm, no database.
- No vague adjectives — easy, efficient, convenient, comfortable, intuitive, robust, user-friendly, seamless. None of those are validatable as written.
- Use the user’s vocabulary, not engineering’s. If a nurse would not say it out loud, rewrite it.
4. Structure, traceability, and upkeep
Allocate needs before you write requirements
Develop user needs prior to allocating them to the system of interest.
Then allocate. Some needs land inside your system boundary and become design inputs. Some land outside it — on the hospital network, the EHR, an accessory, a third-party service, the user’s own phone.
A need that allocates outside your system of interest does not vanish. It becomes an interface requirement with that system.
This is the cleanest answer we know to the perennial “what do we do with needs about the hospital IT environment?” You do not delete them and you do not pretend you own them. You convert them into interfaces, and then you can actually verify them.
Do not encode traceability in the identifier
A scheme like UN-011 → FS-UN-011 → DS-UN-011 puts the relationship inside the name.
Every change then triggers a rename cascade across documents, tools, and test records. That is how a thirty-minute fix becomes a full day of document surgery, and it is why teams stop making improvements they know are correct.
Use opaque, stable identifiers plus an explicit trace matrix that holds the relationships. Identifiers should be immutable for the life of the item. Relationships are data, not names.
(This one is engineering judgment rather than a standards requirement — but we have paid for it more than once.)
Write it once: user needs and the use specification
IEC 62366-1 clause 5.1’s use specification and your user needs set are largely the same content.
Most organizations author both, in different departments, that do not talk to each other — and then reconcile them badly under time pressure. Pick one source of record and reference it from the other rather than duplicating text. The usability engineering file and the design history file should never disagree, and the cheapest way to guarantee that is to stop writing the content twice.
Common failure modes
- Back-justification — writing needs after the design exists, to match the design.
- Requirement laundering — a design input copied upward and relabeled as a user need.
- Orphan needs with no validation objective, and validation tests with no parent need.
- Stakeholder-wish inflation — sales preferences documented as clinical necessity.
- Frozen needs — never revisited after postmarket data contradicts them.
- Single-author needs — written by one engineer and reviewed by nobody who touches the device.
A working review checklist
| Check | Pass condition |
|---|---|
| Named user | A specific user group from the user profile table, not “the user” |
| Solution-free | No mechanism, component, or technology appears in the statement |
| Singular | One capability per statement; no compound “and” clauses |
| Conditioned | Environment and circumstances that affect success are stated |
| Sourced | Traceable to inquiry, literature, postmarket data, or a standard |
| Validatable | A named method exists: inspection, demonstration, test, or analysis |
| Positively phrased | States what must be achievable, not what shall not occur |
| Linked | Trace matrix entry exists to design inputs and a validation objective |
| Task-decomposable | Decomposes into at least one observable task in simulated use |
The part no web resource will tell you
User needs are not gathered. They are negotiated.
The failure mode is almost never bad writing. It is writing them after the design already exists and back-justifying, then discovering at design validation that the document describes a product nobody asked for.
So when someone asks how to do user needs properly, the first question back is not about format. It is: is the product already built?
Sources
- ISO 13485:2016, clause 7.3.3 (design and development inputs, including usability per intended use) and clause 7.3.7 (design and development validation).
- IEC 62366-1:2015, clause 5.1 (prepare use specification) and clause 5.6 (user interface specification).
- AAMI HE75:2009 (R2013), clauses 9.2 and 9.3.4.8.2 (usability objectives established on defined user needs).
- FDA, General Principles of Software Validation, section 6.2 (defined user requirements).
- FDA, Applying Human Factors and Usability Engineering to Medical Devices (validation under simulated use conditions).
- INCOSE requirement-phrasing practice (positive phrasing; functional and performance requirements kept distinct).
A note on 21 CFR 820.30. Older training material — including ours — quoted 21 CFR 820.30 for the design validation definition. That section was removed from the CFR effective 2026-02-04 under the QMSR transition. Cite ISO 13485:2016 clause 7.3.7 instead. If you find a blog post still quoting 820.30 as current, that tells you when it was written.
Highland Biomedical helps medical device companies build design controls, software lifecycle, human factors, and cybersecurity evidence that holds up under review.