Cognitive Load and Why Enterprise Software Exhausts People

I once watched a procurement officer spend about twenty minutes looking for a button in an enterprise system to approve a purchase order. She had done this task hundreds of times. She was not new to the software. She was not confused about her job. The button had moved in the latest update, and finding it now required navigating through a menu structure that felt designed to obscure rather than reveal. She eventually found it. Then she went back to the workaround she had been using for the past week, which involved exporting a spreadsheet and emailing her manager.

This is not a story about a bad employee or a poorly trained user. It is a story about a software system that treats human cognition as optional.

The theoretical frame here is cognitive load theory. My understanding from educational psychology and HCI literature is that the foundational work comes from Sweller (1988), who demonstrated that working memory is severely limited, and that when the cognitive demands of a task exceed working memory capacity, performance collapses. This is not a personal failing. It is a structural property of human cognition. Similarly, George Miller's well-known 1956 paper described working memory as holding roughly seven items at a time, plus or minus two, before things start to fall off. I am citing both from my understanding of the broader literature, as neither appears in my course study-hub files directly, but both are widely cited foundational references in cognitive psychology and HCI research.

What Hu, Hu, and Fang (2017) contributed specifically in IS research was showing that cognitive load mediates the relationship between system design features and user satisfaction. That is an important finding for IS researchers because it tells us that the path from "design choices" to "unhappy users" runs through cognitive overload, not through some vague notion of complexity or user preference. The mechanism matters.

Think about what the typical enterprise system asks of a user in a single workflow. Open the application. Navigate to the correct module, which may be nested inside two or three levels of menu. Find the right form, which may have dozens of fields, most of them irrelevant to the current task. Fill in the required fields, remembering which ones are truly required versus which ones will cause an error later if skipped. Submit, then wait to see whether an error message appears, and if so, decode what it means and what action to take.

Each of these steps asks the user to hold context in working memory while performing the next step. The module name, the record number, the state of the transaction, what was entered in the previous screen, what error message just appeared. A system with well-designed information architecture reduces this load by making context visible, by surfacing relevant information at the right moment, and by not forcing users to hold state in their heads. A system with poor information architecture forces users to do mental juggling that the software should be doing for them.

The phrase "feature-rich" is used as a compliment in enterprise software marketing. More features, more capabilities, more configuration options. But from a cognitive load perspective, every feature that is present in the interface, even features the current user never needs, contributes to what Sweller would call extraneous load. It is not directly related to the task at hand, but it consumes working memory simply by being present and requiring evaluation. A dashboard with thirty widgets is not more helpful than one with five. It is more exhausting.

This is why the "consumerization of IT" trend exists. When employees are given a choice between the enterprise tool and a consumer app that does something similar, they often choose the consumer app. Not because the consumer app has more features, it almost certainly has fewer. And not because employees are lazy or untrained. It is because the consumer app is designed with cognitive load in mind. Instagram does not require you to navigate three menu levels to post a photo. Slack does not ask you to remember a record number before you can send a message. These applications constrain choice in ways that match how human attention and working memory actually work.

Enterprise software vendors tend to rationalize the complexity by pointing to the complexity of enterprise processes. Fair enough. Enterprise processes are genuinely complex. But complexity in the underlying business process does not require complexity in the interface. Separating those two things is exactly the design challenge.

The deeper problem is who enterprise software is evaluated by versus who actually uses it. Purchase decisions are made by procurement officers, IT directors, and finance teams comparing feature lists and integration capabilities and security certifications. Usage happens at the hands of people who have ten minutes between meetings to complete a task they need to do fifty times a month. Those are different populations with different concerns, and most enterprise software is optimized for the first group's decision-making process, not the second group's daily experience.

Cognitive load theory predicts this outcome precisely. When the cognitive demands of a system consistently exceed working memory capacity, users do not get better at using the system. They find workarounds. They export to spreadsheets. They keep a notebook of steps they cannot remember. They develop shadow systems. Every workaround is a signal that the designed system failed to meet people where their cognition actually is. That is not a training problem. It is a design problem.