Recognizing User Goals

So what are user goals? How can we identify them? How do we know that they are real? Are they the same for all users? Do they change over time? We'll try to answer those questions in the remainder of this chapter.

Users' goals are often quite different from what we might guess them to be. For example, we might think that an accounting clerk's goal is to process invoices efficiently. This is probably not true. Efficient invoice processing is more likely the goal of the clerk's employer. The clerk is more likely concentrating on goals like appearing competent at his job and keeping himself engaged with his work while performing routine and repetitive tasks.

Regardless of the work we do and the tasks we must accomplish, most of us share these simple, personal goals. Even if we have higher aspirations, they are still more personal than work-related: winning a promotion, learning more about our field, or setting a good example for others, for instance.

Products designed and built to achieve business goals alone will fail; personal goals of users need to be addressed. When the user's personal goals are met by the design, business goals are far more effectively achieved, for reasons we'll explore in more detail in later chapters.

If you examine most commercially available software, Web sites, and digital products today, you will find that their user interfaces fail to meet user goals with alarming frequency. They routinely:

• Make users feel stupid

• Cause users to make big mistakes

• Slow users down so they don't get an adequate amount of work done

• Prevent fun and/or bore users with navigational tedium

Most of the same software is equally poor at achieving its business purpose. Invoices don't get processed all that well. Customers don't get serviced on time. Decisions don't get properly supported. This is no coincidence.

The companies that develop these products don't have the right priorities. Most focus their attention far too narrowly on implementation issues, which distract them from the needs of users.

Even when businesses become sensitive to their users, they are often powerless to change their products because the conventional development process assumes that user interface should be addressed after coding begins—sometimes even after it ends. But just as you cannot effectively design a building after construction begins, you cannot easily make a program serve users' goals after coding has begun (and certainly not after it has ended).

Finally, when companies do focus on the users, they pay too much attention to the tasks that users engage in and not enough attention to their goals in performing those tasks. Software can be technologically superb and perform each business task with diligence, yet still be a critical and commercial failure. We can't ignore technology or tasks, but they play only a part in a larger schema that includes designing to meet user goals.

Goals versus tasks

Goals are not the same as tasks. A goal is an end condition, whereas a task is an intermediate step that helps to reach a goal. Goals motivate people to perform tasks. It is very important not to confuse tasks with goals, but it is easy to mix them up.

Luckily, there is an easy way to tell the difference between tasks and goals. Goals are driven by human motivations, which change very slowly, if at all, over time. Tasks are transient, based almost entirely on the technology at hand. For example, when traveling from St. Louis to San Francisco, a person's goals are likely to be speed, comfort, and safety. In 1850, a settler would have made the journey in a covered wagon; and, in the interest of safety, he would have brought along his trusty rifle. Traveling from St. Louis to San Francisco today, a businessman makes the journey in a jet aircraft; and, in the interest of safety, he is required to leave his firearms at home. The goals remain unchanged, but the tasks have so changed with the technology that they are, in some respects, in direct opposition.

Looking through the lens of goals allows you to leverage technology to eliminate irrelevant tasks. For example, if you want to get to work in the morning, your goal is to get there as quickly and safely as possible. With today's technology, that means executing the tasks of getting in your car and braving traffic, or perhaps waiting for a train and walking the rest of the way. In the Star Trek future, you can throw a switch and materialize in your office via transporter beam. Looking at goals can similarly help designers eliminate tasks that technology renders unnecessary for humans to perform.

Many developers and usability professionals approach the design of interfaces by asking, "What are the tasks?" Although this may get the job done, it won't produce the best solution possible, and often it won't satisfy the user. When designing an interface, task analysis is useful, but only after user goals have been analyzed. Design based solely on tasks runs the risk of trapping the design in a model imposed by an outmoded technology, or using a model that meets the goals of a corporation without meeting the goals of their users. Asking, "What are the user's goals?" lets us see through the confusion and create more appropriate and satisfactory design.

Designing to meet goals in context

Many designers assume that making interfaces easier to learn should always be a design target. Ease of learning is an important guideline, but in reality, as Brenda Laurel (1990) notes, the design target really depends on the context—who the users are, what they are doing, and what goals they have. You simply can't create good design by following rules disconnected from the goals and needs of the users of your product.

Let us illustrate: Take an automated call-distribution system. The people who use this product are paid based on how many calls they handle. Their most important concern is not ease of learning, but the efficiency with which users can route calls, and the rapidity with which those calls can be completed. Ease of learning is also important because it affects the happiness and, ultimately, the turnover rate of employees, so both ease and throughput should be considered in the design. But there is no doubt that throughput is the dominant demand placed on the system by the users and, if necessary, ease of learning should take a back seat. A program that walks the user through the call-routing process step by step each time merely frustrates him after he's learned the ropes.

On the other hand, if the product in question is a kiosk in a corporate lobby helping visitors find their way around, ease of use for first-time users is clearly the goal.

A general guideline of interaction design that seems to apply particularly well to productivity tools is that good design makes users more effective. This guideline takes into account the universal human goal of not looking stupid, along with more particular goals of business throughput and ease of use that are relevant in most business situations.

It is up to you as a designer to determine how you can make the users of your product more effective. Software that enables users to perform their tasks without addressing their goals rarely helps them be truly effective. If the task is to enter 5000 names and addresses into a database, a smoothly functioning data-entry application won't satisfy the user nearly as much as an automated system that extracts the names from the invoicing system.

Although it is the user's job to focus on her tasks, the designer's job is to look beyond the task to identify who the most important users are, and then to determine what their goals might be and why. The design process, which we describe in the remainder of this chapter and detail in the remaining chapters of Part I, provides a structure for determining the answers to these questions, a structure by which solutions based on this information can be systematically achieved.