Users interact with a software application by means of physical actions, such as:
- Pressing individual keys or key combinations
- Sustained typing
- Precisely aiming a pointing device (homing the mouse pointer onto a target)
- Clicking the mouse or touching and gesturing on the screen
Performing each action incurs a cost of time, physical effort, and some mental effort. In other words, performing an action requires the user to expend some energy.
In addition to the above physical actions, there are other actions that cost time, physical and mental effort, and energy, such as:
- Reading labels, titles, and instructions
- Choosing an option from a list or menu
- Trying to locate something specific
- Switching contexts (for example, switching between two windows, pages, or tabs)
- Switching visual attention (for example, reading text, then referring to an illustration, and then returning to the text)
- Waiting for a response from the system
- Recovering from some kind of distraction (like an unexpected pop-up dialog)
In general, users don’t mind performing actions when the actions clearly help to make progress towards achieving a desirable goal, and when there seems to be some underlying rationale for why the actions are necessary. However, being forced to undertake actions that are perceived as unnecessary quickly produces feelings of annoyance; the application is forcing the user to waste her time and energy. With enough repeated annoyances, it is only natural that resentment will form towards the designers of the application, who evidently have little respect for the user.
Therefore, we should obviously aim to design applications in such a way that any unnecessary work is eliminated or automated. Making it possible for users to accomplish tasks efficiently, with as few actions as possible, saves time and energy and makes for a much more pleasant user experience.
But consider this situation: If we can take a design that requires ten mouse clicks to accomplish a task, and revise it so that it only requires seven mouse clicks, then we’d probably say that the revised design is superior, because three evidently superfluous mouse clicks were eliminated. But what if the first design didn’t require much conscious thought — the user just had to repetitively click “Next” ten times in a row in a wizard where all the default settings were acceptable. And perhaps the second design required a lot of thought as to how to set various options in a very large, complex control panel. In this case, it sounds like the first design is the easier one to use, even though it involves a few more clicks.
While we should generally aim to reduce the average number of physical and low-level actions a user must perform, we should really take a broader view. We must consider the cognitive load imposed by the task and the user interface.
Cognitive load refers how mentally taxing it is to do a task. It is essentially a way of referring to how much sustained “brainpower” is required to do something.
The more complex a task is — that is, the more contextual details of the task that the user has to keep in working memory, and the more the task demands a high level of focused attention — the higher the cognitive load is for that task.
And so a good general design strategy is to reduce the user’s cognitive load as much as possible. The title of Steve Krug’s popular book Don’t make me think! says it all — reducing the amount of thinking the user has to do is perhaps the single most important principle of designing usable and enjoyable software products.
Thinking might just be the hardest kind of work there is. At least, it is the most avoided. For instance, most users of spreadsheets and word processors use a lot of repetitive manual keystrokes for, say, formatting content. While these users may suspect that there must be a more efficient way of doing the reformatting, they continue to use their trusted but labor-intensive methods, because thinking through the problem, investigating alternatives, and learning how to use features like macros or scripting would involve more intense mental effort than just plowing through using manual techniques that require less thinking. While an alternative method would probably save time over the long run, users doesn’t want to spend the time and effort to figure out the alternative.
Types of thinking
Let’s consider some of the different kinds of thinking that users of software might have to engage in. If your application requires some of the following kinds of thinking, it might be worth investigating whether you can restructure the design to reduce to some degree the need to engage in them:
- Determining what the next step in a procedure should be
- Holding things in working memory for the duration of the task
- Having to recall facts, commands, or procedures from long-term memory
- Having to memorize things in long-term memory
- Having to look up information from a reference source
- Making decisions or judgements
- Mentally integrating information from multiple sources
For many intellectual tasks, a lot of thinking goes on in the user’s head, and the software is only incidental to this thinking; the software provides a way to support the activity or record the results of the thinking. For example:
- Creative output; generating the content of writing, audio, or visual art projects
- Reading and understanding long passages of text
- Actively conducting research
For these higher-level types of thinking, there’s often little you can do to reduce the amount of thinking required, because the thinking has little to do with operating the software. The best you can do is ensure that the software works reliably, generates good- quality output, and supports the task as best as possible. If your application lets users access academic journals, the search function should provide relevant results. Providing good-quality results will reduce the amount of time the user spends searching, navigating, and reading. Likewise, if your application is a word processor and your user is writing a novel, there’s little you can do to relieve the user of the very tricky mental work involved in creative writing — developing a plotline, creating and fleshing out characters, writing the narrative and dialogue, and so on. But there may be opportunities for your application to aid the user in secondary ways, such as offering support for organizing notes and materials, or providing tools for editing and proofreading.
Reducing the amount of all types of work and effort — both thinking and physical actions — will result in a product that is easier and more enjoyable to use. And so “Don’t make me work any more than I have to!” might be the best usability design advice of all (although it doesn’t make for a catchy book title).
Recreational and creative uses of software
This whole discussion may make it sound like operating software is an intolerable ordeal. For some enterprise systems, this portrayal is accurate, but it’s not the case for all software.
Games require interaction with an interface, but this is not perceived as being work. Having to click 100 times to delete 100 spam comments on a blog would be considered intolerably poor design. Yet people will happily click hundreds of times when playing a game such as Mah-Jongg, and some players of online games have been known to compulsively spend hundreds of hours doing very repetitive tasks to earn points or status or currency in virtual game worlds. There are also countless games like flight simulators where players gain enjoyment and satisfaction from doing what others, such as aircraft pilots, do in their everyday jobs.
As well, when people get deeply involved in producing a creative work, whether writing a novel or drawing art, what might appear to be work to others may not be perceived as work by the artist.
Work that is voluntary and creative is simply more pleasurable than work that is involuntary and mundane. Motivating factors, like competition in games, can also change the way work is perceived.