“Necessity is the mother of invention” has to be one of the best proverbs advocating for user centered design.
I need therefore I invent, or in the case of technological invention, I build. This fact is no different regardless of the sector, industry or discipline. But in the case of defense, the user can sometimes become entangled with the threat when innovating. In order to meet and anticipate threats, we are constantly looking for ways to not just transform what exists but also to innovate where nothing like it exists today. But if it doesn’t exist, then who are we building for?
While modernization is a must in defense, before applying user center design we must recognize that today’s warfighters are responding and making decisions based on outdated policies designed to win our last war.
They have never been tested in a war with near-peer advisories. Additionally, these warfighters are trying to implement this policy on technology that was built before the current warfighters were even born. What it all adds up to is the realization that our capabilities are driven out of our ability to respond to the lessons of the past war, not anticipate future challenges.
If we are not careful as we modernize our existing processes, the outcome will be cloud-native, prettier UIs that are still bogged down by outdated policy: a pig rolled in glitter is still a pig.
So how can defense be successful in the race to technological dominance? The answer is simple: defense needs to build innovative, disruptive software that drives policy, not the reverse. This role reversal requires a cultural change within defense and its internal software factories. While defense has embraced bringing the warfighter into the OODA Loop, modernizing software without modernizing policies and organizational structures is equivalent to using computers to manage Blockbuster inventory while your competitor is busy building Netflix.
“Too frequently, major acquisition decisions are framed in terms of replacing one aging platform with another more modern version of the same thing (such as replacing fourth-generation fighters with fifth-generation fighters), instead of asking the more fundamental question of how a given mission (such as achieving air superiority) can be performed most effectively and affordably. Consequently, the discussion narrows to focus on platform replacements rather than considering how to use new technologies and capabilities to solve problems in new ways.” – Michele A. Flournoy Foreign Affairs May/June 2021 “America’s Military Risks Losing Its Edge”
Blindly applying UCD to the software development iteration cycle has left many in defense believing UCD does not work, however utilizing current operators to build a futuristic state is setting everyone up for failure.
What has made Netflix, Amazon, and Google so successful is their ability to reach, get feedback, and empathize with their customers. Current C2 operators conduct themselves within the confines of outdated policies therefore the software they help build will always be confined to the intellectual limits and organizational principles of yesterday. While they do provide important input the Current C2 operators are not the personas of future warfare, they are not fighting the next war.
Defense has not developed a way to empathize with the futuristic warfighters who will be facing multi-domain warfare, therefore UCD has been blamed for not leading to the right outcomes. Instead of obsessing over recreating everything the C2 operator of today does, program managers and software developers in the DoD should focus on developing comprehensive UCD “personas” that combine feedback from current warfighters with projected future needs.
When we say user centered design (UCD), it’s important to differentiate between the discipline and framework. Especially in the context of defense, where the discipline is often outsourced. The UCD framework as defined by ISO 9241-210:2019, is a set of recommended “human-centered” principles and activities across the lifecycle of computer-based interactive systems. The key takeaway here is that it’s a cycle, or series of recurring events that connect dots and inform shared context centered around “someone” not “something”. That someone is your user, or in the case of some innovation where the user does not exist today, your “persona”.
A persona as defined by Yale’s Usability resource is a practical tool that serves as an encapsulation of your understanding of the intended audience. It can include but is not limited to the following data categories:
- Demographics
- Goals
- Behaviors
- Influences
- Pain points
But what makes personas essential is their ability to:
- Aid in design decisions
- Build empathy while encouraging objectivity
- Serve as the basis for user testing (most important)
This is most often what we think of when we hear the term “warfighter”. But it’s much more than depending on the domain and what lean slice of the warfighter journey we’re talking about.
What is the opportunity here? Yes. Joint All-Domain Command and Control (JADC2), the Department of Defense’s (DOD’s) concept to connect sensors from all of the military services into a single network, is an innovative vision. Yes. It not only transforms legacy systems but also informs innovation that will improve our readiness to respond to our adversaries. No. We cannot theoretically accomplish this at one time given the fiscal, resourcing, and organizational constraints in place today. So how can UCD help us to orient around non-discrete personas and iteratively deliver measurable value towards this mission?
To correct this misalignment and successfully leverage the advantages of UCD, defense needs to have an intimate vision of the next warfront. An understanding of a warfront where the United States does not have complete dominance in the air, land, and sea is needed to set the foundation for discussing and considering how new technologies solve defense problems. UCD is not just images and interfaces. It’s a holistic approach to researching, defining, experimenting, and executing based on validated data, not SWAGs or assumptions. The critical path of UCD is distinguishing between the perceived threat or opportunity for innovation and the persona that innovation is intended for. This is where defense most often falters. We see a need, unattached to a user, and we try to boil the ocean of innovation on the shaky foundation of historical perspectives as opposed to current, objective analysis of “an” intended audience.
Defense must leverage UCD personas instead of current multi-domain command and control (MDC2) users to identify the problems, gaps and needs for future C2 operations is needed to escape the current build trap happening across defense. Once current warfighter C2 knowledge and the vision of our next major war have identified opportunities for technology to fill the gaps in a new innovative way, defense can build a persona based on that knowledge. Once defense has linked a capabilities gap to a persona, we can begin to experiment, build, measure, learn, and iterate to a complete JADC2 capability. JADC2 is an all-encompassing futuristic capability that does not exist today, therefore defense needs to break it down into bite-sized pieces.
A bite-sized piece still needs to be a top to bottom slice of cake. In the next-generation war where the United States cannot establish forward Control and Reporting Centers (CRC), send out Airborne Warning and Control System (AWACS) pass the Forward Line of Owned Troops (FLOT), defense needs to bring in pilots that are going to be responsible for building mission plans and have the information the applications they will physically touch, which then informs data architecture, which then informs the platform capabilities, which then informs infrastructure. To do this bite-sized top-to-bottom piece successfully, the defense-first needs to focus on information gathering. The defense should utilize pilot and warfighter combat experience, to conduct an event storm around a single thread scenario. Once the “happy path” is established and agreed upon, then system operators can highlight pain points and capability gaps. The pain points and capability gaps should then be compared against commercial-off-the-shelf / government-off-the-shelf solutions that already exist. After information gathering is completed, defense is now in a position where they can make directional decisions and prioritize the work for their software engineering teams.
The goal is to equip the defense to innovate in a way that is not limited by policy directives and outdated historical war perspectives but instead leverages an objective analysis of the current C2 construct versus what is required to fight and defend the United States against a near-peer adversary through the correct usage of UCD.
