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.
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
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.