Why is being user-centered such a challenge in the DoD?
U.S. Army photo by Pfc. Brooke Davis, Operations Group, National Training Center
I first asked myself this question while working Human Systems Integration (HSI) as a Systems Engineer for a large defense contractor. As I explored this difficult topic, I realized I might have more luck driving change from the other side of the table. So, I made my way to a FFRDC to work more directly with the Government and help shape programs and projects to be more user centered.
Six years later, I’m happy to report that Cyber is the new thorn in everyone’s side! Jokes aside, user-centered design has not yet achieved its full potential. While I’ve seen more programs understand and embrace user-centered design than before, it is still frustrating that so little has changed in the larger environment. Every program I join struggles to bring human-centered practices to bear.
The challenges I most often see: missing or cryptic SOW statements, outdated / incorrect MIL-STDs, insufficient expertise / staff planning, and no or poor requirements. In the worst cases, only a handful of people on the program understand the user’s actual mission, and even fewer have ever spoken with users.
There’s a lot we can learn from commercial industry on this point. Commercial products that succeed tend to have a strong customer-focused value proposition – in DoD terms, they help users accomplish a mission. Delivering a successful product or service requires knowing your customers, the jobs they need to get done, and the associated pain points and gains. That’s true no matter the domain or industry — involvement with users should not be limited to generating requirements. It should not be treated as a contractual checkbox to fulfill, nor as the sole responsibility of an expert or team. Instead, it should be early, frequent, and meaningful. Being user-centric is how the commercial world works because it has an impact on their bottom line. We see this in manufacturing and software alike, where user engagement is a core principle of commercial practices like agile and Lean.
And yes, I understand that traditional DoD acquisition approaches can be limiting. However, it is possible to make designing for and engaging with users a part of how we work. Start by considering these questions:
- If we’re so risk adverse and cost conscious, why aren’t we be making user-centered design a non-negotiable part of our approach?
- Why do we spend SO MUCH TIME writing limiting and insufficient requirements? What might a Minimum Viable Product (MVP) requirements document look like for your program?
- As we read proposals for design and development, shouldn’t we be looking for appropriate expertise and design process-related words like research, prototype, and iterations?
- Why don’t we kick off programs with mandatory visits to engage with users?
- Why don’t we leverage user ingenuity and “field fixes” as valid sources for upgrading systems?
- Why can’t we have multiple user assessments during discovery and design? Why wait until test?
- Why aren’t we inviting or incentivizing or making opportunities for users to be part of engineering teams (e.g., Kessel Run) or directly tapped for ideas and solutions (e.g., AFWERX)?
- In a nutshell, why do we keep doing business this way?
If you haven’t heard, there’s some good news on this front. The AF recently appointed a Chief User Experience Officer. I’m excited to see what that will mean for the Air Force. As an Army Brat, I wish we had named one first. (Call me Army – I want to help Beat Navy!) I’m still holding out hope that the other services will follow suit and, more importantly, that the DoD taking a Warfighter-centric approach to research, engineering, design, acquisition, and sustainment shifts from being novel to our new normal.