NATO MSS

Scheduling Module : UX Design

A couple years ago, while at Adobe Consulting, I've had the chance of working on a pretty cool app, NATO's Mission Support System for AWACS Aircrafts.
In this case study, I'll present some of the thinking that went behind the design of the app's "scheduling" module.

"Mission Scheduling is the process of creating and maintaining a record of planned
missions within an operational calendar, and ensuring the availability of aircraft, crew,
permissions and other resources for the successful execution of those missions."

User research: needs and flows

Obviously, planning AWACS missions is not trivial. Definitely not a job we were very familiar with either... So we started the project doing what any UCD practitioner would do: user research.
After a couple weeks of workshops and interviews, we established 3 user groups were going to use the module:
  • Long Range schedulers, who handle the scheduling of missions from three months in ad-
    vance up to one month before their execution.
  • Short Range schedulers, who are responsible for filliing up all the details, up to the day before the mission.
  • Finally, the Command Post guys, who take over on the day of the mission itself, to ensure everything goes according to the plan.

UI Framework

Given that those 3 groups look at the same data, but at different granularity levels, I came up with the idea of organizing the UI's main work area across 3 sliding panels, each offering a different level of information:
A. Grid view, for long range scheduling and resource allocation.
B. Timeline view, to visually specify mission timing details. You know, details like making sure the planes don't all take off or land at the same time on the same track :)
C. Map view, for geographic information, such as orbits, routes, etc.

Interactions

Given that those panels pretty much present the same data at different scales and under different forms, the benefits of that configuration really come up when you start thinking about all the interactions that can be thought of, within, and between the different panels.
Given the complexity of the data, the wireframes' fidelity quickly rose, details were added, and the user interface progressively matured towards its final form.
Unfortunately, and for various reasons, those wireframes never received the visual design love they deserved, and the module was never implemented. That being said, and despite the fact that it's a 4 years old project, I still think that module was pretty darn cool, what do you think?

-

Jerome Cordiez [@jeromecordiez]
http://www.thisislovely.com