A few years ago, I began looking at defects reported by customers to our support team. For a software tester, this was like being a kid in a candy store.
I realized that the problems customers face are very difficult to anticipate while developing the software. The support issues gave me a clear idea about how I could look for defects in the future. As a tester, this also meant I would have to anticipate customer problems.
Over time, I was surprised that very few people shared my excitement. I slowly realized that there are strong forces that prevent us from recognizing what we could do differently when designing and developing software to prevent customer anguish.
In his book The Inmates are Running the Asylum, Alan Cooper asserts that software is different from mechanical objects we used in the past. He introduces the term “cognitive friction” to explain this difference, which he defines as “the resistance encountered by a human intellect when it engages with a complex system of rules.” Mechanical artifacts are complex, but they may not have cognitive friction. Although a violin can be used in a complex manner, “the violin never enters a ‘meta’ state where various inputs make it sound like a tuba or a bell.” Cooper contrasts this with a microwave oven. The oven has two modes, intensity and radiation, and the number keys are manipulated differently depending on the mode, creating cognitive friction. “This dramatic change, along with the lack of sensory feedback about the oven’s changed state, results in high cognitive friction,” Cooper writes.
While Cooper owns the term “cognitive friction,” Jerry Weinberg has written extensively about the lack of sensory feedback from technology. In How to Observe Software Systems, Weinberg explains that software is “invisible,” by which he means it can’t be seen, heard, felt, tasted, or smelled. This lack of visibility means you cannot use a feedback loop to control the quality of software. “Without visibility, we lose the ability to guarantee control over any project,” he writes. Weinberg explains that this has resulted in various tools to make software visible, but the underlying invisibility makes it difficult to test software or manage its quality.
Both cognitive friction and software invisibility are profound concepts and have formed the basis for Cooper and Weinberg’s work—interaction design for Cooper, and software testing, quality, and management for Weinberg. However, there is a much more sinister aspect of these terms, which neither Cooper nor Weinberg recognized.
It’s Easy—Once You Know How
Users often face problems using software. Sometimes they don’t know how to find certain information; other times, software doesn’t work as expected. In both cases, cognitive friction is at play.
Users can seek help for these problems on online forums or with customer support. Once the underlying reason for the problem is explained, there is no more cognitive friction or software invisibility. I struggled for an hour to get a Wordpress plug-in to work. When I contacted support, they asked me to check conflicts with other plug-ins. Sure enough, there was a conflict—cognitive friction disappeared, and the software was no longer invisible.
The flip side of cognitive friction is that it’s only easy once you know how to do something. In the case of Alan Cooper, he pressed the wrong button on his car’s remote control and the alarm went off—as it was programmed to do, but not as he expected. In some cases, customer support staff themselves cannot figure out how their software works, and they have to read lengthy instructions or the user guide before being able to help customers. As long as users can find the solution and it fixes the issue to their satisfaction, they’re usually happy to have resolved the problem and don’t seem to harbor any ill will.
However, in all of these cases, the real problem seemed to be that the customer didn’t know how to perform the operation, not that the software was difficult to use. If pushed, the problem may be conceded to be a “usability issue.” I am not implying that there is an intention to avoid responsibility. Both with the customer support staff and users, it is cognitive friction at play! The person providing the solution genuinely doesn’t understand the cognitive friction barrier that the user had to overcome.
The end result is that neither customer support nor the development team realizes there is a problem. There is no incentive to change, and the cycle continues. Software remains invisible, and cognitive friction thrives. In Cooper’s book with Robert Reimann, David Cronin, and Christopher Noessel, About Face: The Essentials of Interaction Design, one thesis is that software makes consumers feel stupid. The book teaches how to design software so that the software is intuitive and there is less chance of users having problems. However, what the authors didn’t realize is that when customers face problems that are resolved by the support team or in other forums, customers agree that they should have read the documentation or known better. They agree that they were stupid!
Converting Customer Problems into Learning
Our perception of events is changed when we view what happened later. This cognitive bias is called “hindsight bias.” The effect is even more pronounced when we are not involved in the event. In his book Why We Make Mistakes, journalist Joseph T. Hallinan writes, “With hindsight, things appear obvious after the fact that weren’t obvious before the fact. This is why so many of our mistakes appear—in hindsight—to be so dunderheaded.” If you compare the experience with other objects, hindsight bias is compounded many times by cognitive friction in the case of software.
Alan Cooper’s ideas on design and Jerry Weinberg’s ideas on software quality and testing affect the development team in creating better software. However, the ideas of cognitive friction and software invisibility affect a much larger number of people after the software is released—every one of its users. Once the way software is supposed to work is revealed, it’s as if cognitive friction vanishes, and there is no reason for any change.
Hopefully, once developers and testers understand this much more profound impact of cognitive friction, they will be able to learn the source of the confusion and improve software the next time around. This would result in better engineering, lower cognitive friction, and happier users.
