What characteristics contribute to a negative user experience?

Posted on July 6, 2012 by Kevin Matz

There are many things that can cause users frustration and annoyance with software. In the previous post, we discussed some “do’s” for creating a positive user experience. Let’s now consider some “don’ts” that can create a negative user experience.

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.

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

What characteristics contribute to a positive user experience?

Posted on July 5, 2012 by Kevin Matz

As designers, we’d like to know what things contribute to a positive user experience, and what things contribute to a negative user experience, so we can work on building the former into our products and avoiding the latter. In other words, we want a list of “do’s and don’ts”.

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.

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

How to design software to encourage flow states, concentration, focus, and productivity

Posted on July 4, 2012 by Kevin Matz

Many kinds of software, including productivity applications like word processors and spreadsheets, and enterprise information systems, are intended to be used for sustained periods of time. Such applications should encourage the user to focus and work productively.

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.

Posted in Psychology for UX Design, Usability, User Experience Design | 1 Comment

Design techniques for reducing cognitive load

Posted on July 3, 2012 by Kevin Matz

In the previous post, we argued that minimizing cognitive load is essential for creating an efficient and enjoyable user experience. Here are some design tips and techniques to consider for reducing cognitive load in your software product:

  • 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.
Posted in Information Architecture, Psychology for UX Design, Usability, User Experience Design, Visual Design | Leave a comment

“Don’t make me think!”: Eliminating excise and reducing cognitive load

Posted on July 3, 2012 by Kevin Matz

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

Posted in Information Architecture, Psychology for UX Design, Usability, User Experience Design | 1 Comment

Communicating your mental model to the user: Design models and the system image

Posted on June 30, 2012 by Kevin Matz

As a user interface designer, you’ll have a conceptual mental model in your mind of how the application works. In order for a user to be able to operate the application effectively, she will have to have a similar mental model in her mind.

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.

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