M-SHARP Flight Scheduler

The Overview

M-SHARP works closely with fly communities in the Marines and one of our biggest features in the application is the Flight Scheduler. The Flight Scheduler helps Schedule Writers and Clerks compose a flight schedule on a daily level. There are many moving pieces to sift through as a schedule writer, and my colleague and I were aware of the complexity of this feature. We knew that we had to understand our users’ environment, workflow, and behaviors in order to create an intuitive tool to help them compose a daily flight schedule.

The Process

Observation

To gain a better understanding of what our users actually do, we put ourselves in our users’ shoes and experienced creating a flight schedule. We observed a total of 3 units: KC-130J, FA-18C, and an MV-22 unit. We were able to experience first hand days when the flight schedule was completed and signed off by 2pm and when the schedule was not finalized until 10pm. During these observations, my colleague and I, along with 2 observers, took notes on what our participants were doing, using, who they’re interacting with, and what they’re thinking while they were creating the flight schedule. At the end of the day, we constructed our Experience Map and reviewed it with the participant to capture their thoughts, feelings, what went well, and what went poorly.

UI Flow Models

After our exploratory research, we jumped into UI Flow Models to try and wrap our heads around the different screens needed to create a Flight Schedule. After discussions with the Solution Architect and Lead Developer, the UI Flow Models quickly evolved in complexity to capture the different screens that a user would need to go through.

Sketches

Once the UI Flow Model was approved by the Technical Team, Product Owners, and Business Analysts, we quickly jumped into individual and group sketching with the Solution Architect and Lead Developer to generate potential solutions. Areas of focus included scheduling codes & crew, general layout of adding and editing flight events, the overall interaction of creating, editing, and moving formations, and the summary and validation page.

Wireframes

When we felt like we generated enough sketches, we moved on to wireframes. During the wireframing process, we took our best sketches and put them through multiple iterations. The wireframes focused on displaying the flight events, adding and creating events, and making and breaking flight formations. After many versions with countless discussions in between, the final wireframes focused on a layout that resembled physical copies of a unit’s flight schedule, a new interaction to create and break flight formations, and the ability to sort the events.

Below are wireframes demonstrating how to create and rearrange fight formations.

Prototypes

The prototypes were built in HTML/CSS and jQuery based off finalized wireframes. While the prototypes were being built, there were questions and assumptions around how users name flight events, and how they sort, split, and reorder events. To answer these looming questions, we created two prototypes to test in a usability study.

Prototype 1 focused on setting and creating events from defaults, automatic event numbering, and interacting with the split modal.

Prototype 2 focused on setting your own alphanumeric event names, automatic flight event splitting, and interacting with the sort modal.

Usability Study

Once we had our two prototypes ready, we tested them on a total of twelve individuals that either had experience scheduling flights or entering the flight schedule into the application. Six participants tested Prototype 1 and six participants tested Prototype 2.

Participant List

• 6 Pilots – creates the flight schedule

• 6 Clerks – enters the flight schedule into M-SHARP

Tasks:

Although we sought out to test specific components of the prototypes, we wrote our four tasks so that our users will experience the entire flight scheduler as if they are creating an actual schedule. This allowed us to pinpoint areas in the prototypes that worked well and areas that did not work so well.

Analysis

We documented our findings in a Rainbow Spreadsheet and cross analyzed the results from both prototypes.

Top findings

• Prototype 1

  • 5/6 participants skipped past the TMR multiple times.

  • All participants slowed by full syllabus list.

  • 4/6 participants looked for a way to link events in the edit modal.

  • 4/6 participants added all the crew when adding a new formation. The participants expected the crew to split between each event.

  • 4/6 participants found the split modal easy to use.

  • 2/6 participants found the sort arrows easy to use.

Prototype 2

• 6/6 participants skipped past the TMR at least once.

• 5/6 participants  were slowed by full syllabus list.

• 3/6 participants left the Event Number field blank on the first add.

• 4/6 participants added all the crewmembers on a new formation event expecting the crew to split between the individual events.

• 3/6 participants typed “-1”in the Event Number field when adding a new formation.

• 3/6 participants clicked finalized before validating the schedule.

Implemented Changes

Once we identified the outstanding usability issues, we updated our final prototype for development. Below are the implemented changes.

• Added an Event number field but hard coded “-1”

• Added the TBD checkbox

• Created a more prominent TMR section

• Wrote clearer help text explaining how to add crew

• Filtered out the syllabi

• Kept the sort arrows in the main view

• Kept automatic flight event splitting

• Disabled the finalize button until the user has completed validation