Minimize Cognitive Load in UI - A Case Study

Cognitive load refers to the used amount of working memory resources. If the demands placed on working memory, the cognitive load, are too high, users may give up in frustration or fail to comprehend. For example, we can probably read in a familiar language or make simple calculation separately without an issue. However, if we are asked to read and make simple calculation simultaneously, we’d start sweating. This is why a UI requires a lower cognitive load feels easier, more natural, and more comfortable to use.

In this article, I will explain how we apply the theory of cognitive load to design a UI that minimizes the cognitive load of a task that is intrinsically very complex.

The complex task

We are facing an exciting challenge: design a simple user interface for experts to tell us his or her expertise, skills, knowledge, and any other professional capabilities. Experts in our case are experts in high-tech domains such as aerospace, healthcare, automotive, etc.

The challenge is threefold:

1. The task is intrinsically complex. Just imagine trying to explain all your professional capabilities and competencies to others in a few minutes during an interview. There is a lot of thinking (use of working memory) going on during this kind of conversations. So, the cognitive load of the task itself is intrinsically high.
2. This is the first task our users will see right after registration. We want to make sure the UI is professional and inviting enough to keep users engaged.
3. We must make sure this user interface is as SIMPLE as possible. It doesn’t matter how complex a task is, the UI must be simple. This is the fundamental principle we stick to.

So, how exactly can we minimize the very high intrinsic cognitive load?

The approach

KISS & Don’t make me think

My usual approach to a complex problem is KISS (Keep It Simple and Stupid).

When I first communicated KISS with the team, I’d seen many frowning faces. The most dominant doubt being: “Xinrong, all our users are high-tech experts. They are the smartest people we know. Do we really need to keep it simple and stupid?” And my answer is: Yes. I do not have the slightest doubt about our users' intelligence. However, in the case of user experience, the pre-requisite requirement for me is always this: “Do not make users think”. Many User-Centred Design principles are derived from this fundamental principle.

Help users stay focused on more intelligent tasks. Don't "waste" their cognitive load on figuring out what's going on in UI or trying to solve two puzzles at the same time.

How are we going to achieve that? Before I continue to elaborate on the UI design, let's first take a look at the result.

The result

We had done user tests with 17 users (experts in high-tech domains) using an interactive prototype. This prototype behaves the same as the real deal. The only difference is that we weren’t connecting the actual database to the prototype. So, experts had to choose within a limited dataset. That’s the only thing that will remind them: this is not real.

Test result in summary:

• All 17 experts completed the task within 5 minutes without any assistance. 100% task completion on time
• All of them consider the UI to be easy to use. 100% ease of use
• All users are looking forward to the UI that follows this task. 100% user engagement

Based on this result, we are confident that the design is good to go.

So, what exactly have we designed?

The design

Step 1 - The domains

We start with asking the expert what are his or her domains (area of expertise).

A limited number of example domains are displayed on the screen. We give the domain elements a cute name: Bubbles. Bubbles serve three purposes:

1. Ease of use. These domains shown in UI are the most popular ones in our database. So it is likely, a newly joined expert will choose at least one of them. Tap once is a lot easier than entering texts in an input field. Ease of use score 1.
2. Improve learnability. Even if none of these domains is relevant to this expert, at least he or she can learn from the examples what we mean by "domains". In such a way, we minimize the chance of irrelevant user inputs.
3. Get familiarized to a new UI. Choosing or specifying the domains is relatively easy throughout the task. We take this opportunity to introduce the UI to our users and to prepare them for the tougher task. Therefore, in the next step, users no longer need to learn a new UI, their working memory (cognitive load) can be used entirely on what they are asked in the next step.

Tips: Don't fill up screen space with too many items. In this case, more is less (effective)! Keep in mind the "Magical Number Seven, Plus or Minus Two".

Step 2 - Expertise, skills, and knowledge

In the next step, the expert is supposed to tell us his or her expertise, skills, and knowledge.

In our database, experts' professional capabilities are categorized as expertise, skills, and knowledge, currently. Maybe later we will introduce even lower granularity. It is very logical and makes total sense ... for MACHINES.

However, for humans, the mental model is quite different. After a series of interviews with our users, we understand that to complete this task, actually, two separate subtasks are going on in their minds:

1. Subtask 1: They try to recall any professional capabilities and competencies (such as AutoCAD, Defect Analysis, Quality Control, etc.)
2. Subtask 2: They try to allocate each item to the right category (is it expertise, skill or knowledge?)

Ask our users to perform these two subtasks in one go, is the same as asking them to read and make calculation simultaneously.

Well, for this release, we cannot / do not guess an expert's professional capabilities (this is a topic for future releases). So, the input of subtask 1 must come from the users. However, we can help with subtask 2, the categorization.

As a result, this is the design:

Again, we use bubbles, the familiar UI item that the users have learned already. In this case, each bubble represents expertise, skill or knowledge. The items adapt based on chosen knowledge, skills or expertise. For example, when "MySQL" is selected, more items that are associated with MySQL appear, and less relevant items disappear. In such a way, it is more likely users can tap on a bubble. Also, it is more likely that the items can remind users of other familiar items.

This UI encourages users to focus on finding the relevant keywords or recalling what they are good at. Let the system sort out the items.

Tips: Recognition over recall. Recognition requires less cognitive load than recall. Furthermore, recognition is far less error-prone. It doesn't mean that our experts don't know what they are good at. Different experts might refer to the same item with different wording using a free-text input UI.

Summary

We must ask our users to go through a crucial task which requires high cognitive load. Here are the methods that we use to minimize users' cognitive load and, ultimately, offer a friendly and pleasant user experience.

• KISS (Keep It Simple and Stupid)
• Show no more than 9 hints on one screen at any given time
• Construct a mental model of our users.
• Recognition over recall

It is how we make it for this challenge this time. We are going to face more challenges in the future. And along the journey, we hope we can improve our user experience even more with every release. For TASKER, the UI can never be too simple.

If you want to know more about TASKER, please read this article: On a Mission to Make the CV Obsolete and Is there a need for a new Social Platform? or even better, join us at:

ArtesFAST.com