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
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-
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
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
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 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
are likely to be speed,
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
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
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.
On the other hand, if the product in question is a kiosk in a corporate lobby helping
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
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.