While completing my Masters, I was also hired part-time as a designer by the Georgia Tech Research Institute. Don't let the name fool you - GTRI is a separate organization and industry consultant, with projects ranging from military design & development to self-driving car research. For almost two years (with a brief break at Method), I worked 20 hours a week with the Human Systems Engineering Branch whose primary contract was design work for the Navy.
I was the lead designer on mobile work for Naval Air Systems Command. As part of a four person team, I developed interaction models, journey maps, personas, and wireframes, as well as producing UI designs and a style guide deliverable. Our tools were targeted for use with over 4,000 E/A-18G Growler aircraft by 17,000+ users, and our style guide set the stage for future mobile development.
Designing for the military was a humbling experience.
As designers, we often focus on simplifying tasks, increasing efficiency and helping users to achieve their goals. Military design work was no different -- except the stakes were high, the learning curve was steep, and every day there were new, unimaginable obstacles. With minimal access to users and classified information, my team designed tools to support successful mission execution in life threatening environments. No pressure.
Mission planning is a complex art.
Before a mission, crew members determine where they are going, how they will get there, and what they need to bring. This planning involves specialized software that produces a flight plan for the jet. Specifically involved in airborne electronic attack, Growlers listen for and jam hostile detection devices during the mission.
Planning occurs on a ruggedized laptop. To complement existing software, the Navy wanted to make their tools mobile.
Before jumping in, I asked
What's the role of mobile in mission planning?
Military aircraft are expensive and built to last for years. As a result, hardware cannot be updated regularly as functionality and needs evolve. Mobile technology offers the ability to enhance and complement existing hardware, directly impacting efficiency, fuel economy, and safety. My team's first mandate was to "make existing tools mobile-friendly". However, preliminary conversations demonstrated that this did not map to user needs - and making the tools mobile-friendly was not technically feasible.
To balance client expectations and push the design process forward, I led a team evaluation of each phase of mission planning and asked: what data is required at each stage, how is it used, and how might it change throughout the mission. This allowed us to step back and consider the role of mobile tools within the context of a mission (from planning through execution). In addition, we considered hardware limitations and jet functionality, which drove us to better understand technical requirements and limitations.
The potential for mobile tools appeared to be post-planning.
Conversations with subject matter experts helped to identify opportunities for mobile tools post-planning, and focused our efforts on electronic warfare officers who accompany pilots but are not flying the jet. Using these interviews, our blueprint and prior task analyses, we created personas and example journey maps to facilitate further discussions.
With no prior knowledge, I walked the fine line between gathering much needed information and showing my ignorance. I found subtle, comedic design details and parallel experiences helped to bridge the knowledge gap.
We were able to identify user needs and a set of core functionality for a mobile application.
"Replanning" or making significant changing to a mission plan as new information became available was a critical use case. While changes could be made manually to the jet today, mobile tools provided an environment to predict whether changes were safe and optimize route updates. Using a mobile application on Samsung Galaxy Tab S2 tablets, Electronic Warfare Officers would be able to view their route with an interactive map, analyze targets, take notes, and update fuel calculations.
How do we make decisions with limited access to users?
As the project moved into interaction and visual design, it was important that our design decisions were grounded, reasonable, and defensible - especially since we did not have direct access to users or ways to test interactions in context. I worked with our team to focus on three primary goals.
The application should be familiar and easily learnable, relying on recognizable patterns and prior knowledge. User testing and an emphasis on modern, familiar patterns would support this goal.
It should be simple and efficient, requiring minimal effort to do things. Visual heat maps and required clicks would allow us to compare options.
It should promote adoption, by being desirable and minimizing user frustration. We would gauge this via client feedback.
Our design process spanned interaction and visual design, while also considering military design standards.
Software developed for the military is governed by standards to maintain consistency. Color connotations, predefined icons or time formats needed to be considered, for example. A persistent classification status bar (ex. "Unclassified") was also included at the top of the application.
INTERACTION DESIGN (+ Information Architecture)
Based on the user needs and functionality we'd defined, we explored a few variation in the applications structure that handled "replanning" differently. We also defined general interactions and evaluated how the most commonly used tools helped to achieve those goals. Map interactions, for example, were inspired by Google Maps, Waze, and Google Earth (among others). Where interactions did not exist, we created new ones.
Prior style guides were based on Microsoft's Windows 10 style guide. We evaluated the existing style guide, the Windows UWP standards, and Google's Material Design guidance. Based on user feedback and the target hardware, we used Material Design as inspiration, deviating as needed to support novel user needs.
Application Screens + an Interactive Prototype
Our final deliverable included two parts: a style guide of components, sizing, navigation structures, and interaction patterns, as well product design documentation for a future mobile application (and an interactive prototype). For some interactions, such as navigation, it was important for us to demonstrate alternative patterns while making a recommendation for the current application.
Note: While this project was not classified, design assets could not be taken off premises. The screens below were recreated from memory and a few pictures.
Mobile Style Guide 1.0
The contract deliverable was a PDF style guide with detailed, text-based specifications. To promote adoption and improve usability, I illustrated each section of the style guide using elements of the prototype to further demonstrate how the style guide could be used. More complex sections included code that could be used during implementation. By continuing to push past flat documentation, we hoped that future contract deliverables would be digital, code-based style guides that would help to increase the efficiency and quality of future development.