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.