The title says it all. I enjoy reading UX questions and answers from Stack Exchange's hot network questions, and I often see people justify their answers by saying it minimizes cognitive load.
I am curious, is that always the goal?
If there are situations where raising (or at least not minimizing) cognitive load is preferable, please list some of those situations.
No. It is not always appropriate to minimize cognitive load.
Minimizing cognitive load is not the goal of usability, human factors, UX, or the user centered design process in general. It is about "good design", and good design is not always the simple design.
To clarify the rationale, let's make sure we have a definition for "cognitive load".
In cognitive psychology, cognitive load refers to the total amount of mental effort being used in the working memory.
To put it another way: how hard is it to figure something out, or how hard is it to accomplish a task. So when is it appropriate to actually make something more difficult?
Requirements of a system are not always strictly "make it simple to use." Many external forces and environment constraints often guide "good design" in a direction where it makes sense to make something more difficult, helping to prevent unintentional usage of either the intended or an unintended user.
Here is an example for The Design of Everyday Things, Donald Norman's classic book, in which a door is made more difficult to use:
Quoted from the book:
This is good design, deliberately and carefully done. The door is to a school for handicapped children, and the school didn't want the children to be able to get out to the street without an adult.
Continuing reading from The Design of Everyday Things:
Most things are intended to be easy to use, but aren't. But some things are deliberately difficult to use - and ought to be.
Designing something to be difficult can protect the user. Reducing the cognitive load may produce a situation where an unintended audience (e.g., children) can too easily use the system. It can also protect the intended audience from making errors.
Guarded buttons are a simple example of making a task more difficult for the intended audience. If you take a peek inside any airplane cockpit, you'll see plenty.
By making the task more difficult, the designer has reduced the chance of an operator accidentally pressing an unintended button.
User Experience is not about "easy".
ISO 9241-2101 defines user experience as "a person's perceptions and responses that result from the use or anticipated use of a product, system or service". According to the ISO definition, user experience includes all the users' emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviors and accomplishments that occur before, during and after use. The ISO also list three factors that influence user experience: system, user and the context of use.
(Source: Wikipedia)
Notice that "easy" isn't in there. "Easy" is good, "easy" is an element, but it is the overall experience (the "anticipated result") that is the overall goal. Safety is a huge part of that.
The US Military has a Military Standard that focuses on Human Engineering (of which User Experience is related). MIL-STD-1472F, "Department of Defense Design Criteria Standard", discusses at length how systems should be designed to promote effective work flows and safety of the user. An excerpt of the Objective of MIL-STD-1472F reads:
Military systems, equipment and facilities shall provide work environments which foster effective procedures, work patterns, and personnel safety and health, and which minimize factors which degrade human performance or increase error.
The standard also has the following requirement:
4.8 Safety. Design shall reflect applicable system and personnel safety factors, including minimizing potential human error in the operation and maintenance of the system, particularly under the conditions of alert, battle stress, or other emergency or non-routine conditions. Design of non- military-unique workplaces and equipment shall conform to OSHA standards unless military applications require more stringent limits (e.g., maximum steady-state noise in personnel-occupied areas).
In many situations, making something "easy" reduces the chance for the operator to make an error. But sometimes the action needs to be made hard in order to achieve the user experience you are looking for - protecting the operator by making it more difficult for them to commit an error.
Reducing UX friction/cognitive load is only helpful if it accomplishes some design goal. Usually, low-friction UX is desirable because it can help users accompish tasks faster, with greater efficiency/productivity, etc.
However, sometimes designers introduce deliberate cognitive load for legitimate reasons.
Here are some examples of deliberate friction in design:
Confirmation dialog - Here, designers use a blocking modal interaction to prevent the user from continuing until she confirms a destructive action.
Anti-spam - Here, the user is inconvenienced by a captcha interaction, but the design is legitimate because the company needs to avoid costly or illegal/unsavory spam.
Legal consent - Here, the user is forced to type in a confirmation (or electronic signature, etc) for legal reasons so the company can show clear consent. A simple button or checkbox might be lower-friction, but the company needs a high-friction interface to ensure that the user has adequate time to pause and consider the legal language.
Security or safety mechanisms - Here, the user is forced to take action in two separate places to open the hood of a car. This is a very high-friction interaction, but it is designed to ensure user intent, safety (hood doesn't oppen by accident if car is moving) and security (hood can't be opened from the outside by a stranger).
There are many other examples, but these interactions should illustrate why designers sometimes add cognitive load intententionally in order to accomplish a greater design goal.
There are already some good answers in this thread. As mentioned, it depends on the system and the context of use.
That being said, I would like to take another viewpoint and highlight a case where users preferred cognitive load over a simplistic design.
The Bloomberg terminal looks like this and people say it's hideous.
IDEO redesigned it to make it simplistic and easy to use. However, it was not taken so well by traders who operate the terminal.
I would like to quote the following from an article published on UX Mag.
As a PortFolio.com article clearly puts it: "Bloomberg isn't looking to do a major overhaul of its terminals' graphic design anytime soon. In fact, company executives see the Bloomberg terminal's unique presentation as a status symbol and a selling point. 'We have to be religiously consistent' to satisfy users who become attached to terminal's look and feel, says Bloomberg chief executive Lex Fenwick. 'You can see a Bloomberg from a mile away.'"
Simplifying the interface of the terminal would not be accepted by most users because, as ethnographic studies show, they take pride on manipulating Bloomberg's current "complex" interface. The pain inflicted by blatant UI flaws such as black background color and yellow and orange text is strangely transformed into the rewarding experience of feeling and looking like a hard-core professional.
The more painful the UI is, the more satisfied these users are.
The Bloomberg Terminal interface looks terrible, but it allows traders and other users to pretend you need to be experienced and knowledgeable to use it.
As pointed out in the comments:
In the case of Bloomberg terminal, people who become proficient with the Bloomberg command line interface can be extremely efficient with it (much more efficient than a point-and-click GUI would allow). Thomson Reuters already offers a competing product called Xtra 3000 which looks a lot like IDEO's proposal (i.e. point-and-click navigation, white background, etc). But the lack of a command line interface makes it much less useful for power users.
Even though the cognitive load is high initially, traders prefer it because it allows them to become more productive with time.
You must have also seen this with some of your fellow programmers who prefer vim/emacs over an IDE. It's initially tough to use, but you can become productive once you get familiar with it.
Design is not just the presentation layer but a whole lot about human psychology and behaviour. What seems like less cognitive load might not work for someone else.
Within a task-completion context:
I'm sorry to be an outlier, but I think a proper answer to this should be a bit more comprehensive.
As a cognitive-scientist-turned-uxer friend on mine who read this question asserted:
If you need to make things harder for the user, you need to make it harder.
But a no answer is dangerous.
It goes:
A design has many dimensions (per requirements engineering). Amongst them:
Now, consider a system that doesn't exist and never will - such system will have no cognitive load on users whatsoever. By the virtue of the system being there (functionality) you introduce cognitive load on its users.
"Where are the external walls Mr Watson?"
"We've decided not to install them to reduce cost".
The point? There are tradeoffs between the various dimensions - adding functionality and safety features is likely to increase cognitive load and there is nothing wrong with this. The question is can you reduce cognitive load while still satisfying all other requirements?
Error prevention is slightly different here - error prevention within non-critical information systems often reduces performance load overall. Making an error in itself is not an issue - it is the consequences that matter. So if on average the performance load added as a consequence of making an error outweighs the performance load involved in preventing the error - by increasing the latter you are reducing the much greater former.
And so, given other requirements are satisfied you should always strive to reduce cognitive load.
The are some exceptions for this, for example:
But even here you can argue that performance load is traded with another requirement.
Another important consideration is cognitive load over time: Any change to a system will increase cognitive load as users have to re-learn. But this doesn't mean that we should never change a system - if the long-term cognitive load reduction outweighs the short term increase, the change is justified.
A design inevitably introduces cognitive load in order to satisfy its various requirements. But should still do so attempting to minimise such load.
Read this article sometime back about Japanese web design and how the Japanese culture influences it, resulting in very cluttered design. but turns out to be a good thing in their case
https://www.techinasia.com/breaking-down-japanese-web-design/
Here is a sample case study. An overseas web service was getting ready to enter the Japanese market and showed the website they had developed outside of Japan to several dozen Japanese users from age 20 to 50, including both men and women. About 80 percent of them said that the design of the website “lacked credibility.” This website employed a creative, simple, and unified design, with a carefully-tended and economical information design.
The users’ reason was simple.
There is not enough information. The simplicity and modernity that is often seen in Western web design gave these users the impression of not providing enough information, which made them uneasy and engendered a lack of trust.
The test continued. Next, banners or imageries were placed on the right and left sides, filling up the empty space with more content. When the users were shown this design, they were observed to be using it without any resistance. Given a large volume of information to satisfy their initially passive attitudes and the freedom to select what they wanted from among many candidates led to a sense of enjoyment, and resulted in them using the website.
In general, UX is about making things easier for the user and often reducing cognitive load is great way to make things easier. But there are exceptions. Some examples would be:
In systems where users perform a supervisory control role, like managing nuclear power plants or chemical plant, a low cognitive load can have a negative impact on performance. These systems are highly automated and run well most of the time. During these times artificially loading users can keep users engaged using the system and help ensure that they have good situational awareness when a problem occurs.
Here's the dictionary definition of load
- A heavy or bulky thing that is being carried or is about to be carried.
- A weight or source of pressure borne by someone or something.
It's always defined as baggage to be dragged around. And so, by definition there's no case where load is preferable.
However, there are cases where a system is overly simplified. If the user has insufficient information to perform their desired action, then you've gone too far.
Information architecture is about finding the threshold of just enough. Not enough details and the user can't act, too much details and it becomes cognitive load.
I try to think about what the user's tasks are when they're using the system.
Usually additional cognitive load gets in the way of those tasks. Remember, people are using your software to accomplish something. They're not there to figure out how your search works or to figure out how to contact you or to learn what the labels you're using mean or to fill out long forms.
I hesitate to say anything is always true, but the way I look at design, yes you should minimize cognitive load.
