How to Conduct a Credible Human Readiness Level Assessment

Tristan Plank

Director of Product Design | Human Factors Practitioner 

A Marine launches a Neros Archer first-person-view attack drone from a vessel off the coast of Okinawa, Japan

At first glance, assessing a Human Readiness Level (HRL) might seem straightforward. Review the system, find the level that best matches its current state, and document the result. But in our work with clients, we've found that mapping the system’s current state to the closest HRL description is the easy part. The harder question is what evidence is available to support the selected level.

Evidence is gathered from an understanding of the system and the intended users: What do we know about the people who will operate, maintain, and support the system? Which tasks and operating conditions have been evaluated? Where are we still relying on assumptions or informal feedback? A useful HRL assessment brings the answers to these questions together to help a program understand not just where its human readiness stands today, but what work will need to happen as the system matures.

A graphic representing the steps of an HRL assessment: define scope, gather evidence, identify gaps, make the judgment, plan path forward

The HRL standard defines the criteria, not a universal process

If you are new to human readiness levels and the HRL scale, we have previously written about Understanding Human Readiness Levels. ANSI/HFES 400-2021 defines the HRL scale and includes level-specific guidance, exit criteria, supporting questions, and application examples. However, despite the ASI/HFES guidance and the adoption of the levels by the Department of Defense in 2025, there is no universal prescribed process for conducting an assessment. 

Research on applying the standard recommends that organizations should rely on their existing human systems integration (HSI), human factors, and systems engineering processes. But if a team doesn’t have an established HSI process or if a program has never conducted this type of assessment, teams may be uncertain how to bring the relevant evidence together to support the readiness claims.

The advice below offers a practical way to organize and approach an HRL assessment. Note that this guidance is not intended to reflect any official government or organizational approach and you should follow any established organizational processes for conducting and documenting your HRL assessment.

Define the human-system context and scope

Begin an assessment by clearly defining scope of the readiness rating. The scope definition should include the system or technology, configuration(s), development baseline, and intended use. Then define the intended end user roles, their known or assumed expertise, and contexts of use. For example:

  • Define operators, maintainers, support personnel, and other users

  • Define the expertise and training that will be required per role

  • Identify the mission types, tasks, workflows, and contingency scenarios 

  • Identify and flesh out the environments where the system will be used

  • Define the software versions and their associated interfaces and controls

  • Identify and define the levels of automation and human-automation interactions needed for each task

Without a clearly defined scope, those reviewing an assessment may not understand what the rating actually represents.

Make requirements and assumptions visible

Once scope has been defined, teams should ensure the scope can be tied back to requirements. Trace human factors requirements to the mission, tasks, hazards, user needs, and system performance objectives they support. If your program hasn’t created such requirements for the system, consider reviewing our guidance for creating human factors requirements.  

Also, where relevant, capture assumptions that have not been formally translated into requirements. For example, teams may assume maintainers can complete a task within a certain time limit or training will compensate for interface complexity. A concept of operations (CONOPS) may assert one operator can supervise several assets. Automation may be assigned decision authority without a clear account of when a user must intervene. These types of assumptions carry inherent, unstated requirements that will likely require validation. Keep requirements, assumptions, targets, and demonstrated results separate and distinct.

Gather the evidence and understand its limits

Your program may have already completed several useful analyses and evaluations. The challenge is showing what each one tells you about human performance and the HRL claim.

Depending on the human readiness level and system, evidence might include user research, task analysis, workload or staffing analysis, function-allocation studies, models, trade studies, prototypes, formative usability evaluations, training evaluations, human-in-the-loop (HITL) tests, field observations, or performance data. Published HRL examples demonstrate how the evidence becomes more representative as the design matures: analytical work and early task evaluations mature into realistic mission simulations, testing with representative users in operational conditions, and monitoring after fielding.

Gathering evidence is only part of the process. The team also needs to consider what each study or analysis actually demonstrates… and what it doesn't. A single user completing a usability test does not establish a readiness level. Consider what was tested, with which users, for which tasks and system configuration, and under what conditions. In addition to supporting any performance claims, the evidence trail should also show how findings flowed back to requirements, design, risks, and plans for later evaluations.

A test can produce a promising result yet still leave important questions unanswered. Looking for the unanswered questions and gaps in your evaluations helps keep the HRL claim connected to the limits of the evidence. 

Identify gaps in your existing evidence by asking questions like:

  • Were all known user populations and roles represented?

  • Do scenarios include high workload, degraded communications, and emergency or other off-nominal conditions?

  • Are staffing and training assumptions supported by analysis or based on expert/SME judgment?

  • Have critical human performance requirements been verified?

  • Has the interface, automation behavior, and system configuration changed since the evidence was gathered?

  • Have all necessary maintenance and support tasks been considered?

Suppose an evaluation shows manageable operator workload for nominal missions but did not test performance under degraded communications or an automation failure. The data is still useful but does not support a broad claim across the full operational context. The absence of these other scenarios doesn't make the results less useful, it simply means the team needs to be clear about what the evidence has and has not demonstrated. 

The gaps can provide more decision value than the HRL rating itself. Gaps can reveal what the program does not yet know and areas where risk is likely to surface later.

Determine and document the readiness level

After the context, requirements, evidence, and gaps are visible, the team should be ready to assess the readiness level. Use the definitions, exit criteria, and supporting questions in the applicable HRL standard along with any organization-specific guidance.

HSI and human factors practitioners should be able to judge which questions are relevant and whether the evidence answers them satisfactorily. For a critical review, include the disciplines needed to verify performance claims, such as HSI and human factors, systems engineering, test and evaluation, operations, training, maintainability, safety, and program leadership. The assessed level should reflect the maturity demonstrated, not the level the schedule says the program should have reached.

Reviewers should be able to understand how the team reached its conclusion without making assumptions. At minimum, capture:

  • The assessed HRL and exact scope or configuration

  • The criteria applied and references to supporting evidence

  • Assumptions, gaps, risks, and evidence limitations

  • Conditions that must be met before claiming the next level

  • Any disagreements among stakeholders about evidence or system performance claims

The rationale can reference existing requirements, analyses, test reports, risk databases, issue trackers, and other artifacts. What matters is the traceability between the assessed HRL rating and the evidence that was gathered.

Translate gaps into a maturation plan

A complete assessment results in more than just a number; the credible assessment can and should help a team decide what to do next. Gaps identified during the assessment can be turned into a path forward with actions, owners, decision points, and evidence needed for closing the gap in the future.

The path forward might include additional task analysis, refined human factors requirements, interface redesigns or updates, a staffing or workload study, a training analysis, or a more representative HITL evaluation. Prioritize gaps by their effect on mission performance, safety, cost, schedule, and future design freedom. This is where the assessment becomes especially useful: providing the team with a clearer picture of what needs to happen next.

Reassess when the system or evidence changes

Human readiness assessment is an ongoing process. Changes to CONOPS or underlying manpower assumptions can alter task allocation. An interface update can invalidate earlier usability findings. Automation advancements may shift workload, decision authority, staffing, or training needs. Updated prototypes and tests may close old gaps while exposing new ones.

Revisit the assessment at key technical milestones or when significant program decisions result in changes to requirements. When conducting follow-on assessments, maintain the same rigor and evaluation criteria for consistency and traceability. Even when a system is fielded, HRL 9 includes continued monitoring of human-system performance, reinforcing that human readiness is a system lifecycle activity, not a single deliverable.

What a credible assessment should leave behind

A completed HRL assessment should give a program more than a readiness rating: it should establish what the team knows about human performance, where important questions remain unanswered, and what work is needed to move forward.

We recently used HRLs as part of an HSI effort to help identify human readiness gaps alongside broader system development.  Applications like this demonstrate the real value of the framework as a tool to help teams look beyond a single readiness number and have more productive conversations about the people who will ultimately operate, maintain, and support the system.

HF Designworks supports Human Systems Integration, Human Factors Engineering, workload and human-performance assessment, and human-in-the-loop evaluation. If your program is preparing for an HRL assessment or needs help understanding what comes next, contact us.


Blog image credit United States DoW, Marine Corps Lance Cpl. Oscar Ocampo

Sources and further reading

Human Factors and Ergonomics Society. ANSI/HFES 400-2021: Human Readiness Level Scale in the System Development Process.

Handley, H. A. H. (2025). Human System Integration Framework (HSIF) Activities to Support Human Readiness Levels (HRLs). Ergonomics in Design, 33(1), 44–51.

Steelman, K. S., & Handley, H. (2022). A Primer on the Human Readiness Level Scale (ANSI/HFES 400-2021). Advances in Human Factors of Transportation, 60, 184–191.

See, J. E. (2021). Human Readiness Levels Explained. Ergonomics in Design, 29(4), 5–10.

Office of the Under Secretary of Defense for Research and Engineering. (2025). DoD Adopts Standard for Human Readiness Levels.

NASA. (2021). Human Systems Integration Handbook. NASA/SP-20210010952.

Keep Reading

// SAY HELLO

Contact

HF Designworks, Inc.

PO Box 19911
Boulder, CO 80308

(720) 362-7066

Protocol3 Logo

© 2026 HF Designworks

Protocol3 Logo

© 2026 HF Designworks

Protocol3 Logo

© 2026 HF Designworks