Perspective_

Enterprise systems support operations, so every workflow, approval path, data field, and system dependency influences how work actually gets done across Army units and missions. Over time, these design decisions affect compliance, behavior, and the quality of information leaders rely on to make decisions.

Design, in this context, is not limited to interfaces or usability. It encompasses how systems are architected, how workflows are structured, how data is captured and shared, where and when systems are accessible, and how quickly they can adapt as missions and policies change. When design is treated as a narrow technical concern instead of an operational one, risk is introduced quietly and at scale.

That risk doesn’t show up all at once. It accumulates.

When design undermines command intent

Systems that don’t reflect operational reality introduce friction into daily execution. That friction may look like unnecessary steps, slow approvals, inconsistent access, incomplete data, or platforms that aren’t available when units need them—especially outside of ideal network conditions.

Units do what they have always done: they adapt. They build parallel tracking tools, maintain spreadsheets, rely on informal reporting chains, and develop local workarounds to keep the mission moving. These adaptations solve immediate problems, but they create new ones. Data becomes fragmented. Enterprise visibility degrades. Leaders lose confidence in what they are seeing. Adoption drops, not because Soldiers resist change, but because the system doesn’t support how the force truly operates.

Over time, design gaps become governance gaps. Systems intended to enable standardization and insight become constraints—ball-and-chain technologies that slow execution and require constant manual intervention to function.

Design as a tool for control, predictability, and readiness

When enterprise systems are built in tandem with operators, design becomes a form of operational control. Architecture, workflows, and data structures reinforce standardization without micromanagement by aligning the system to real execution patterns.

Well-designed workflows encode policy, timing, permissions, and accountability directly into system logic. Availability and real-world performance matter as much as functionality—particularly for units operating across varied environments and conditions. Access at the edge is just as important as visibility at headquarters.

Early and continuous engagement with users allows leaders and program teams to see how design choices will play out before systems are fielded at scale. It reveals second- and third-order effects that are difficult to capture in requirements documents alone. A disciplined feedback loop allows systems to evolve quickly and deliberately, updating workflows, data structures, and behavior without disrupting operations.

This is not about making systems easier to like. It is about making them reliable, predictable, and aligned with how the Army actually works—which will almost inevitably make them easier to like.

Soldier-centric design: end users are key to ATIS software success  

The need for reliability certainly extends to training readiness data, which only has value if units can consistently access, understand, and trust the system producing it. In supporting ATIS, the Army’s training information system, LMI and the Army made design decisions for planning, execution, and reporting that were grounded in how training is truly implemented across the force.

That meant accounting for differences across components and echelons, as well as the realities of how units manage training under real constraints. Engagement with Soldiers informed not just interfaces but workflows, data models, permissions, and system behavior. Observing how training was conducted in context revealed where legacy approaches created friction or drove unintended workarounds.

Continuous interaction with users allowed adjustments to be made early—before informal processes hardened and parallel systems emerged. Changes to workflows, data handling, and system behavior were incorporated as part of an ongoing development rhythm, keeping the system aligned with evolving requirements and policy updates.

By treating ATIS as operational infrastructure that evolves with and guides mission priorities—rather than a static application—the system was positioned from day one to not just serve as a tool for training but to support consistent operational readiness.

What this means for Army leaders and program owners

Enterprise software design should be governed with the same seriousness as requirements, policy, and sustainment planning. Leaders should ask not only whether systems meet specifications, but how they will shape behavior, data quality, and decision making over time.

Programs should build with system availability, performance, and adoption as design outcomes—not concerns that are downstream from the stated goal of delivering a system. Early investment in operationally informed, full-stack design reduces rework, shortens timelines, and preserves trust in enterprise systems.

When systems reflect real-world usage, leaders gain predictable execution and reliable visibility. When they don’t, the force absorbs the cost through friction, delay, and diminished confidence and adoption.

Design is part of readiness

Readiness is built and sustained through thousands of small, correct interactions every day. Enterprise systems either support that rhythm or disrupt it. Treating design as an operational imperative—across architecture, workflows, data, and access—enables predictability, trust, and sustained readiness.

This is not just about usability. It is about enabling mission at scale.