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.
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.
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.
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.
Version 2 - Daily view and editing flow
Renumber and reordering flight events
Below are wireframes demonstrating how to create and rearrange fight formations.
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.
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.
6 Pilots – creates the flight schedule
6 Clerks – enters the flight schedule into M-SHARP
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.
We documented our findings in a Rainbow Spreadsheet and cross analyzed the results from both prototypes.
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.
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.
Rainbow Spreadsheet Legend
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