IEEE Spectrum May 2026 issue
Why the unmeasured half of every system is the one using it
I’ve been a member of IEEE for a long time, to the point where I’m now a senior member. I still get their Spectrum Magazine, which highlights the latest in engineering technology. I even wrote an article several years back on an IEEE article dealing with Weapons Acquisition [1]. The cover of the latest issue (May 2026) shows a man in an exoskeleton suit. My mind immediately went to an exercise I do for my Principles in Systems Engineering class. I ask the students to conduct an Architectural analysis of alternatives, prompting them to come up with various solutions to get six troops across a bunch of mountains from point A to point B within a certain amount of time. During the brainstorm, they come up with the standard solutions such as helicopters, hover jets, and even a fast truck. As the exercise continues, a student will sometimes come up with innovative ideas, such as Elon Musk’s boring machine or even soldiers outfitted with exoskeleton suits to run across the treacherous terrain.
So when I opened this IEEE article [2], I expected to see a soldier explaining how this exoskeleton suit helps him be a better soldier. Instead, I found an article that is a perfect example of the importance of stakeholder elicitation and input for perfecting a system.
The man on that cover is Robert Woo, and he isn’t a soldier but an architect. Or he was one, until a December morning in 2007 when a crane sling thirty floors above a Manhattan construction site came crashing down onto the trailer where he was working. He barely survived and became paralyzed from the chest down. What earns his story the cover of the IEEE magazine is not the accident but the fifteen years that followed. Woo became a test pilot, early adopter, and clinical-trial subject for nearly every serious exoskeleton built anywhere in the world, and along the way, he did something most users never get the chance to do. He helped shape the very machines he depended on, working from the inside out.
Keep in mind, most companies building these suits are not short on talent. Eliza Strickland’s feature [2] carefully notes that one of these firms had experienced and competent engineers under its roof. And yet the former CEO of Ekso Bionics conceded that engineers left to their own instincts tend to overlook things, and that it took a user to remind them what the suit had to be. It had to be “something that people actually like to wear.” That one sentence is the INCOSE Stakeholder Needs and Requirements Definition process [3] compressed into half a dozen words. You can derive functional requirements all day from a whiteboard. You cannot derive “people have to want to wear this” from anywhere except a person who actually has to wear it.
Woo was that person, and he was relentless about it. He hated the clunky backpack that carried the battery, so one afternoon he cut the straps off an old pack, rebuilt it into a compact hip pouch, photographed his handiwork, and mailed it off. The next model shipped with a fanny pack. He felt an early suit’s hip motors running hot and shutting the thing down after half an hour, and offered to drill his own heat sink; a year later, the manufacturer quietly added cooling around those very motors. Most telling of all, he reported that a strap was abrading his shin. For most of us, a strap rub is nothing. For a man who cannot feel a wound forming on his own leg, it is a real hazard, and it is exactly the sort of requirement no engineer writes down until the right stakeholder hands it to him. The Handbook lists users among the stakeholders you are obligated to identify and elicit from [3]. It is one thing to drop that word into a process diagram and quite another to put a man inside the machine for fifteen years and actually listen to what he reports back.
My favorite stretch of the article is about cooking, because it is the cleanest case I have seen of an operational concept colliding with operational reality. Woo assumed the kitchen would be the killer application. He pictured himself at the stove, looking down into his pots, gliding between counter and sink. The reality was a grind. He had to gather every ingredient in a wheelchair first, transfer into an eighty-kilogram robot, inch up to the counter, and stop at precisely the right instant, and he fell once when he misjudged it and went over backward into the cabinetry. The OpsCon the Handbook asks us to develop is supposed to capture how the system is really used, in its real environment, by its real users [3]. Woo’s imagined OpsCon and his lived OpsCon were two different documents, and the only way anyone discovered the gap was by letting him try to make dinner. I tell my students constantly that the best way to validate a system is to run it through its OpsCon with a user within its environment. Woo is living proof of this truism.
The Wandercraft CEO framed the deeper problem better than I could. An exoskeleton, he observed, is two systems of roughly equal importance bolted together. The robot half is fully quantified and measured. The human half is not. You do not really know what the person is doing or how they are moving inside the device. That unmeasured human half is precisely what stakeholder elicitation exists to illuminate. It is also why Woo’s architect’s eye proved so valuable. The Handbook warns that every stakeholder frames his input through the biases of his own role and history [4], and Woo had spent a career understanding structures from the inside and hunting for their weak points. The engineers saw a control problem. The architect saw a structure and went looking for the cracks. Years ago, he told these teams to put motors in the ankles so the suit could balance itself and free the user’s hands. They told him they were not about to rebuild their platform. The self-balancing suits he now demonstrates do exactly that. The right stakeholder does not merely validate the requirements you already have. Once in a while, he hands you the architecture you will eventually wish you had started with.
So I will leave my fellow Systems Engineers with the question I have been thinking about since I set the magazine down. Every program has a Robert Woo somewhere, the one user who actually lives inside the system you are building. Have you put him in the room, let him drill holes in your prototype, and listened to what came back? Or are you still writing requirements from the comfortable side of the plate-glass window, where nothing you write has to survive contact with a real user?
Optional Reader Resource
References
[1] Martin, Paul. "SE to the rescue?" SE Scholar, Nov. 2008, https://se-scholar.com/se-blog/2008/11/se-to-rescue.html.
[2] Strickland, Eliza. “What Exoskeletons Learned From One Relentless User.” IEEE Spectrum, May 2026, https://spectrum.ieee.org/exoskeleton-user-experience.
[3] INCOSE SEH5, Sec. 2.3.5.2: Stakeholder Needs and Requirements Definition Process.
[4] INCOSE SEH5, Sec. 1.4.2: Cognitive Bias.
