How Do You Handle Requirements for a System That Will Be Operated by Users With Widely Varying Technical Skill?
This question comes up in almost every domain where the technology has matured enough to leave the specialist’s hands. A surgical robot built in 2010 was operated exclusively by scrub-trained surgical teams. A similar device sold today may be deployed in ambulatory surgical centers staffed by teams with a fraction of that training. An industrial exoskeleton designed for a manufacturing line is now being evaluated for elder care. A drone system once restricted to licensed pilots is being marketed directly to consumers.
In each case, the engineering team faces the same structural problem: the system must be safe and usable across a user capability range that may span two or three orders of magnitude in relevant technical skill. That range cannot be collapsed into a single “representative user.” It must be explicitly modeled, and requirements must be derived from the full distribution.
Here is how to do that rigorously.
Start With a Formal User Population Analysis
The first mistake teams make is treating “user diversity” as a UX problem and handing it to a human factors designer. The second mistake is treating it as a single variable — “novice to expert” — and assuming the system can be designed to the novice end of the scale.
Both approaches fail because they skip the structural engineering step: formally characterizing the intended user populations as distinct groups with distinct capability profiles, and then developing requirements for each.
IEC 62366-1 (Application of Usability Engineering to Medical Devices) is the most rigorous publicly available framework for this work. Its concept of the “intended use” and “intended users” is not a marketing statement. It requires you to specify:
- The knowledge, skills, and abilities the intended user is expected to have
- The training and experience typically associated with that population
- The physical and cognitive capabilities and limitations relevant to device operation
- The environment of use for each population
This analysis becomes the engineering input. Requirements are then derived from it — not from general usability heuristics.
MIL-STD-1472 (Human Engineering Design Criteria for Military Systems) approaches the same problem from a different angle, specifying quantitative criteria for controls, displays, labeling, and cognitive load across varying operator skill levels and operational conditions. Where IEC 62366 is process-oriented, MIL-STD-1472 is criteria-oriented. Teams building systems with mixed civilian-military use, or industrial systems with defense heritage, often find it useful to apply both.
For consumer robotics and general industrial equipment — where neither standard is formally mandated — these frameworks still provide the right analytical structure. The absence of a regulatory mandate does not make user population analysis optional; it just means no one will catch you if you skip it until a product liability event.
Develop Separate Use Case Sets for Each User Population
Once you have characterized your user populations, the next step is to develop use cases for each group independently — not a single unified use case set with “user role” annotations.
This matters because the failure modes differ by population. Consider a medication infusion pump:
- A trained ICU nurse executing a rate change during a high-acuity situation is at risk from workflow interruption errors and confirmation bias on alarm dismissal.
- A home health aide following a laminated instruction sheet is at risk from mode confusion and failure to recognize error states.
- A patient performing self-infusion is at risk from failure to understand feedback, from fatigue affecting fine motor steps, and from motivational factors that may cause deliberate deviation from protocol.
These are not variations on the same use case. They are distinct use cases that share a physical interaction with the same device. Writing them as one use case with conditional branches (“if user is trained, then…”) hides the safety-relevant distinctions and makes verification nearly impossible.
Each population-specific use case should capture:
- The task goal as the user population understands it (not as the engineer understands it)
- The assumed prior knowledge and context the user brings
- The anticipated error modes specific to this population’s capability profile
- The environmental conditions relevant to this population’s typical use setting
This use case development is not a product management artifact. It is a systems engineering artifact that feeds directly into requirements derivation.
Writing Usability Requirements That Are Actually Verifiable
Human factors outputs often stall at the recommendation level: “the interface should be intuitive,” “error recovery should be straightforward,” “the device should accommodate users with limited dexterity.” These are not requirements. They are design aspirations with no verification criteria.
Translating human factors analysis into verifiable requirements requires specifying measurable acceptance criteria tied to the specific user population being addressed.
Examples of the structural difference:
| Non-verifiable | Verifiable |
|---|---|
| ”The alarm system shall be easy to interpret" | "A user from Population B (home health aide, no device-specific training) shall correctly identify the alarm category within 10 seconds on first exposure with probability ≥ 0.90 as demonstrated by summative usability study" |
| "Error recovery shall not require technical knowledge" | "A user from Population C (patient self-infusion) who encounters Error State 3 shall be able to restore normal operation without reference to technical documentation in ≤ 3 unaided attempts" |
| "Controls shall be operable by users with limited dexterity" | "All primary controls shall require an actuation force ≤ 3.5 N and shall be operable by users in the 5th percentile female grip strength category as defined in [reference anthropometric dataset]” |
The verification method — summative usability study, analysis against anthropometric data, simulation — must be specified at the requirement level, not left to the verification plan to invent later.
For safety-critical systems, you will also need to identify which usability requirements are safety-critical and ensure they are treated with the same rigor as functional safety requirements. IEC 62366-1 formalizes this through the concept of “safety-related use scenarios” — your usability requirements that map to those scenarios need failure mode analysis, not just user testing.
The Safety Requirements Problem: Designing for the Full Capability Range
The hardest case is when the same physical safety hazard exists for all user populations, but the protective measure must work differently for each population’s capability level.
A standard approach — specifying a single protective measure and testing it against the least-capable user population — is necessary but not sufficient. It tends to produce systems that are so constrained for the novice population that experienced users work around the constraints, introducing new hazard pathways.
The correct approach is to:
- Identify the hazard and its harm potential independent of user population
- Analyze the likelihood of each failure mode as a function of user capability for each population
- Specify protective measures for each population separately, or specify adaptive protective measures with capability assessment built in
- Verify each protective measure against the population it was designed for
This produces a requirement structure that is more complex than a single safety requirement, but it is honest about the actual risk picture. A safety requirement that reads “the system shall prevent user-initiated overpressure events” without population context is not a complete requirement. It may be easily satisfied for your trained-operator population and catastrophically inadequate for your general-public population — without that distinction ever appearing in your requirement set.
Maintaining Traceability Across the Full Chain
The organizational challenge in all of this is traceability. You are building a chain that runs from:
User population analysis → population-specific use cases → usability requirements → verification methods → safety requirements (where applicable) → design features that implement them
In a document-based requirements environment — Word documents, Excel RTMs, PDF specifications — this chain is extremely difficult to maintain. A change in the user population analysis (you’ve added a new distribution channel; your intended user is now less specialized than originally characterized) must propagate through use cases, through usability requirements, through safety requirements, and into verification plans. In a document environment, that propagation depends entirely on human discipline. It rarely happens completely.
This is the problem that graph-based, AI-native requirements platforms are designed to solve. Flow Engineering is one of the tools that specifically addresses this traceability challenge for hardware and systems teams. Its graph model allows teams to connect user population characterizations directly to the use cases derived from them, and to trace those use cases forward to specific usability and safety requirements. When an upstream node changes — a user population attribute is revised, a use case is added — the downstream requirements affected by that change are immediately visible.
For teams working under IEC 62366, that bidirectional traceability is not optional. The standard requires you to demonstrate that your usability requirements derive from your intended use characterization and that your verification activities map to your usability requirements. Flow Engineering’s structure makes that demonstration tractable; a spreadsheet RTM makes it an audit-season scramble.
Flow Engineering is intentionally focused on requirements and traceability rather than being a full product lifecycle management suite. Teams that also need integrated change management workflows across mechanical, electrical, and software domains will need to evaluate how it connects to adjacent tools in their stack. But for the specific problem of making human factors traceability rigorous — connecting population analysis to requirements to verification — it addresses the problem directly.
Practical Starting Points
If you are starting this work on an existing program where human factors traceability has not been structured:
Week 1: Map your actual user populations. Pull every assumption about user skill level out of existing documents — design inputs, marketing requirements, labeling — and organize them into distinct population profiles. You will likely find inconsistencies. Surface them now.
Weeks 2-3: Audit your use cases against your population list. For each use case, identify which population it represents. If a use case is labeled “generic user,” decompose it. If you have populations with no use cases, that is a requirements gap.
Week 4: Review your usability requirements for verifiability. Apply the test: “Could I run a study or analysis right now and get a pass/fail answer?” If not, the requirement is incomplete.
Ongoing: Build the traceability connections explicitly. Whether in a graph-based tool or a structured spreadsheet, the connection from population analysis to requirement to verification method must be visible. If it is only in someone’s head, it will not survive a personnel change or a regulatory audit.
The Short Answer
You handle requirements for a system with diverse user populations by treating that diversity as a first-class engineering input, not a UX afterthought. That means formally characterizing each population, developing separate use cases for each, writing usability requirements with population-specific acceptance criteria, deriving safety requirements that account for the full capability range, and maintaining explicit traceability across the entire chain. The tools you use matter: graph-based requirements platforms make this traceability tractable at scale. Document-based tools make it invisible until something goes wrong.