Goals

If personas provide the context for sets of observed behaviors, goals are the drivers behind those behaviors. A persona without goals can still serve as a useful communication tool, but it remains useless as a design tool. User goals serve as a lens through which designers must consider the functions of a product. The function and behavior of the product must address goals via tasks—typically, as few tasks as absolutely necessary. Remember, tasks are only a means to an end; goals are the end themselves.

Goals motivate usage patterns

People's or personas' goals motivate them to behave the way they do. Thus, goals provide not only an answer to why and how personas desire to use a product, but can also serve as a shorthand in the designer's mind for the sometimes complex behaviors in which a persona engages and, therefore, for the tasks as well.

Goals must be inferred from qualitative data

You can't ask a person what his goals are directly: Either he won't be able to articulate them, or he won't be accurate or even perfectly honest. People simply aren't well prepared to answer such questions accurately. Therefore, designers and researchers need to carefully reconstruct goals from observed behaviors, answers to other questions, non-verbal cues, and clues from the environment such as book titles on shelves. One of the most critical tasks in the modeling of personas is identifying goals and expressing them succinctly: Each goal should be expressed as a simple sentence.

Types of goals

Goals come in many different varieties. The most important goals from a user-centered design standpoint are the goals of users. These are, generally, first priority in a design, especially in the design of consumer products. Non-user goals can also come into play, especially in enterprise environments. The goals of organizations, employers, customers, and partners all need to be acknowledged, if not addressed directly, by the product's design.

USER GOALS

User personas have user goals. These range from broad aspirations to highly pragmatic product expectations. User goals fall into three basic categories (Goodwin, 2001):

• Life goals

• Experience goals

• End goals

We describe each of these in detail in the following sections.

LIFE GOALS Life goals represent personal aspirations of the user that typically go beyond the context of the product being designed. These goals represent deep drives and motivations that help explain why the user is trying to accomplish the end goals he seeks to accomplish. These can be useful in understanding the broader context of relationships the user may have with others and her expectations of the product from a brand perspective.

• Be the best at what I do

• Get onto the fast track and win that big promotion

• Learn all there is to know about this field

• Be a paragon of ethics, modesty, and trust

Life goals rarely figure directly into the design of specific elements of an interface. However, they are very much worth keeping in mind. A product that the user discovers will take him closer to his life goals, and not just his end goals, will win him over more decisively than any marketing campaign. Addressing life goals of users makes the difference (assuming other goals are also met) between a satisfied user and a fanatically loyal user.

EXPERIENCE GOALS Experience goals are simple, universal, and personal. Paradoxically, this makes them difficult for many people to talk about, especially in the context of impersonal business. Experience goals express how someone wants to feel while using a product or the quality of their interaction with the product.

• Don't feel stupid

• Don't make mistakes

• Feel competent and confident

• Have fun (or at least not be too bored)

Experience goals represent the unconscious goals that people bring to any software product. They bring these goals to the context without consciously realizing it and without necessarily even being able to articulate the goals. People have an unconscious desire to be treated with decency and dignity and to be supported, not chastised. When software makes users feel stupid, their self-esteem drops and their effectiveness plummets, regardless of their other goals. Their level of discomfort and resentment also increases. Enough of this type of treatment and users will be primed to use any chance to subvert the system. Any system that violates personal goals will ultimately fail, regardless of how well it purports to achieve other goals.

END GOALS End goals represent the user's expectation of the tangible outcomes of using a specific product. When you pick up a cell phone, you likely have an outcome in mind. Similarly, when you search the Web for a particular item or piece of information, you have some clear end goals. When you open a document with a word processor, you have something in mind that you expect to accomplish. End goals must be met for users to think that a product is worth their time and money; most of the goals a product needs to concern itself with are, therefore, end goals such as the following:

• Find the best price

• Finalize the press release

• Process the customer's order

• Create a numerical model of the business

COMBINING END GOALS AND EXPERIENCE GOALS End goals have more appeal than experience or life goals, especially to sober businesspeople and programmers. True to their nature, they create software that—although it admirably fulfills the end goals—fails utterly to satisfy the experience goals of the user. Even if end goals are recognized and satisfied, users feel poorly about themselves and the product if experience goals are not also met. Sure, they get their work accomplished, but it's not a pleasant or empowering experience. On the other hand, if your software ignores the practical and serves only the user's experience goals, you have designed a toy, not a business application.

NON-USER GOALS

Customer goals, corporate goals, and technical goals are all non-user goals. Typically, these goals must be acknowledged and considered, but they do not form the basis for the design direction. Although these goals need to be addressed, they must not be addressed at the expense of the user.

CUSTOMER GOALS Customers, as already discussed, have different goals than users. The exact nature of these goals varies quite a bit between consumer and enterprise products. Consumer customers are often parents, relatives, or friends who often have concerns about the safety and happiness of the persons for whom they are purchasing the product. Enterprise customers are typically IT managers, and they often have concerns about security, ease of maintenance, and ease of customization. Customer personas also may have their own life, experience, and especially end goals in relation to the product if they use it in any capacity. Customer goals should never trump end goals, but need to be considered within the overall design.

CORPORATE GOALS Businesses and other organizations have their own requirements for software, and they are as high level as the personal goals of the individual. "To increase our profit" is pretty fundamental to the board of directors or the stockholders. The designer uses these goals to stay focused on the bigger issues and to avoid getting distracted by tasks or other false goals. Corporate goals include the following:

• Increase profit

• Increase market share

• Defeat the competition

• Use resources more efficiently

• Offer more products or services

Psychologists who study the workplace have a term, hygienic factors, which Saul Gellerman (1963) defines as "prerequisites for effective motivation but powerless to motivate by themselves." The lights in your office, for example, are hygienic. You don't go to work because the lights are nice; but if there were no lights at all, you wouldn't bother showing up.

Corporate goals are hygienic factors in this sense. From the corporation's point of view, it has important goals. But the corporation isn't doing the work; its people are, and their more personal life, experience, and end goals are equally decisive.

Corporate goals can't be slighted, however. Software that fails to achieve them will fail just as readily as software that fails to meet user goals.

TECHNICAL GOALS Most of the software-based products we use everyday are created with technical goals in mind. Many of these goals ease the task of software creation, which is a programmer's goal. This is why they take precedence at the expense of the users' goals.

• Save memory

• Run in a browser

• Safeguard data integrity

• Increase program execution efficiency

• Use "cool" technology or features

• Maintain consistency across platforms

Technical goals in particular are very important to the development staff. It is important to stress early in the education process that these goals need to serve user and business goals. Technical goals should derive from the need to meet other more human-oriented goals. It might be a software company's task to use new technology, but it is never a user's goal to do so. As users, we don't care if we get our job done with hierarchical databases, relational databases, object-oriented databases, flat-file systems, or black magic. What we care about is getting our job done swiftly with a modicum of ease and dignity.

Successful products meet user goals first

Designing a good interactive product has meaning only for a person using an artifact for some purpose in some context. You cannot have purposes without people. The two are inseparable. That is why a key tool in the process of designing behavior is personas: specific people working towards specific purposes or goals.

The most important purposes or goals to consider are those of the individuals making actual use of the artifact or application, not necessarily those of its purchaser. A real person interacts with your product, not a corporation or even an IT manager, so you must regard his personal goals as more significant than those of the corporation who employs him or the IT manager who supports him. Your users will do their best to achieve their employer's business goals, while at the same time looking after their own personal goals. A user's most important goal is always to retain his human dignity: not to feel stupid.

We can reliably say that we make the user feel stupid if we let him make big mistakes, keep him from getting an adequate amount of work done, or bore him.

AXIOM 

Don't make the user feel stupid.

This is probably the most important interaction design guideline. In the course of this book, we examine numerous ways in which existing software makes the user feel stupid, and we explore ways to avoid that trap.

The essence of good interaction design is devising interactions that achieve the goals of the manufacturer or service provider and their partners without violating the goals of users.