How to recruit users for usability testing

To conduct effective usability tests, you need to find real users whom you can observe while they use your product.

If you have a consumer product intended for sale to the general public, you’ll need to make sure that your user tests involve a matching diversity of people representative of your target audience.

If you have a specialized niche product, your pool of potential users may be small, but your potential subjects will be more motivated to participate, as your product promises to solve their particular problems and is tailored to their needs. You may have a harder time finding enough suitable users in your local area and so you may need to resort to “distance testing” via teleconferencing and screen-sharing software. Industry publications, professional associations, and discussion forums catering to your target audience can be useful for recruiting suitable participants.

Here are some ideas for sources of potential users:

  • Friends and family
  • Employees in your development team or department
  • Employees from elsewhere in your organization
  • Your existing customers
  • Subscribers to your company/product newsletter or blog
  • People at trade shows and conventions
  • People in your professional network
  • People recruited through advertisements

Recruiting your friends, family, and coworkers is often easier than other methods, but statisticians call this convenience sampling, and convenience samples introduce biases into your results. Your participants may not accurately represent the cross-section of users who will actually be buying and using your product, and so you may draw incorrect conclusions from your observations and usability tests.

If you solicit participants from the general public via advertising, you’ll usually need to offer an incentive, usually cash. But be aware that this can attract a certain kind of people. And there are many people whom you may want to reach but who will never respond: Not many high-powered lawyers earning $300 per hour will take an hour or two out of their busy schedule for a $50 gift certificate, for instance. And introverted individuals are less likely to sign up for usability testing sessions. Again, the main point here is that you need to make sure that the people you’re recruiting are a reasonable sample of your target audience, and if you suspect your sample is not representative, then you need to be aware of potential biases.

Recruiting participants and scheduling meetings can be time-consuming, so you may want to delegate this to an assistant. You also need to plan for the fact that a shockingly large percentage of people will not show up to their appointments. Reminder phone calls the day before the appointment can help, though.

How many users do you need for a usability testing study? One or two participants is too little (though better than nothing); ten is sometimes too many as you’ll usually see patterns emerging by then. Five to eight is a good target to aim for.

Posted in Product Management, Usability, Usability Testing, User-Centered Design | Leave a comment

What user interface designers need to know about how human memory works

Human memory is complex and a little mysterious. Unlike electronic data storage, human memory is not perfectly reliable and predictable. In this section, we’ll take a whirlwind tour of what we know about human memory, and then we’ll think about how we can apply this knowledge to user interface design.

A model of memory

There are a number of psychological models of human memory. Most distinguish between short-term and long-term memory as separate but interrelated structures or systems in the brain. While there is no consensus on the “correct” model, one model useful for us is as follows:

  • Short-term memory or working memory is a temporary store that can hold a small amount of information, such as a handful of words, numbers, or symbols, related to your current train of thought. Working memory decays very rapidly; the information can be lost when your attention is drawn to something else, and so you often have to repeat the information to yourself to avoid having it disappear. The capacity of working memory is said to be about “seven, plus or minus two” items (Miller, 1956), and it’s for this reason that North American phone numbers were chosen to be seven digits long — it’s difficult to hold more than about seven digits in your mind if you’ve heard a phone number and you’re trying to write it down.
  • Middle-term memory or contextual memory holds information required for you to be able to work on your current activity, but you won’t permanently remember most of this information. For example, during a conversation, you’ll have in mind the details of what has been discussed so far. Or if you’re working on your income tax return, you’ll know where on your desk you’ve put your different papers and receipts and you’ll remember some of the key numbers and details.
  • Long-term memory is a more persistent store of knowledge and memories of experiences — facts, concepts, ideas, names, images, sounds, voices, places, emotional feeling states, and so on. Long-term memory also stores procedures and skills, for both cognitive and sensory-motor tasks. Long-term memory might alternatively be called “permanent memory“, but this is misleading as information is often subject to forgetting or “false recall”.

How does memorization happen?

Memorization, or committing something from short-term memory to long-term memory, most commonly involves repetition. The more often you encounter (see or hear) something, the more likely you are to remember it later. Studying involves actively intentionally re-reading, rehearsing, and practicing.

But we also tend to remember information and experiences that are surprising, novel, or unusual without any repetition.

The exact nature of how the brain forms memories remains unknown, but it is likely that information and memories stored in long-term memory are somehow stored symbolically. That is, if you hear a professor telling you information in a lecture, you may memorize much of the information in the lecture, but you will probably not store a perfect audio recording of the professor’s lecture. You may of course remember the professor’s voice, especially if it is particularly unique, but this is separate from the information content of the lecture, which you can make use of in practical contexts without “playing back” the “audio recording” of the professor’s voice.

There are some rare people who do have a perfect “photographic” memory, though, and most people can remember music precisely enough that they can distinguish if a later performance differs by only one note.

We tend to store information in logical groupings or chunks, and memorization is most effective when a chunk is associated with other existing chunks of information in memory. Associations are logical connections or relationships between pieces of information. If you meet and get to know a new person, for instance, you’ll associate the image of their face with their name and their other personal details, like their occupation and family members.

If you are trying to learn a complex concept or process, and you feel that your understanding is incomplete or insufficient because of unanswered questions, memorization and later recall will tend not to be as reliable as when you feel that you have a complete and logical understanding of the matter.

Recall and recognition

Recall of information from long-term memory is usually triggered by some cue. Seeing someone’s face, for instance, will typically trigger you to recall that person’s name.

Successful recall is never guaranteed. The more recently the information was memorized or accessed, though, the more likely you are to be able to recall it (the recency effect).

Successful recall of some piece of information is also more likely to occur when you’ve already recalled related information. It’s as if related information is stored in adjacent locations in the brain, and by accessing information in a particular region, “lighting up” that region, recalling other related information from that region becomes easier.

Sometimes you will struggle to recall something, and the information may or may not “come to you” at a later time. Sometimes recall is inaccurate; you recall incorrect information. You might misremember a formula when you’re taking a math test, for instance. Sometimes you may have doubt about whether the recalled information is correct, but just as frequently, you may not recognize the error.

Often you may not be able to recall something, but you can recognize it when you see it. The information was in your memory, but for some reason it was “shrouded” and didn’t lend itself to being accessed at that moment.


The less frequently a chunk of information is accessed from long-term memory, the more likely it is to be forgotten. This is natural — things that are relevant to your daily routines will be remembered, and additionally reinforced due to the recency effect. On the other hand, facts that you studied years ago but haven’t needed since, or the names of people whom you met years ago but haven’t kept in contact with since, will tend to fade away.

But there are also many cases where letting information or skills languish for long periods of time won’t necessarily guarantee that they will be forgotten. Highly-developed motor and cognitive skills that can be done unconsciously after much practice — like riding a bicycle or speaking a foreign language — can often still be performed with surprising levels of competence after years of neglect.

What all of this means for user interface design

On the basis of this understanding of memory, memorization, recall, and forgetting, here are some guidelines to keep in mind when designing software:

  • Structure your interface to reduce or eliminate the need to memorize and recall things. Donald Norman introduced the notion of “knowledge in the world versus knowledge in the head“. For example, if you present a list of options in a menu, this knowledge is “in the world”: the user can view the menu, recognize the options, and make a selection without needing to memorize or recall anything. If you were to require the user to enter commands at a command-line interface, on the other hand, this would require the user to memorize the commands — thereby storing the “knowledge in the head” — and then the user must recall the names of the commands from memory.
  • If a task has a defined sequence of steps, guide the user through the task workflow step-by-step using a “wizard” interface or something similar. Don’t force the user to remember a series of commands or how to navigate to various different screens to finish the task.
  • While shortcut keystrokes and command-line interfaces are often appreciated as time-savers by advanced users, you shouldn’t make these the sole means of interaction as they require memorization and recall. If you must rely on shortcuts or commands, make it is easy to refer to a quick-reference chart or other help material.
  • Make icons and names easily recognizable so that they can be found easily when scanning a list or menu. Icons can be clarifying if the image represents something concrete and recognizable, but if the user has to memorize and recall what an peculiar or abstract icon really means, then it defeats the purpose of using a graphical icon. Consider showing the image and text together if the icon is abstract or its meaning is unclear.
  • If the user will have to work with ID numbers such as product or customer numbers, it can be advantageous to limit these to about 7 or fewer digits or characters in length, if possible, so that it’s easier to temporarily store the numbers in working memory.
  • Arbitrary names are harder to remember and recall than names that accurately describe what they represent. When names don’t match what they actually represent, not only do they become problematic to learn, but the additional memorization and recall adds to the user’s cognitive burden. Commands in the Unix operating system shell are particularly bad at violating this prinicple. For example, most Unix systems offer a command called “less” for showing the contents of a text file. The name “less” is a play on words; “less” is an improvement of another command called “more”. (“more” is a filter command that lets you view a stream of data in a page-by-page fashion.)  The name “less” doesn’t in any way communicate what that command does; it’s a dumb pun by somebody trying to be clever. “list” would be an example of a more appropriate, obvious, and memorable name.
  • Offer a good online help system or other reference documentation so that, when the user has forgotten something, it can be looked up again quickly.
  • In search and index systems, allow the user to use synonyms and variations in case they can’t recall the exact word or phrase (or the correct spelling of the word or phrase) needed to identify something.
  • Try to use commonly accepted, well-known, standard names for things rather than inventing your own terminology. Avoid using abbreviations or acronyms if they are not immediately obvious.
  • Be consistent; don’t make the user remember different ways of doing the same thing in different contexts. I’m familiar with one system where some drop-down lists had to be opened with a Ctrl+L keystroke combination, while other drop-down lists had to be opened with Alt+F11. (An absurd situation, given that in all other systems, drop-down boxes can be opened just by clicking on them.)
  • Because first impressions are rarely forgotten, do everything you can to make sure your product gives a great first impression!
Posted in Information Architecture, Psychology for UX Design, Usability, User Experience Design | Leave a comment

How users’ skills and competence improve with practice

As users gain experience with using a product, their skill tends to improve in the following ways:

  • Increasing knowledge of the product’s capabilities (what it can do)
  • Increasing knowledge of how to perform tasks, and how to deal with special cases
  • Increasing speed
  • Decreasing error rate
  • Increasing confidence

In general, one might also expect the quality of the work done to increase as well. But the quality of work is difficult to define and measure. For rote, repetitive, mechanical work, simply getting the work done quickly and with few errors makes it high-quality work, and so more practice will almost always lead to better quality work. For creative tasks, not only is judging quality a very subjective and inherently unmeasurable affair, but also more practice will not necessarily guarantee better quality work. If someone’s a bad artist with no visual design sense, then if learning and becoming competent with Photoshop’s features will not necessary make his artwork more visually appealing.


The most reliable way to get better at something is to practice — that is, to repeatedly perform (or rehearse the performance of) a task.

In some situations, practice “just happens” — you may have a job where you have to do some activity repeatedly, and so you gain practice and thereby get better at the activity because it’s just a part of your work. Card et al. (1983, p. 188) observe that “people generally become skilled in whatever becomes routine for them.”

But if you are intentionally practicing with focused attention, having in mind the specific goal of improving your skill, and challenging yourself to work at increasing levels of difficulty, you can be said to be engaging in deliberate practice. Deliberate practice also involves carefully monitoring and evaluating your own work and actively seeking out ways to improve it.

As users gain experience with an activity through repetitive practice, their performance improves rapidly at first, but the rate of improvement gradually slows down until a peak performance level is reached.

For most tasks, the average time taken to complete the task declines with practice in this way, and the Power Law of Practice is a mathematical description of this effect, verified by psychological experiments. The Power Law of Practice can be illustrated graphically with the following illustration:

Power Law of Practice

Power Law relationships may or may not apply to other quality metrics besides task completion time. According to Card et al. (1983, p. 59), the Power Law of Practice applies to most mechanical (“sensory-motor”) and cognitive skills, but does not apply to learning in the sense of knowledge acquisition.

Skills atrophy

Without continual ongoing practice, skills will gradually tend to atrophy or “fade” over time. In general, motor skills (like riding a bicycle) do not atrophy as quickly as knowledge-based skills (like long division). But atrophied skills can be refreshed and improved again with revision and practice.

Attaining competence

Another useful model of how people improve at an activity is the Four Stages of Competence model. According to this model, a user goes through the following stages in mastering a skill:

  • Unconscious incompetence: The user is unaware of how bad he is at the skill (and may even be completely unaware of the skill).
  • Conscious incompetence: When attempting the skill, the user gradually becomes aware of his deficiency in the skill area. The user realizes that he will have to learn and practice to improve at the skill, and this can sometimes be a overwhelming and daunting realization.
  • Conscious competence: By means of practice, the user becomes able to perform the activity competently but slowly. Perfoming the activity requires a lot of concentration, focus, and effort.
  • Unconscious competence: The user is able to do the activity effortlessly, naturally, automatically, and quickly without consciously thinking about it. The skill has become “second nature”.

To better understand these stages, you might try thinking back to your personal experiences of learning to drive an automobile. You probably went through these four stages, and today you are probably so “unconsciously competent” that you can do other things — like eating, or singing along to songs on the radio — while driving.

Judging competence

If you are conducting usability studies or questionnaire surveys, you should be aware that people tend to be very poor judges of their own competence. People who are incompetent at a particular activity tend to grossly overestimate their level of skill, and additionally are not very adept at judging the skill levels of those who are more competent. Conversely, many experts, often because they are acutely aware of how much they still do not know, tend to underestimate their own level of skill. This phenomenon is known as the Dunning-Kruger effect.

Teaching skills to users must include practice

Simply telling or showing someone how to do something is rarely sufficient. Training or education has to include hands-on practice for it to be effective.

Posted in Psychology for UX Design, Training, Usability, User Experience Design | Leave a comment

Designing software for different user skill levels

As a user interface designer, you’ll need to think about how you will make your software product understandable and learnable for beginners while at the same time not hindering experts from working productively.

The general skill levels of people using an application might be categorized as follows:

  • An evaluator is investigating your product; she has not committed to the product yet, but may be considering buying or adopting it. An evaluator explores a product to see what the product can do, to determine whether it meets her needs, and to get a general impression of how it works. There is no particular pressing goal or task at hand; the user is just exploring and experimenting with the product.
  • A beginner is someone who is trying to accomplish tasks with the product, but has little or no past experience with the product, and thus may not know how to complete the tasks. Beginners often have feelings of uncertainty, and gradually learn by trying things out, exploring, observing, and learning from mistakes. Some — but certainly not all — beginners will seek out and make use of documentation such as tutorial guides, help systems, or reference manuals.
  • An intermediate user has used the product for some period of time and is generally able to accomplish her goals and tasks. However, the intermediate user may not have explored all of the product’s functionality, and may still be uncertain about some tasks; “fluency” has not yet been achieved. And because some users may only use the product sporadically (for instance, tax preparation software is usually only used once a year), or because some features may be used very infrequently, the user may have forgotten how to do some tasks, despite having done them in the past. The book About Face 3 (Cooper et al., 2006) suggests the term perpetual intermediates to refer to users who use the application sporadically and never really get the chance to become experts.
  • An expert user is very confident and has a deep understanding of the domain and the product. An expert can not only complete tasks without difficulty, but is concerned with getting things done as efficiently and quickly as possible. When faced with a new or unexpected situation, an expert can often reason about how the product works and find a solution or workaround.
  • A power user is an expert user who has a particular fascination with the product and often enjoys customizing it and stretching its limits.

So when you’re designing an application, you should think about how to make it suitable for each level of user:

  • For evaluators, the product must give a good first impression. It should look appealing and inviting and not overwhelmingly complex. You might consider offering demo videos so the user can quickly understand what the product does and how it works. Walk-through tutorials with step-by-step instructions can be useful. If applicable, consider providing sample files or documents that the user can open and experiment with in the application.
  • For beginners, use visual design, information architecture, and interaction design principles to make the product’s functionality easily discoverable and learnable (we’ll discuss these in depth in later sections). Offer wizards for setting up projects or to guide the user through complex tasks. Offer undo/redo functions to encourage experimentation and to make it easy to correct mistakes. Offer in-depth tutorials and introductory guides, either as manuals, or as online help content.
  • For intermediate users, offer indexed and searchable online help so that instructions can be easily located.
  • For expert users, ensure that tasks can be completed as quickly and efficiently as possible. Provide shortcut keys, and allow users to bypass wizards and turn off any pop-ups or other aids intended to offer help to beginners.
  • Power users often want to be able to customize the application, and, if applicable, may expect to be able to write scripts to automate some tasks. Online discussion forums might be provided for these users to exchange tips and tricks.

We should also note that the ability of users to learn and use your product is also influenced by the following factors:

  • Domain knowledge: If your product is an accounting package, for instance, users who have never heard of debits and credits and journals and ledgers will be completely puzzled, no matter how well-designed the interface is.
  • General skill with computing/technology: Unless you’re specifically targeting total computer newbies, it’s usually reasonable to assume that your users have the basic skills to operate similar applications on the device and/or operating system of choice. For instance, you’ll probably assume that users know how to use a mouse or touchscreen, and are aware of concepts like opening and saving files.
  • General intelligence and reasoning capacity: When faced with new situations, some people are simply more intellectually curious and more capable of problem-solving than others.
  • Persistence and motivation: When faced with challenges, some people will give up easily, while others will keep trying and experimenting.

You may have to make some basic assumptions about what minimum skills and knowledge you will expect new users to have. Because it’s not your job to train total newbies who don’t know how to turn on a computer and operate a mouse, for instance, you may simply declare that such people are simply outside of your target market.

But you have to make sure that your assumptions really match the reality of your marketplace. If you’re selling shrink-wrapped accounting software, most of the buyers will be first-time small businesspeople who have never taken an accounting course. And so including a “Getting Started” guidebook or video that introduces just enough concepts and terminology to get started with basic tasks might be what you need to prevent frustrated customers from returning your product to the store.

Posted in Information Architecture, Product Management, Psychology for UX Design, Usability, User Experience Design, User-Centered Design | Leave a comment

Security usability: Designing usable software security measures

Security is critical in many software applications, but security measures often are seen as annoyances that negatively impact the user experience.

The essential purpose of security, however, is to protect users (and other stakeholders) from more serious negative experiences. For example, having to remember a complex password is annoying. But it reduces the chances of much worse experiences: losing access to your account, having your data stolen, deleted, or tampered with, having fraudulent transactions conducted on your behalf, or having someone impersonate you.

Thus, like so many issues in software design, there is a trade-off between security measures and usability. Let’s survey some common security mechanisms and issues and examine them from a usability perspective.


Authentication refers to the process of identifying the user and verifying that they are who they say there are.

To gain access to a system, a user must prove that they are somebody who has been granted permission to access that system, and this is done by providing proof of identity. Most computer systems implement this by challenging the user to provide a username and password. The username can exist only if an account has been granted to a particular approved person, and only that person should know the password for the account. And so by providing the correct password, the user is “proving” that they are who they say they are.

Since passwords are so easily guessed or stolen, they are a weak means of identification, but passwords persist because they are cheap and easy to implement. Physical tokens like ID badges or keycards, or biometric identification using fingerprints or retinal scans, are alternative but costlier means of identification. High-security installations tend to combine physical tokens or biometric identification together with a password, so that if one half is compromised (e.g., a keycard is stolen), an intruder still cannot gain access.

Short passwords can be easily guessed or “cracked” using brute-force algorithms, so requiring passwords to be of a certain minimum length, and requiring passwords to include characters from an extended character set (numbers, punctuation symbols, etc.) can greatly reduce the chances of hackers gaining illicit access. Complex passwords come at the cost of irritating users, though, who quite understandably have a hard time remembering the passwords for all of the systems and websites they interact with.

Likewise, requiring users to change their passwords every few months is recommended by security experts, but users tend to resent this added memorization burden.

The strictness of the security requirements should match what is at stake. An Internet discussion forum does not require the same security as a banking website, and a banking website does not require the same measures needed for a classified military installation.

Security violations like intrusions and leaked passwords are highly embarrassing, and so your product’s technical architects must ensure that they are employing current best practices for implementing the security system. Security audits are worthwhile if your organization can afford them.

In enterprise information systems, applications are often constructed by cobbling together several off-the-shelf products. It is highly unpleasant if the user has to log in with separate usernames and passwords every day to access, say, the Customer Relationship Management application, the workflow application, the reporting application, and so on. A single sign-on solution is recommended for such systems so that a single login grants the user access to all of the component applications.

Automatically logging out the user after a period of inactivity is a measure designed to reduce somewhat the chances of a malicious user taking over a user’s session when the user leaves the machine unattended. To reduce annoyance, however, the timeout period should not be so short that the user will be logged out during normal operation, and when the user re-authenticates himself, the system should resume where it left off.

Authorization (access control)

Authorization, also known as access control, refers to controlling what each particular user is allowed to access. Which functions are permitted, and which functions are prohibited? What information can be viewed and edited, and what is off-limits?

Rather than controlling access to individual users, most systems define roles. Users can then be assigned to one or more roles. An access control matrix can then be created to define what functions members of each role are permitted to access:

Functions Teller Loan Officer Branch Manager
Process withdrawal yes no yes
Process deposit yes no yes
Process mortgage application no yes yes
Approve mortgage no yes yes
Override default interest rate no no yes

Access control is often overlooked when user interface designers produce initial sketches and mockups, and it tends to be haphazardly added later. A key decision to be made involves the presentation of the menu items and buttons for functions that the current user is prohibited from accessing. Should these controls be hidden completely, or should they be shown in a disabled state (i.e., greyed out)?

With greyed-out controls, it might not always be obvious to the user that the reason why the control is greyed out is because of an access control restriction. Users in some cases might think that the application is simply in the wrong mode, for instance, and might waste time trying to figure out actions needed to re-enable the controls.

Hiding controls can be an attractive option because it produces less clutter, but it can also cause confusion if a user is looking for something they’ve seen before (perhaps while watching a coworker use the application) and cannot find it. Hiding controls can also cause layout issues; if the layout is static, there will be empty gaps where the controls used to be, and if the layout is dynamic, controls that were nicely aligned may no longer be nicely aligned once some of them disappear. Additionally, the same screen will appear differently when users with different roles log in, and so if you include screenshots in the documentation and help content, and if the user’s permissions differ, the screenshots may not match what the user is looking at.

Fraud prevention

Enterprise systems that deal with financial transactions often must consider fraud prevention. If a user can issue a payment, for instance, what is stopping her from issuing a few payments to herself? If the system is structured so that payment transactions must be reviewed and approved by a peer coworker or a manager (this is sometimes called the two-man rule or the four-eyes principle), and if all transactions are permanently recorded and logged, then this kind of fraud is less likely to occur, as there is a risk of getting caught and reported if someone were to seek out a collaborator.

Posted in Information Architecture, Psychology for UX Design, Usability, User Experience Design | Leave a comment

Designing error-handling for maximum usability in your application

The way a software application handles errors can have a big impact on user satisfaction and usability, and so error handling deserves close attention from user interface designers.

Errors are unexpected or undesirable situations that prevent the normal operation of the application. We might classify errors by their general types and severities:

  • The worst type of error is the unrecoverable crash, where the program abruptly stops due to a programming error that usually involves an unforeseen situation. Extensive testing and careful code inspections can reduce but never completely eliminate the possibility of such cases in a complex system.
  • Technical errors are programming errors that prevent some task or action from being completed, but do not crash the entire application.
  • Transient technical errors are situations that arise that temporarily hinder proper operation, but which can usually be corrected by taking actions outside of the application. For example, a database connection or network connection might be lost, a disk is full, etc.
  • Data validation or rule violation errors are cases where the application has detected that the data does not meet some criteria for validity. The system cannot function correctly if the data remains in this state, and so the user is notified and the user is expected to correct the data.
  • Warnings are cases where the application detects a situation that doesn’t prevent operation but which may have consequences that the user might not want or expect.

We should also note that if the system interacts with the real world, programming mistakes and invalid data can lead to “error-like situations” in the world. For instance, if your application prints out checks but the address on the check or envelope omits the postal code, they may not be deliverable by the postal system, and the recipients won’t receive their checks.

Errors usually occur as a result of the user taking some action, although sometimes a system will report an error “out of the blue” when a background process has encountered a failure or when some data has been received from another system. Data-entry forms are one of the most common places where errors are identified and presented. In most data-entry forms, the data must be checked for completeness and validity before the task flow can continue.

Usually, the user is informed of errors by means of error messages, which may be presented in pop-up dialogs, in lists (when there are multiple errors), or in “callout” messages alongside fields in a data-entry form. In some applications, you may be able to indicate errors using highlighting or non-textual symbols. For example, word processors often highlight misspellings with squiggly red underlines, and cells with formatting errors in Microsoft Excel are marked with a colored triangle.

When writing error messages, here are some guidelines to keep in mind:

  • Ensure that error messages are carefully worded so that they clearly identify the problem in a way that your users will understand. If possible, explain how to proceed to resolve the issue. In enterprise systems, you may ask the user to notify the helpdesk; in such cases, you should provide an error number so that the helpdesk staff can easily identify the error.
  • Try to ensure that error messages are at a suitable level of abstraction for the user. Complex software systems are built upon stacked “tiers” or layers of abstractions, and an error message generated in a low-level component may be too technical or obscure to be exposed to the user without translation into a more user-friendly form.

For example, when trying to save information to a database, if a required field is missing, the database might generate an error such as “ORA-01400: cannot insert NULL”. This type of message is baffling to average users. It describes a technical situation that the user does not understand and cannot access, and it doesn’t pinpoint what or where the actual problem is, or what the user should do to solve it. If the system cannot prevent these types of errors through better program design (validation at a higher level of abstraction), it should “catch” these errors and relay a more suitable error message such as “Please enter a value for the Due Date field”.

There are cases where the details of the error are necessary for technicians to properly investigate the error. As a compromise, you may choose to present “sanitized” error messages to users, but save the technical error messages to a log or database for inspection by the support team and developers.

  • Avoid blaming or criticizing the user. Many users feel guilty when the system is reprimanding them for a mistake they have made, when it is often the design of the system that is really at fault. When the error is a system exception and the user is not at fault, the error text should reassure the user that she has done nothing wrong. If the error has caused the user some inconvenience, it is courteous to apologize for the error.
  • When an error message is presented, you may wish to aid users by offering help or suggestions for resolving the issue. This is very useful for new users, but cumbersome for experienced users, especially when the explanations are very detailed. (The IBM DB2 database system’s error messages are sometimes over a page long and scroll off the screen!) For error messages that contain lengthy explanations, ensure that there’s an emphasized summary or “headline” so that experienced users can identify and refer to the error easily. Or you may consider presenting only the brief summary, and then allow the user to click a button to access help content relating to the error.

Here are some more tips and guidelines for thinking about how to handle and present errors in your application:

  • Let the user correct errors and mistakes easily. Allow the user to undo an operation or retry an action without losing data or having to start over from scratch. For validation errors, allow the user go back and correct the erroneous fields without having to re-enter all of the data on the form.

One study found that expert users of word processors spend about 30% of their time correcting typographical mistakes (Card et al., 1983, p. 423). Because of the amount of time spent on error correction, improving the efficiency and ease of correcting errors can greatly increase productivity and reduce frustration.

  • For validation errors, whenever possible, show the error messages in proximity to what is causing the error. If a field is invalid, try to place the error message alongside it. Don’t put a list of errors on another page or in a pop-up dialog and then expect the user to navigate back and find the errors. However, some validation errors involve multiple information sources, and in these cases it may not be so simple.
  • Color can be used to highlight errors (e.g., marking invalid fields with a red border or background), but don’t make it the only signal, because it may not be noticeable to visually-impaired or color-blind users.
  • Obviously, whenever possible, try to design the system so that error conditions simply cannot occur in the first place. If a mortgage calculator requires the interest rate to be within a certain range, a “slider” control that constraints the interest rate so that it can never exceed that range will prevent any error. As another example, the user may be unsure of the correct date format to enter in a date field. If you pre-fill the field with the default due date (in the correct format), or if you let the user pick the date with a calendar control, there will be fewer chances for entering the format incorrectly.
  • Make sure that the user is aware of important error messages. One system I’ve used displayed error messages in the status bar at the bottom of the screen, and the user was not always aware that the message in the status bar had changed. (Using the status bar for displaying errors also has the problem that it can only show one message at a time.)
  • Non-critical warning messages that are presented repeatedly can quickly become a nuisance. You may wish to allow the user to check a “Do not show me this warning again” box to suppress these warnings.
  • It is better to catch and report errors early rather than allow invalid data to lead to further errors later. It is much better to use data validations to ensure information is correct instead of letting it pollute later calculations and operations, which may lead to additional, more complex errors.
  • For transient technical errors such as a broken network or database connection, the system might want to retry the operation several times before generating an error message.
  • Some types of errors and mistakes made by the user can be automatically corrected by the system. For example, Microsoft Word can auto-correct common spelling errors. Some systems let the user enter dates in virtually any format, and the system then converts it to the preferred format.

When the system performs an auto-correction, there should be clear but unobtrusive feedback so that the user is aware of what has happened and can verify that the correction is in fact correct. You should also allow the user to disable this behavior, because there is nothing more arduous and frustrating than correcting unwanted auto-corrections.

  • Critical technical errors, especially those that cause program crashes, should be reported to your support team or helpdesk for eventual investigation and fixing by the development team. Investigators will need sufficient diagnostic information (stack traces, system configuration, etc.) to understand the context and recreate the error.

Although you can ask users to submit a bug report or trouble ticket, and copy-and-paste error details into an e-mail or online form, extraordinarily few will do so, because it is time-consuming and the user receives no immediate benefit. It is preferable if the diagnostic information can be provided electronically to the support team. In a web application, the server can simply record these errors in a log or database, but in a desktop or mobile app, you usually need to ask permission to transmit data to a server. Ensure that privacy laws involving the use and protection of personal data are respected.

  • Some systems must allow invalid or incomplete data to be saved. Investment brokerage systems, for instance, often require a number of documents to be submitted before an account can be opened, and multiple errors will accumulate if documents are missing or information is incomplete. It may take weeks for the proper documents to be received. Some pension administration systems even allow the user to intentionally override certain errors so that preliminary benefit estimates can be calculated even when some information is missing or invalid. In these systems, the errors have to be resolved before some key final task (such as “open the account”) can be completed.

In systems that permit these “persistent” errors, users must be able to easily access the list of errors. Ideally, the user should be able to click on an error to navigate to the place where the error can be corrected. And in workflow-driven systems, reports or alerts should alert staff to cases that have been left “hanging” for some length of time.

Dealing with errors is always an unpleasant situation for users. Careful attention to user interface design and an effort to reduce the number of errors that users will be presented with can greatly improve the user experience.

Posted in Information Architecture, Usability, User Experience Design | Leave a comment