Bottom-line up-front:
- The Stinger air defense system met performance goals in controlled developmental testing environments, but failed when real soldiers used it in operational test.
- Human factors and usability issues cut operational effectiveness in half and delayed fielding the solution to soldiers who needed it.
- Effective systems engineering requires designing for and validating the solution with real users in realistic conditions, not just testing the technology itself.
- System performance requirements must include integrated human-system performance reflecting real-world operational demands.
The FIM-92 Stinger missile system is widely recognized as a technological success. It is a lightweight, shoulder-fired, heat-seeking missile that can take down air threats with deadly precision. It has been in service for decades, but it almost did not make it out of testing.
Developmental history
By the late 1940s and early 1950s, the nature of air threats on the battlefield was changing. During World War II, most aircraft threats came from high-altitude bombers or fast-moving fighters, which were countered by large radar-guided anti-aircraft artillery or interceptors. But as military aviation evolved, a new category of threat emerged: low-flying, close air support aircraft and helicopters that could maneuver below radar coverage and directly attack frontline ground forces. These aircraft were difficult to detect and even harder to engage using traditional anti-aircraft systems, which were too slow to deploy and too cumbersome to follow fast, evasive targets at low altitude.
Ground troops needed a way to quickly and independently defend themselves against air threats, without relying on vehicle-mounted systems or centralized air defense networks. The goal was to give small units the ability to engage enemy aircraft in a responsive, mobile, and cost-effective way.
This led to the concept of the Man-Portable Air Defense System (MANPADS): small and light enough for small units to carry, fast enough to set up and fire quickly when incoming threats are detected, and smart enough to guide itself once launched. The U.S. first developed FIM-43 Redeye in the late 1950s. Redeye would home in on the infrared signature of an aircraft’s engine exhaust and guide itself to impact.
While a technological breakthrough, it had serious battlefield limitations. It tracked the target’s engine heat, meaning it was only effective after the threat had passed over and had the opportunity to attack, with some referring to it as a “revenge weapon” rather than a true defensive capability. It was susceptible to countermeasures like flares, required ideal weather and lighting conditions, and was difficult to keep a steady aim on a maneuvering target especially under battlefield stress. Still, Redeye proved the feasibility and value of equipping infantry with lightweight air defense capabilities. The shortcomings of Redeye directly informed the next generation of MANPADS, including the far more capable FIM-92 Stinger.
The goal for Stinger was not just better accuracy, but greater ease of use, improved tracking, and true fire-and-forget capability. It represented a leap forward in guidance technology and portability. Significant improvements were made in the seeker and guidance technology, leveraging new computer-based modeling and simulation capabilities across the entire engineering lifecycle; an estimated $100M was saved by using computer simulation to reduce the number of test launches required1. The result was a highly-capable solution that could target an aircraft from any direction and was resistant to countermeasures, vastly expanding the engagement envelope and allowing soldiers to respond much more flexibly to air threats.
Yet it failed in testing.
The trap of technology-centric design
Stinger had a clear Key Performance Parameter (KPP): 60% probability of kill (PK). It easily met that requirement in developmental test. But when handed to soldiers in operational test environments it performed far worse, achieving a PK of only 30%. Instead of enhancing battlefield defense, such a poorly performing system would threaten it.
This is a common pattern: emphasis was placed on technology development, overlooking the importance of usability and real-world operational conditions that affect performance. The system performs well in controlled environments with expert users and perfect conditions, but fails in more realistic tests.
The Army conducted a contemporary lessons learned analysis, which found these shortcomings in the development process:
- Incomplete or poorly specified requirements
- Inadequate task analysis to define what users actually needed to do
- Unnecessarily complex controls and procedures
- A lack of attention to the physical, cognitive, and operational characteristics of the intended user population
Outcome
The most immediate and impactful result of this issue was a delay in fielding this system, leaving soldiers with the existing, inadequate air defense capabilities while the shortcomings in Stinger were addressed. Of course, that also added cost to the development.
Another impact is the lost opportunity to deliver a great design up front; instead, the program was forced into reactive, band-aid fixes to improve the system interfaces and add additional training burden on how to use the system most effectively. Training is a common but poor solution to design shortcomings: it is expensive, it atrophies over time, and it puts the burden on the human to perform better. This is especially problematic in the most demanding and high-risk situations when errors are most likely and most consequential.
What this means for system designers
Stinger is now an incredibly successful weapon system that has been upgraded many times over the years. But it never would have gotten that opportunity if it had been cancelled for cost and schedule slips, as often happens with modern weapons systems when they encounter engineering challenges.
The Stinger case is decades old, but the lesson is timeless. Systems must be designed and tested with their intended users in mind—not just technically skilled testers, but actual end users, with their real-world capabilities, limitations, and stressors. That means:
- KPPs must reflect real use conditions: A 60% success rate in testing means little if those tests do not mirror the operational environment. Requirements must be explicit and be interpreted to reflect mission-relevant conditions.
- Human operators are part of the system: If the system boundary excludes direct system users, the result may be great technology that will not rise to the demands of the mission.
- Validation testing with representative users is essential: System performance cannot be fully understood and quantified until it is evaluated in the hands of actual users in realistic operational conditions. Test early and iteratively.
- Training cannot compensate for poor design: If users routinely fail in realistic conditions, that is a sign the interface, workflow, or cognitive demand are misaligned, not that they just need more reps. Design interfaces and controls that match user expectations and abilities
Closing Thoughts
Boundaries are essential for managing scope in complex engineering projects, but choosing where to draw them is critical. Excluding human users from the system boundary is a costly mistake, as human performance is a critical component of system performance.
Human factors engineering ensures that systems are designed to function effectively in the hands of those who depend on them. The FIM-92 Stinger met its technical requirements in development but failed in operational use. The cost of that gap is measured in missed targets, failed missions, and real-world consequences.
Sources
Lyons, J. W., Long, D., & Chait, R. (2006). Critical technology events in the development of the Stinger and Javelin missile systems: Project Hindsight revisited. Center for Technology and National Security Policy, National Defense University. Retrieved from https://ndupress.ndu.edu/Portals/68/Documents/DefenseTechnologyPapers/DTP-033.pdf
Promisel, D. M., Hartel, C. R., Kaplan, J. D., Marcus, A., & Whittenburg, J. A. (1985). Reverse engineering: Human factors, manpower, personnel, and training in the weapon system acquisition process. U.S. Army Research Institute for the Behavioral and Social Sciences. Retrieved from https://ndupress.ndu.edu/Portals/68/Documents/DefenseTechnologyPapers/DTP-033.pdf
Footnotes:
- Hardware-in-the-loop simulation (HWIL) was also used to validate these technologies; I worked in the lab where this work had been conducted and remnants of it including control panels and building-mounted test rigs were still present.