Mental Load: The Psychological Side of Software

The trouble I often have with SaaS as a business model is that the emphasis is almost always technical: if the tech is easy to use, then the app is easy to use, so the dev and product teams make the tech easy to use... and when it still doesn’t get the uptake they want (or if churn is still too high), they rinse and repeat. Sales, marketing, service, investors... everyone puts all their effort into simplifying the app, tweaking functionality, and blaming the app when things don't go right.

They don’t know what else to do.

But often, users’ problems aren't technical as much as they are psychological. I saw this in the early days of the web, when site design was all the rage. (It was the same conversation as is being had today, just swap "app" and "site.") And in the midst of the Tufte renaissance, here came Amazon, with a horrible user experience and way too many links and unclear navigation and all sorts of whatnot. But we all figured it out. Why? Because we wanted to buy what Amazon was selling! The mental load of using Amazon.com was (and is) low because we already understood what we were doing there and why. All the extraneous links on Amazon's site weren't too much because they had real-world counterparts we already understood—from recommendations to impulse buys to distracting end cap displays. 

At the same time, another site, Yahoo!, was at risk because of it's horrible UI. There was nothing technically difficult about using Yahoo's site to search—the search bar was hard to miss—so in a technical sense, Yahoo! was no different than Amazon. So why the different endings to their stories? Because on Yahoo!, all those other links complicated things in the mind of the user in a way that Amazon's extra links didn't. Very few people understood what a web search was really about. Everyone understood shopping. That meant that while Amazon's extra links required very little brain space to process, Yahoo!'s did. Each extra link served to increase the mental load to figure out what the site was all about. Google's simple homepage lowered the mental load required to understand a web search et voilà.

I call the issue of mental load the Friday Night Problem: it's the level of effort a person has to go through to see themselves identifying with something on Friday night when they're out with friends. If they can’t see themselves identifying as users of an app, they won't use it. It'll look like a technical problem, but it's not. It's psychological. They're imagining a friend asking about something and somewhere in their mind they’re thinking, I can't see myself being the person who gives an answer to or even gets that question.

How do you solve for mental load? SaaS developers are increasingly aware of psychological heuristics as decision making models people use, which is a start. That needs to get extended. The next step is to use those heuristics for something beyond software design… they need to be used for process design. Engineers need a more holistic understanding of what people are trying to solve for. Not the problem the software solves, but the bigger issue of who they're trying to be or what they're running from, and solve for that. 

For instance, I had a call recently with a SaaS entrepreneur with a churn problem. When he talked through his onboarding process, he talked about how he had made it as easy as possible but was still losing people right at the most technically difficult part. What he didn’t notice was that was also the part that required his users to commit to a fundamentally different approach to managing their businesses. I encouraged him to dig into his customer base to understand what obstacles they have that aren’t technical in nature. He hadn't done that yet. I suspect that he's going to find that many of his users don't actually want to solve the problem he solves... because solving it takes away something important from his users: the ability to complain to friends and colleagues about how unsolvable the issue is.

Mental load—the Friday Night Problem—is real, often counterintuitive, and is entirely non-technical. It’s an area of focus that holds the answer to many an adoption/churn problem that SaaS companies won’t be able to solve purely through technical innovation.