The talk defines engineering as the application of scientific and mathematical principles to practical ends and argues that this approach is essential for safety‑critical interactive systems. It uses the ubiquitous yet often poorly implemented cancel function as a concrete example of where engineering rigor can dramatically improve usability. The speakers explain that a truly usable cancel requires 21 distinct software responsibilities—ranging from simple UI elements to perceptual‑performance constraints such as providing visual feedback within 150 ms. To test whether exposing engineers to these responsibilities helps, a controlled lab experiment was run with three groups: (1) asked only to add a cancel button, (2) given the list of responsibilities, and (3) given the list plus sample UML designs. Results showed that without guidance engineers considered on average only three of the 21 responsibilities, and extra time spent did not improve solutions. Providing the responsibilities increased the number of considerations, and adding design artifacts further improved outcomes. The speakers note that many responsibilities are obvious, but others rely on basic psychology and architecture tactics. Building on this research, they created a tool that embeds the responsibilities and design guidance; a pilot with ABB’s product‑line designers reported that six hours of tool use saved five weeks of work, yielding a 17:1 return on investment. The presentation concludes that upfront engineering effort—identifying responsibilities, providing design artifacts, and tooling—yields substantial downstream payoff in software quality and development efficiency.
Chapters
Engineering.
The dictionary defines it as the application of scientific and mathematical principles to practical ends. An engineering approach is clearly valuable when designing safety-critical interactive systems, such as infusion pumps for drug delivery. They've obviously got to be reliable. But engineering can seem high effort for low return the rest of the time, isn't it? Let's consider cancel.
Since making this video, I've seen cancel buttons everywhere. They're on everything with a process.
Except they're not! They should be though. For example, I sometimes hit the startup button for an app that wasn't next to the one that I intended to start up, and then I have to sit there for ages waiting for it to actually load up because I can't cancel that process.
You know, Nielsen says many usability problems have fairly obvious fixes as soon as they have been identified. So tell the software engineers: Add cancel. There's more to cancel than just adding a button. In fact, years of engineering and HCI research has identified 21 software responsibilities that a software engineer would have to consider and build into their system to implement a truly usable cancel that works for people. And we can express those things in a list of responsibilities or in sample solutions, in component diagrams or sequence diagrams. And the problem is that things like implementing cancel and thinking about all these things are not taught in software engineering education. And there's a mismatch because HCI people believe the software engineers know how to implement this. We in engineering for HCI research can solve this problem by identifying all the responsibilities that people would have to implement and presenting them to software engineers. And in fact, we did that.
To find out if our ideas could actually help software engineers, first we did a controlled experiment in the lab, asking the question: How many responsibilities would software engineers consider when modifying a software architecture to support cancel? We asked the first group to just add cancel. We asked the next group to add cancel and we gave them our list of responsibilities. We asked the third group to add cancel, gave them our list of responsibilities, and a sample solution and UML diagrams. We found that if you just ask them to add cancel, trained software engineers on average consider only 3 of the 21 necessary responsibilities. If we gave them more information, that is, the software responsibilities, they identified significantly more. So responsibilities do help, but there's a lot of room for improvement, perhaps with tools. There was one more really interesting thing in our results. We had asked them to spend as much time as they wanted modifying this architecture, expecting that the participants who spent longer would produce higher quality solutions, as is typical in any problem-solving task. That is the result we got when we gave them the software responsibilities, but that's not what we saw when engineers were just asked to add cancel. There they worked and worked, they did not give up, some people spent 2 hours on this, but their solution was no better. So they didn't even know that they didn't know.
Now, these responsibilities are sometimes very obvious. Provide a command, a button, a keyboard shortcut, something like that. Sometimes they depend on basic science, like psychology, perceptual and motor psychology. If you don't provide visual feedback at the point where a person clicked the button that they actually receive the command, like the button changes color or something, that they receive the command within 150 milliseconds. That's how long it takes a person to not see it and decide to click the button again. So we actually have a performance requirement on this. And there's lots of software architecture tactics that we can use to help implement a good solution that we can provide to practicing software engineers because we've done the research. Now that we've said, hey, there may be value in this, we can go to the next level and embed this information in tools. So we did that. We built a tool and we worked with a company called ABB who was designing new product line architecture. And the senior software designer and a new software designer worked together. They spent 6 hours using our tool, and when they were done, they said that 6-hour experience saved our team 5 weeks of work. That is a return on investment of 17:1.
By investing upfront in developing guidance and science and tools, engineering typically demands less ongoing effort for higher returns.
