Case Study: P-8A

The P-8A is a Multi-Mission Maritime Aircraft, performing multiple mission types for the US Navy. Five workstations provide operators with the interfaces required to carry out the different tasks to carry out these missions. It was the responsibility of the Human Engineering group to carry out a User Centered Design type process to define, design, and validate the Operator Machine Interface (OMI) used by the operators.

The following is a working draft, explaining this project. Language will be cleaned up and additional details will be expanded on soon.

My Role

I work as a Human-Systems Engineer - one of, at the peek, four usability engineers and, at the end of my involvement, only myself and usability lead were working on the project. I was responsible to consuming requirements and realizing their

Our Process

We followed a standard user-centered design process. Initial design guidance steered definition and idiation of GUI screens. A solid prototyping phase allowed us to pick high-impact scenarios to test and iterate on before fully passing design descriptions off to the development team.

Design and development process slide, shown during debriefs.

Initial Guidance

As part of a DoD contract we were bound to meet all appropriate guidance put forth by MIL-STD 1472F. Additional design guidance documents included:

  • OMI Style Guide: A living document that defined interactions and patterns. This document would be referenced during new features to maintain consistency.
  • P-3 OMI Design Docs: The predecessor platform design specs, which provided historical context.
  • TOMS SRS Requirements

Design Coordination Teams (DCTs)

Design Coordination Teams (DCTs) were weekly, or more frequent, design meetings which brought together all stackholders to review requires, design proposal wireframes, and review testing data. Teams were made up human engineering, Boeing SMEs, software developers, and test engineers.


  • features were selected for prototyping and user testing
  • Boeing P3 Operators did internal reviews and simulations
  • ASAPs
    • External Reviews
    • Mission simulations
    • Recommended Design Changes
    • Usability Evaluation
    • Workload Measurements

Design Description Document

  • take all the DCT and prototyping information and document the design.
  • rationale for the design, using internal and ASAP metrics included


  • we moved into development
  • worked with developers and made updates as needed
  • all changes made through DCT

Research and Validation

The Result

Some examples of the GUI below; remember, their LnF was defined years before 2005 when we designed them.


  • Need section for the hardware work
  • Clarify error states and need for situational awareness in a high stress situation.