The problem

ARMS is a mission-critical application that the USAF uses to track and manage flight data for about 65,000 aircrew and parachutists — including flying hours, flight and jump schedules, readiness information, and training and evaluation. It consists of seven different functional modules, such as Jumps (jump training records management) and Training (student profile management and accomplishments). About 2,800 aviation resource managers rely on ARMS to perform over two million transactions per week. These users experience multiple pain points because the original system was not built around the reporting and information gathering needs of its users. Our team sought to uncover the core “jobs to be done” by this system to create a more user-centered and efficient tool.

Solution overview

Research setup

I focused on a few key concepts during discovery:

• Who are the core personas, and what are their primary tasks, activities, and touchpoints throughout the process of training, recording, and reporting information?

• What gaps or redundancies exist in the current processes?

• What are the core “jobs to be done” by the system, and how can we meet these needs in a more efficient and user-centered way?

Over the course of two months, I conducted a series of contextual inquiry and interviews with 20 users of the system, gathered documents and artifacts from users, identified key personas and roles, mapped out the user journey, and then identified the chief jobs to be done and design opportunities for the redesigned system.

User roles and personas

Key to understanding the workflows and identifying core jobs to be done by the system was understanding the roles of the different users who interacted with the system. To this end, I sketched out rough proto-personas to identify the primary goals and tasks of the different users of the system.

Journey mapping

The initial journey map defined key user roles and personas, tasks, channels, and pain points in the process.

Jobs to be done analysis

After examining the tasks and processes by the users of the system, I discovered that users ultimately relied on the system to determine badge and course eligibility and determine unit-wide mission readiness, but the data generated by the reports was not optimized for these use cases and created inefficiencies and errors in the process.

To ensure that the re-designed system met these larger objectives, I first identified the core “jobs to be done” by the system, and then determined what information was needed at each stage so that we could surface it at the right time in the application.

Outcome

We focused design efforts around making reports more actionable and useful. This automated key report outputs and eliminated the need for users to manually count items on a report and cross check them against requirements.