Defense programs are starting to talk about human-centered design, but the decisions that matter most still get made before a designer or an operator is anywhere near the room. The acquisition reform now underway uses design's vocabulary. What it means by those words is being decided right now.
The Acquisition Transformation Strategy asks for iteration and outcomes. Whether that produces systems operators want to use depends on what "iterative" gets defined to mean once the strategy hits contract language.
TL;DR
The DoD’s acquisition reform language increasingly mirrors core design principles.
Definitions of “iterative” and “outcomes-based” are being operationalized right now.
Many defense programs still define requirements before validating warfighter input.
Research is frequently approached as training demonstration rather than qualitative inquiry.
Design competency is largely absent from acquisition workforce transformation efforts.
The opportunity for design to influence acquisition policy has never be more open than it is now.
The reform already speaks design
In November the Department published its Acquisition Transformation Strategy. It calls for "iterative approaches." It frames success as "rewarding outcomes over process." It describes a culture built around speed, innovation, and accountability, which, candidly, hasn't described much of my experience on defense programs.
For eight years I've been in rooms with program managers, contracting officers, engineering teams, primes, startups, and DoD stakeholders, and the argument that operators should shape what gets built has never been an easy one to land. So reading versions of it reflected back in official policy language was strange. The reform uses design's words. Whether the words become practice depends on who's in the room when they get defined.
Policy language and implementation aren't the same thing, and "outcomes over process" is a good example of how far apart they can drift. A contracting officer hears flexibility inside a familiar procurement structure. A designer hears something else. A process where requirements evolve through observation, prototyping, and testing with the people who'll use the capability.
"Iterative" splits the same way. Inside defense acquisition, iteration has usually meant successive engineering builds within a fixed requirements envelope, each adding function. In design practice, iteration means the requirements themselves stay open to change as understanding deepens through time with operators. Both readings can live under the same word and lead to very different systems.
The Executive Order that set this in motion last April was explicit about what the government wants to change. Procurement that moves too slowly, needs too many approvals, and can't absorb commercial technology at operational speed. The Acquisition Transformation Strategy turns that intent into a plan, and branch-level implementation guidance is already following. At nearly every layer, design's language is present. My read is that the reform is framing iteration as engineering process improvement, and the methods that decide what a better outcome is in the first place are sitting outside the frame.
The inverted process
The most persistent pattern I've run into in defense design is a product development process that runs backwards.
Programs define requirements before any real design work begins. Those requirements tend to come from legacy systems, prior doctrine, or engineering and production assumptions rather than from current warfighter needs. By the time a designer shows up, the problem has been named and the solution heavily constrained. Design becomes a production layer.
That happens regardless of how design-mature the program leaders, contractors, or consultants are, because the procurement structure enforces it. When a program requires finalized requirements before research and design strategy can happen, you can't improve the requirements with operator insight. The structure doesn't let the insight reach them before they're locked. The process becomes a technical solution looking for a human problem, and I've watched it happen repeatedly.
On one program our team got unusual latitude to do real research with active soldiers early enough to shape the product. We built high-fidelity prototypes, watched operators run realistic mission tasks, and iterated on what we saw. Those sessions changed our understanding of how the product should work and how it should sit inside an operational workflow. Several assumptions baked into the written requirements didn't match how operators wanted to interact with the platform. Workflows that looked logical on a whiteboard turned cumbersome, or plain wrong, once they were in soldiers' hands. To their credit, several DoD stakeholders pushed us to keep following what the operators were responding to. It was one of the most exciting stretches of defense work I've had, because human-centered design was working inside the system.
Then we hit the hard stop. The requirements still had to be met, and I was told directly that changing them would take the signature of a four-star general and an act of Congress.
That moment changed how I think about defense product development. If design enters after the requirements are final, most of the consequential decisions have already been made.
The current reform opens real space to challenge that inversion. The mechanisms that decide whether it happens, contract structures, evaluation criteria, workforce competencies, implementation guidance, are being written now. Historically those conversations have happened without design practitioners in them. There's a gap between the intent of the reform and the expertise that would turn the intent into practice, and it's a gap worth naming while it's still open.
Questions versus answers
The most common pattern I see in defense user engagement is a presentation and training mindset where an inquiry mindset is needed.
Program teams demonstrate the system, explain the workflow, teach operators how it works, then collect generic feedback afterward. That satisfies the contractual requirement for user engagement. It leaves most of the usability insight on the table, because teaching someone to use a system is a different activity from watching how they think, hesitate, adapt, struggle, or fail inside it.
Operators are also surprisingly hard research participants without the right methods. Highly trained warfighters are conditioned to project competence and adaptability. Many are used to working around friction or accepting cumbersome workflows as normal. Shown a prototype, the response is usually some version of "Yeah, this works. I could use this."
Getting beneath that takes actual research practice. Contextual inquiry. Observation without explanation. Iterative testing. Knowing that what people say and what they struggle with aren't always the same thing. Some of the richest research I've done in defense came from deliberately creating conditions where things could get confusing, frustrating, or fail in controlled ways. Those moments revealed more about how operators actually think than a polished demonstration ever did.
I think often about something an Army forward observer with two decades of service said to me during an interview. "The things we're given are built by a bunch of nerds wearing khakis and polo shirts, sitting in conference rooms with no idea what we actually need."
That's stayed with me because it captures the tension so exactly. Defense organizations are full of intelligent, experienced people working hard problems. There's just an enormous distance between the rooms where systems are conceived and the ground where they're used, and the further upstream a decision gets made without operator engagement, the more likely the system is to end up capability-centered.
What the workforce plan leaves out
The reform correctly identifies a workforce problem. The Department needs people who can operate inside faster, more iterative, commercially integrated acquisition. The workforce conversation so far focuses on modernizing contracting, agile methods, and shorter delivery timelines. Those investments are necessary. On their own they produce a faster version of the same capability-centered model.
What the plan doesn't name is design competency itself. Research methods that engage operators before requirements are final. Prototyping that makes an idea testable before engineering commits. Validation that measures operator behavior rather than specification compliance. These aren't adjacent skills. They're how user-defined outcomes get produced.
I've led programs where contextual inquiry changed the fundamentals of a design through nothing more than a simple prototype in front of operators. In one case the users made it immediately clear that the most important information was on the wrong screen. We redesigned. That insight wasn't going to come from a requirements document. It took someone who knew how to ask a non-leading question, watch, and turn what they saw into design direction.
There's evidence for this inside the Department already. When DARPA's program managers wrote up their retrospective on the Explainable AI program, they noted that the most effective research teams were the cross-disciplinary ones, computer science working alongside human-computer interaction, and that user study design turned out to be much harder than the technical work. That finding came from a DARPA program, and it hasn't yet made its way into the acquisition workforce conversation.
What gets defined next
Defense acquisition has been reformed before. Each cycle improved specific things and was eventually absorbed into the institution around it. This time feels different to me, and I want to be careful about why.
The pressure is coming from several directions at once. Executive leadership, the strategy itself, branch-level implementation, commercial technology, and a generation of warfighters who say out loud that they don't like their tools. The definitions set over the next year, what "iterative" means in process, what "user outcomes" means in evaluation criteria, whether human-centered design methods count as a formal acquisition competency, will likely harden into contracting structures and training curricula for years.
The opportunity to shape those definitions may not be this open again for a while. There's an honest complication inside that, though. Shaping them assumes there are designers prepared to do it, and in eight years in this space the number of designers pursuing defense work has felt remarkably small. The work doesn't lack meaning. If anything the opposite. The design community has just historically gravitated toward other industries, other products, and other ideas about where design effort creates value. Whether that changes as the door opens is something I don't know yet.
What I do know is that for the first time in my career I can point to official policy language that reflects arguments practitioners have been making for years. The words are there. What they'll come to mean is the part that's still being written, and I'm watching that more closely than anything else in the reform.
Further Reading
Modernizing Defense Acquisitions and Spurring Innovation in the Defense Industrial Base — The White House
Defense Department Acquisition Transformation Strategy — USNI News
The Army’s 2025 Acquisition Reforms — U.S. Army Acquisition Support Center
Talent Development to Unleash the DoD Acquisition Workforce — DefenseScoop
Defense Acquisition Reform: Persistent Challenges — U.S. GAO
UX Research Methods Overview — Nielsen Norman Group