The Challenge

The program already had an established process for defining requirements, evaluating solutions, and acquiring systems.

What was less consistent was how human performance was represented within that process.

Considerations such as:

• user capabilities and limitations

• task demands

• usability

• accessibility

• workload

• human-system interaction

• operational context

could be addressed differently depending on the system, acquisition stage, or documentation involved.

A human-centered need identified early in the process could be difficult to follow through requirements, engineering decisions, and system evaluation.

My Role

I worked at the intersection of Human Factors Engineering, systems engineering, UX, accessibility, and acquisition.

My responsibilities included:

• reviewing existing engineering and acquisition processes

• identifying opportunities to incorporate HFE activities and considerations

• translating human performance needs into requirements and evaluation criteria

• considering how usability and accessibility requirements could be incorporated into acquisition documentation

• developing strategies for improving traceability across the acquisition lifecycle

• advising stakeholders on how HFE could fit within existing engineering processes

• considering both government-off-the-shelf (GOTS) and commercial-off-the-shelf (COTS) systems from a human performance perspective

The work was less about creating a new HFE process and more about integrating HFE into the processes the organization already relied on.

Strategy

01. Understanding the Existing System

I mapped the existing acquisition process from early requirements through engineering, evaluation, and procurement.

This helped identify:

• where user and mission needs entered the process

• where requirements were defined and refined

• where candidate systems were evaluated

• where HFE considerations were already present

• where human performance information could be lost or become difficult to trace

Rather than treating HFE as a separate workstream, I looked for opportunities to connect it to existing engineering activities.

02. Translating Human Needs into Engineering Requirements

One of the central challenges was moving from broad statements about users to information that could actually support engineering and acquisition decisions.

For example, a statement like the system should be easy to use, doesn't provide an engineer or acquisition team with much to work with.

A human factors approach asks:

• Who is performing the task?

• What are they trying to accomplish?

• Under what conditions?

• What demands does the task place on the user?

• What human capabilities or limitations are relevant?

• How could we determine whether a proposed system supports effective performance?

This helped shift the conversation from general usability goals toward requirements that could be more clearly defined, evaluated, and traced.

03. Integrating Accessibility

Accessibility was considered as part of the broader human-system relationship rather than as an isolated compliance activity.

I incorporated Section 508 considerations into the strategy for defining and evaluating system requirements.

This meant considering accessibility earlier in the acquisition process, where it could inform requirements and system evaluation rather than becoming a final-stage check.

The broader principle was:

Compliance tells us what a system must meet. Human Factors Engineering helps us understand how the system needs to support people.

Both perspectives are important when evaluating a system intended for real-world use.

04. Designing for the Acquisition Context

An important constraint was that the program already had established engineering and acquisition practices.

I couldn't simply introduce an idealized HFE process and expect it to work.

The approach needed to be:

Practical
It had to fit existing workflows and documentation.

Traceable
Human factors considerations needed to connect to requirements and evaluation.

Scalable
The approach needed to work across different systems and acquisition contexts.

Actionable
Teams needed to be able to use the information to make decisions.

Outcome

The work gave the program a structured way to bring human-centered considerations into an existing acquisition process.

The resulting strategy provided a clearer path for:

• defining usability and accessibility requirements

• tracing those requirements across acquisition artifacts

• connecting requirements to evaluation methods

• considering human factors earlier in engineering and procurement decisions

Reflection

This project influenced how I think about UX.

In complex systems, the user experience starts long before someone opens an interface. It's shaped by requirements, evaluation criteria, procurement decisions, and the processes organizations use to decide what gets built.

That meant my role wasn't to advocate for users within a product. It was to help create the conditions for their needs to influence the product in the first place.