If you inspect a prototype or product and systematically check whether it adheres to a set of heuristics, you are conducting what is called a heuristic inspection or heuristic evaluation. It is a simple, effective, and inexpensive means of identifying problems and defects and is an excellent first technique to use before moving on to more costly and involved methods such as user observation sessions.

It is usually best when a heuristic evaluation is carried out by an experienced usability specialist, but heuristic evaluations can also be very effectively when they are conducted by a team of individuals with diverse backgrounds (for example, domain experts, developers, and users).

To conduct a heuristic evaluation, you should choose several scenarios for various tasks that a user would perform. As you act out each of the steps of the task flows in the scenarios, consult the list of heuristics, and judge whether the interface conforms to each heuristic (if it is applicable).

Jakob Nielsen introduced the idea of heuristic evaluations, and his 1994 list of ten heuristics, reproduced below, is still the most commonly used set of heuristics today (Nielsen, 1994, p. 30):

An obvious weakness of the heuristic inspection technique is that the inspectors are usually not the actual users. Biases, pre-existing knowledge, incorrect assumptions about how users go about tasks, and the skill or lack of skill of the inspectors are all factors that can skew the results of a heuristic inspection.

Heuristic inspections can also be combined with standards inspections or checklist inspections, where you inspect the interface and verify that it conforms to documents such as style guides, platform standards guides, or specific checklists devised by your project team. This can help ensure conformity and consistency throughout your application.

The KLM-GOMS model, the Keystroke-Level Model for the Goals, Operators, Methods, and Selection Rules analysis approach (Card, Moran, and Newell, 1983), is one analysis technique based on this idea, but instead of assigning scores representing effort, an estimate of the time required to do each action is estimated instead. The amount of time it takes to complete a task is a good proxy for physical effort, although it does not accurately measure the intensity of mental effort.

Let’s take a very condensed tour of the KLM-GOMS approach.

To accomplish a goal, the user will break the work into tasks, and for each task unit, the user will take a moment to construct a mental representation and choose a strategy or method for carrying out the task. This preparation time is called the “task acquisition” time, and can be very short — perhaps 1 to 3 seconds — for routine tasks, or much longer, perhaps even extending into several minutes, for creative design and composition tasks.

After the task acquisition, the user carries out the task by means of a sequence of actions or operations. The total time taken to carry out the actions is called the “task execution” time. Thus the total time required to complete a task is the sum of the task acquisition and task execution times.

To estimate the task execution time, KLM-GOMS defines basic operations (we assume here that we are dealing with a keyboard-and-mouse system):

So to use the mouse to click on a button, we would have a sequence of operations encoded as “HPK”: homing, to move the hand to the mouse; pointing, to point the mouse cursor to the button; and a keystroke, representing the pressing of the mouse button.

In addition to these operators, the KLM-GOMS model also includes a set of heuristic rules governing how the “M” operation, the mental operation, is to be inserted into an encoded sequence. For instance, “M” operations should be placed before most “K” and “P” operations, except for various special cases. So the “HPK” sequence discussed above would become “HMPK”. The rules are fairly arcane and we won’t go into the details here.

As an example, let’s consider the task of finding instances of a search term in a document in a text editor. One possible sequence of actions to accomplish this might be:

• Click on the “Search” menu
• Click on the “Find text” item
• Enter “puppy” as the search term in dialog
• Click on the “OK” button

This can be encoded using KLM-GOMS and used to formulate an estimate of the average time required as follows:

Of course, we would expect a more skilled user to be able to accomplish the same task in substantially less time by using shortcut keystrokes rather than the mouse, and by typing faster than an “average” user.

There are obviously limitations to this kind of analysis; it provides a general rough estimate only, and it assumes that users know the right sequences of actions to complete a task. It also does not account for errors and mistakes. But when you are designing an interface and considering how to design an interaction, methods such as the KLM-GOMS model give you a way to compare the efficiency of different alternatives, and all other things being equal, the alternative that can be done in the least amount of time is the most convenient to the user, and may involve the least cognitive load.

To create an ergonomically sound software application, it is important to first think about the properties and the context of use of the hardware device on which the application will run. For the majority of consumer and business applications, there are currently three main forms of general-purpose personal computing devices:

• Desktop and laptop computers with a screen, keyboard, and a pointing device such as a mouse or trackpad, are comfortable for users sitting at a desk for a long period of time.
• Tablet devices with touchscreens have a form factor that is comfortable for sitting and consuming content (reading webpages, watching movies, etc.), but entering information and creating content via touch-screen control is generally not as comfortable and convenient as with a desktop machine.
• Mobile phones (and similar devices such as portable music players) are usually used for short bursts of activity while on the go.

For more specialized applications, you might have a combination of software and custom-designed, special-purpose hardware. Examples include a machine that sells subway tickets, an automated teller machine, or an industrial thermostat control. If you are a designer for such a product, you may have responsibility for designing the form of the physical interface in addition to the software.

To give you an idea of some of the practical ergonomic aspects that you should keep in mind when designing for different devices, let’s compare desktop computers with touchscreen tablets:

• Tablet devices with multi-touch touchscreens are pleasant and fun to use from an interaction standpoint because you can interact directly with on-screen elements by touching them with your finger. Desktop machines (as of this writing) generally don’t offer touchscreens, as reaching your arm out to the monitor places strain on the arm and shoulder muscles and would quickly become physically tiring. Desktop setups thus rely on pointing devices such the mouse or trackpads. These pointing devices introduce a level of indirection, however: moving the pointing device moves a cursor on the screen.

• On desktop systems, there is a pointing device cursor (mouse arrow), whereas touchscreen devices have no such cursor. Some mouse gestures, like hovering the cursor over a control, thus have no counterpart in touchscreen systems. On both desktop and touchscreen systems, however, a text cursor (caret) appears when a text field receives the focus.

• While a mouse may have multiple buttons, and clicks can be combined with holding down modifier keys (Control/Alt/Command/Shift), touchscreens don’t offer as many options. When you drag your finger across the screen, is it to be interpreted as a scrolling gesture, or an attempt to drag and drop an object on the screen? Cut-and-paste and right-clicking to get a context menu are easy on a desktop machine, but on a tablet, such operations require double-touch or touch-and-hold gestures that are not always evident.

• Fingers range in size substantially; young children have small, narrow fingertips, whereas some men have very thick, fat fingers. Touchscreen buttons and icons thus must be large enough to accommodate “blunt” presses without triggering other nearby controls. In contrast, the mouse arrow allows pixel-precise pointing, and so buttons and icons can be substantially smaller on desktop applications than on touchscreen devices.

• When the user is touching something on the screen, the user’s finger and hand will obscure part of the screen, so you have to be careful about what you display and where, so that important information is not hidden. When pressing an on-screen button, the user’s fingertip will obscure the button being pressed. Because button presses don’t always “register”, users seek visual feedback to see that the button press worked, and so you either need to make the buttons large enough so that the animation of the button being depressed is visible, or you should give some other clue when the user retracts the finger to show that the button was pressed (maybe pressing a Next button makes the application navigate to the next screen, which is very clear feedback that the button press was successful). Auditory feedback, like a clicking sound, can also be useful as a cue that the button was pressed successfully.

• Mobile devices and tablet devices are often held by the user in one hand while standing, and so the user has only the other hand free to operate the touchscreen.

When designing a product, understanding the constraints and limitations, as well as the opportunities, of the hardware devices the software will run on will help you design appropriate and comfortable interactions.

Take this page for example:

The banner is the highest element in the hierarchy of this page. The banner and logo tell the viewer that everything on the page is associated with the site named in the banner.

The navigation bar on the left-hand side of the page comes second in the visual hierarchy.

The main content panel’s heading, “Events Calendar”, which describes the contents that follow, forms the third element in the visual hierarchy.

The two subheadings are subordinate to the main heading, so they come next in the visual hierarchy.

Finally, the sections of body text are subordinate to their respective headings. These come last in the visual hierarchy.

When scanning the page, the viewer’s eye will tend to look first at the banner, then move to the navigation sidebar, then the main heading. While the viewer may read the content under the main heading from top to bottom, it is likely that the viewer’s eye will be caught by the subheadings first, and then the viewer’s eye may go back to read the body text.

The visual hierarchy helps the viewer interpret the content on the page in a logical way. Let’s now take a closer look at how create a visual hierarchy and express relationships between different elements on the page.  Our main tools for achieving this are the use of similar or contrasting visual attributes of elements, and the relative positioning of elements.

Attributes

Attributes are the general properties of things on the page. Common attributes are size, shape, color, texture, and direction. For text, attributes include the typeface, weight, spacing, and decorations such as italicization or underlining. In other words, attributes are ways to style a visual element.

Visual elements that are similar or belong to the same category should share the same attributes, whereas elements that are intended to be different should have one or more contrasting attributes. If one element is intended to be stronger or more important than the other element, then the attributes should be chosen to reflect that.

For example, if you have a list or a menu, then all of the entries belong to the same class or category of elements, and so they should be styled consistently with the same attributes. But the heading that sits atop the list serves a different function. It describes or summarizes the contents of the list or menu, and so it should be styled with contrasting attributes that emphasize its dominance. The heading might be larger or bolder, or it may take a different typeface or color.

Contrast is weak when the elements being contrasted are only slightly different. When two element differ only slightly, it can often look like the difference was made by accident. Strong contrast is produced when the differences are clearly intentional. To create intentional contrast between two elements, the general guideline is to make sure the elements differ in at least two ways; that is, at least two attributes should be different between the elements.

For the purposes of this guideline, surrounding space is often considered to be an attribute as well, so leaving a gap of whitespace between two elements can count as one of the differences.

The following diagram shows some examples of weak contrast and strong contrast between a heading and a list of items:

In example (1), there are no differences between the heading “Commodities” and the entries in the list, so it does not look like a heading at all.

Example (2) is better — the heading is in bold type — but the difference still does not stand out strongly.

Example (3) places a gap between the heading and the list. While this is also better than (1), it is still not satisfying, as the heading is set in the same type as the list entries.

Examples (4) through (6) illustrate how using two differences produces much stronger visual contrast. Example (4) uses a gap and sets the heading in bold type. Example (5) sets the heading in bold type and uses indented bullets to offset the list from the heading. Example (6) increases the size of the heading’s font and sets the heading in a different color.

The latter three examples communicate the relationship between the heading and the list entries much more effectively than do the first three examples.

Positioning

In the English-speaking world, and in other left-to-right languages, we read from left-to-right and from top-to-bottom. What is at the top of the page is considered to be more important than what is at the bottom of the page, and to a lesser extent, things on the left in a row of things are perceived to come first. (In right-to-left languages like Arabic and Hebrew, the right-to-left direction is reversed.)

Thus, the top-left corner of the page is where the eye begins when scanning the page, and so the most important element in the visual hierarchy is usually placed there.

If we have two visual elements A and B, we should ensure that A is positioned either above, or to the left of, element B, when we want to show that:

• Element A is more important than element B; or,
• Element B is a subelement of A; or,
• Element B depends on, logically follows from, or derives from, element A; or,
• Element A is the cause and B is the effect; or
• Element B naturally follows A in a logical sequence.

As an example, let’s take one example of poor design that I’ve encountered. One system had a screen for editing customer details that looked roughly like this:

Users were expected to enter a value in the Customer Number field and then click Retrieve. The other fields on the screen would then be populated with the data on file for that particular customer.

The above design is poor because the relationship between the customer number and the remaining fields is not communicated by the visual design.

The data on this screen is dependent on the customer number, because the customer number is the identifying piece of information, or key, for a customer record. If the user enters a new customer number and clicks Retrieve, new data for the new customer number will be presented.

But because the user will start reading the screen from the top left, the user might assume that the last name and first name are identifying the customer record. Additionally, the fact that the user is expected to locate the Customer Number field first is troubling; it is buried deep in the screen, and there are no visual cues that it is the most important element upon which the others are dependent. If it is the identifying field upon which the other fields depend, then it should be situated in a place that better communicates its importance: the upper left, where the user begins scanning the screen.

And the fact that the user has to jump from the Customer Number field up to the Retrieve button is poor design as well. There are no cues that this is how the interaction flow is supposed to work; because we read from left-to-right and from top-to-bottom, jumping from below to above is counterintuitive. The button should be moved so that there is a left-to-right or top-to-bottom flow from the Customer Number field to the Retrieve button.

Thus, one possibility for an improved layout might be something like the following:

In this design, it is clearer that the details are dependent upon the chosen customer number. There is a left-to-right flow from the Customer Number field to the Retrieve button, and there is top-to-bottom flow that leads towards the finalizing Save and Cancel buttons.

Practical aspects of visual hierarchy for user interface design

While you may not necessarily explicitly design a visual hierarchy when creating a page composition, an awareness of the general concept of the visual hierarchy and an understanding of how relationships between elements can be expressed can help you produce better designs.

In large project teams, you can try to ensure some degree of visual design consistency throughout your product by creating a style guide that defines the general look-and-feel of the interface in terms of a visual hierarchy. Writing a style guide is not always easy; it’s not always possible to completely document everything that makes up a consistent set of visual designs. But by specifying rules for the styles and positioning of headings and other visual elements, and by providing page layout templates and examples, a style guide can help communicate your design intentions to your project team.

Some usability problems can be seen as violations of design principles. Here is how violating Donald Norman’s principles of usability can impair the user experience:

• Lack of consistency: An interface that exhibits inconsistencies in visual layout, labelling, behavior, etc. makes it harder for users to detect and learn patterns and form mental models. Inconsistencies force users to memorize and remember exceptions to rules, increasing the cognitive load.

• Poor visibility of controls: Frustration and lost productivity can result when users can’t locate the controls they are looking for, or when users are looking for means to carry out actions but cannot find appropriate controls.

• Poor affordance cues for controls: When controls don’t give visual clues as to how they can be operated, users must figure out what the controls do by means of time-consuming trial-and-error. Some controls may not even be perceived as controls, and some functionality may be “hidden” when the user cannot discover the means of activating it (for instance, a user may not realize that a context menu can be opened by right-clicking on an icon).

• Poor mapping cues for controls: When controls don’t clearly indicate what actions they perform, confusion can result when behavior does not match users’ expectations, or when users cannot find appropriate controls for actions they want to perform.

• Insufficient feedback: Without prompt and clear feedback, the user can be left wondering whether a control was properly activated and whether the action was successfully performed.

• Lack of constraints: Without constraints, users may be able to perform invalid operations, use controls in invalid ways, or enter invalid data. These problems can cause the system to enter an unstable, unpredictable state.

There are many other general problems that can contribute to a poor user experience. For instance:

• Unreliability, bugginess, flakiness, and instability: If the software crashes, or exhibits unpredictable behavior, it impairs the user’s trust in the software. The user may fear losing his work or having his data corrupted. The user has to waste time discovering and applying workarounds to avoid bugs.

• Poor performance: Lag, latency (delayed responses), and excessively long processing times are annoying and jarring because they interrupt the flow and rhythm of work.

• Disorganized, cluttered, or otherwise unappealing visual design: Unaesthetic, crowded, and poorly-designed screen or page layouts make it hard to find things, and are just simply depressing to look at.

• Conceptual model mismatching the user’s model: If the product’s view of the world or the domain (including things like terminology and processes) doesn’t match what users already understand, then users will have a hard time learning and conforming to the product’s alien way of thinking.

• Behavior not meeting expectations: Users can become disappointed when the product doesn’t work the way they expect.

• Excessive complexity: Too many steps and options and settings for seemingly simple tasks can be overwhelming. Complex products are harder to learn, and error rates will be high because users are more likely to make mistakes. The difficulty can cause the user to feel inadequate, incompetent, and embarrassed.

• Too much work: Users resent products that make them carry out repetitive, mundane tasks that could have been automated.

• Too much thinking: The product makes the user think too hard to figure out how to do things.

• The product makes it tedious or impossible to produce good quality output: For example, one diagramming tool I’ve used has no way to ensure that elements are aligned, and allows elements to be moved by two or more pixels, but not by one pixel, making it extraordinarily difficult and painstaking to create diagrams with aligned elements.

• The work that the product does is of low quality: For example, a paint program may render unaliased, “jagged” fonts, or a software development tool may generate code that doesn’t compile.

• Error correction is tedious: People make mistakes, and it shouldn’t be an ordeal to correct them.

To find usability problems such as the above, you should conduct usability testing on your designs, your prototypes, or your actual product. User observation is the most reliable way to discover where your users will have difficulties with your application.

There are many things that can cause users frustration and annoyance with software. The list of “don’ts” could become quite long, depending on how specific we get with particular problems.

Unfortunately, trying to capture and name the general things that make products enjoyable and easy to learn and use is a bit more difficult, and this list of “do’s” will tend to be much more general.

Firstly, we could say that a positive user experience is characterized by the absence of any of the problem factors that contribute to a negative user experience. If our list of “don’ts” includes things like unreliable behavior and a lack of prompt feedback, then a product probably doesn’t have a great user experience as long as these negative characteristics are present.

But we’d also like a list of “positive” characteristics associated with a good user experience, and the following list attempts to name some of these characteristics. Note that not all characteristics may apply to all types of products.

A product exhibiting a good user experience typically…

• is generally enjoyable and rewarding to use (and in the case of games, may even be addictive);
• enables high productivity and efficiency;
• enables the user to produce a good quality work product;
• enables and encourages the user to enter a “flow state”, i.e., a mental state of focus, concentration, and total immersion that engenders creativity, productivity, and satisfaction;exhibits acceptable performance (such as responsiveness);
• is visually appealing;
• is stable, reliable, and trustworthy;
• gives the impression that there is a logical, rational, intentional design behind it; and
• does not make the user feel incompetent, dumb, or embarrassed.

It should be noted that all of these are vague, subjective, and not easily measurable, and thus don’t lead themselves to easy checklist-style verification.

There are some cases where a product can have a rather poor interface, and yet users still rate their satisfaction with the product highly. This can happen, for instance, if the product facilitates enjoyable experiences, such as social interaction, or if the product is perceived as providing extraordinary value (especially if it is free). For instance, a free videoconferencing application lets geographically-dispersed family members stay in contact, and so even if the interface is poor, users may still highly value the application — it’s not so much the application that they’re focused on, but rather the emotional aspect of the social connection and interaction that the application lets them enjoy.

Psychologist Mihaly Csikszentmihalyi described and popularized the concept of flow, which is the mental state of being completely focused on an activity. For a user who is in a flow state:

• Performance of the activity occurs naturally and unconsciously. Creativity and productivity are high.
• The user experiences deep concentration and immersion in the activity. The user is simultaneously alert and relatively relaxed.
• The user often becomes so engrossed in the activity that she is unaware of the passage of time (often described as “living in the moment”).
• The difficulty of the activity is a good match for the user’s skill: there is sufficient challenge to keep the user’s interest, but not so much that the task seems impossible, and the activity is not so mundane that it causes boredom.
• The user is confident and has a sense of control over the situation.
• Usually, the user is working towards achieving a specific goal. (For some applications, the goal may not always be particularly productive; in the case of games, the goal may be simply to finish one more level.)

Here are some things you should know about flow states with regard to software:

• Beginning users generally cannot be expected to be able to enter a flow state; it requires some level of comfort and competence with operating the application.
• It is often difficult to get into a flow state, and simply wishing to concentrate does not make it happen. Typically, it takes 15 minutes or more of struggling and working unproductively before one can “get into the groove”.
• Interruptions, such as pop-up notifications and phone calls, and distractions, such as chattering coworkers or a television in the same room, can pull a user out of a flow state. When returning to the activity after a distraction, it usually takes another period of time to get back into a flow state.

There is little you can do as a designer to explicitly help a user enter a flow state, but you can encourage and sustain concentration and flow by making the experience work smoothly, minimizing or eliminating any repeated frustrations that might hinder the user from concentrating. Here are some design suggestions for doing that:

• Try to eliminate interruptions like modal pop-up dialogs that present notification and warning messages. Offer expert users the option of turning off any repetitive warnings.
• Keep the visual presentation simple. Brightly-colored images, and especially anything animated or blinking, can distract the user from reading text or concentrating on a work activity.
• When possible, guide the user through task flows. Make it obvious what the next step is, so that the user doesn’t have to start exploring the interface, which might lead to distraction.
• Don’t make the user switch repeatedly between different pages, screens, or tabs to find information; each context switch can be disorienting and can cause the user to forget what she was just doing.
• Make it easy for the user to save any work in progress and then later pick up where she last left off.
• Show completion progress for lengthy tasks. When possible, reward the user for completing tasks; even a simple chime sound effect when a task is completed can be satisfying.
• Ensure that the system gives feedback promptly; especially in web-based systems, work to reduce latency. Having to wait several seconds for confirmation that a button was pressed can become very annoying very quickly.
• It can be hard for humans to concentrate on multiple things at one, so when possible, don’t make users manage multiple tasks at the same time. On the other hand, when the system is busy with a long-running process, you should give the user the option to have the process run in the background so that she can work on something else in the meantime. When users have to wait for a long or unknown length of time, they will frequently switch to something else (like checking e-mail or surfing the web), breaking the flow.

If you are designing a typical software application, preventing distractions in the user’s environment is out of your control. However, in some cases, you or your team may have the opportunity to influence the design of users’ physical workspaces. For example, for an air traffic control center, in addition to the software itself, you may be able to design the workstations and the office facility to prevent distractions.

• Use consistent naming, labelling, icons, and visual presentation to reduce any confusion.
• Try to avoid redundancy so that the same information doesn’t need to be read and processed repeatedly.
• Put related things close together, and avoid forcing the user to switch between different tabs or windows or scroll back and forth to find or enter information.
• Avoid distractions like pop-up dialogs that break the user’s concentration and flow.
• Identify and eliminate any unnecessary steps. You might allow expert users to hide instructions and turn off warning messages.
• If your application has multiple tasks or screens that share similiarities, be consistent in designing the visual appearance and workflow of these tasks and screens, so that once the user has learned how to use one, the same patterns can be applied to the others.
• Automate as much manual work as is reasonably possible. In some cases, though, you may want to allow experts to have the option of doing things manually if they need an extra level of control or precision.
• Where there is a list of steps to be followed, always make it clear how to do the next step. When possible, guide users through tasks with wizard-style interfaces rather than force users to memorize a complex procedure.
• Use visual cues and clues to avoid the need for memorization and recall. Allow options to be selected from menus instead of requiring users to memorize commands.
• Reduce delays and latency as much as possible. Give feedback quickly. If an operation will take a long time, use a progress bar or other indicator to show that the system is busy, and when possible, give an estimate of how much time the remainder of the processing will require.
• Getting started with a blank document can be confusing as users often don’t know where to begin. Where possible, provide templates or “worked examples” so that users can modify an existing document or follow a pattern.
• Avoid forcing the user to memorize data in the short term. For example, I’m aware of one system that required users to make note of a nine-digit customer number, close the window, and then go to another window and re-enter the customer number; this is absurd when the system could remember and fill in this information automatically.

• 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
• Scrolling
• Navigating
• 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
• Problem-solving
• 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.

Design techniques for reducing cognitive load

In the next post, we’ll discuss design techniques for minimizing cognitive load.

One way of building up a mental model in a user’s head is to provide documentation such as a training manual or tutorial. The vast majority of users will never read documentation, however.

For enterprise systems in an organizational setting, you can have your users sit through a training program, but the effectiveness of corporate training varies. The motivation of employees to pay attention and learn is often low, and for training on complex applications, classroom sessions without hands-on practice are essentially useless if you want staff to understand and retain the material.

Some users have the benefit of being able to watch other users use the application, and this can be a very effective way of learning the basic concepts and understanding how to perform tasks. Having an expert nearby whom the user can ask for assistance is also very helpful.

But without any training, documentation, or opportunities to watch and ask other users, the only way a user can figure out how to use the application is to simply start using it. She will learn how to operate the application by trial-and-error. The visual presentation of the application’s user interface provides cues as to how to accomplish tasks, and the behavior of the application provides feedback on whether the tasks are being performed correctly. By exploring and experimenting with the application, the user gradually builds up a mental model of how the application works, and, with time and experience, the user’s mental model will (hopefully) increasingly approximate the designer’s mental model.

To use the terminology popularized by Donald Norman in The Design of Everyday Things, the conceptual model in the designer’s mind is called the design model. The user’s mental model is simply referred to as the user’s model. And the presentation and behavior that the product’s user interface exhibits is called the system image.

And so to design a usable and learnable product, then, the designer’s challenge can be viewed as aligning the design model and the system image, and structuring the system image in such a way that it accurately portrays the design model and enables the user to develop her own user’s model that closely approximates the designer’s model. As the completeness and correctness of the user’s model increases, the user’s skill at operating the application will approach that of the application’s designer.

Structuring the system image to make an application learnable and understandable is tricky, and the fundamental aim of this blog and the upcoming book Designing Usable Apps is to explain how to do this by means of design principles and techniques, and usability testing and evaluation techniques.