Goal-Directed Software Design

From the UI to the underlying architecture, user satisfaction is what's important

Alan Cooper

Alan developed the method of designing software described in this article, naming it "Goal-Directed Design.(tm)" Cooper Software, his design consulting company, uses it exclusively. Alan is best known as the Father of Visual Basic and author of About Face: The Essentials of User Interface Design (IDG Books, 1995). You can contact him at [email protected] or http://www.cooper.com.

By assuring that your software moves users inexorably toward their goals, you can design programs that are deeply satisfying and effective. In this article, I'll present a methodology called "Goal-Directed Design" that makes this possible, allowing you to eliminate unnecessary features from your software, separate good design ideas from bad ones, and create software that makes users happier and more productive.

To illustrate how this method works, suppose you are designing a group-calendaring program in which users coordinate meetings (and other activities) by drawing on a calendar. The number-one task performed by almost all group-calendaring software is to create meetings. However, the number one goal of almost all users of group-calendaring software is to avoid meetings-at least to avoid needless, unproductive meetings. This contradiction-where the user's goals and the program's tasks are in direct opposition-is symptomatic of the failure of our current design methods to work effectively. What's more, this contradiction is found almost universally in our software, regardless of its type.

Goals versus Tasks

It is easy to confuse goals with tasks, but the two are very different and are often in direct opposition to each other. For example, doctors-whose goal it is to keep you healthy-spend all of their time and energy curing your illnesses.

The confusion is rampant in computer systems, too. The programmer's task is to ensure that the program doesn't get confused, so you put barriers up to assure that no unexpected data gets entered into the database. However, the user's goal is to quickly handle the varied and unpredictable demands of the client. If the client, for example, hasn't yet established where an order should be shipped, and the program rejects the order because it lacks a valid shipping address, the software has achieved the task of data integrity while utterly failing to achieve the goal of recording the client's order. Another way of looking at this is that the author of the software has mistakenly imposed his goals on the user, instead of making the code work to achieve the user's goals. It is certainly beneficial to maintain an unsullied database, but not at the expense of employees who interact with the database or a client who is rebuffed.

Another example of goal/task confusion is the design of bookkeeping systems. Manual bookkeeping systems were prone to human error. The double-entry method was invented to fix this problem. Essentially, each transaction was booked twice in two separate accounts. When the totals didn't balance, it was an indicator (that is, an error message) telling accountants to check their math. Ever since, bookkeeping systems have been built around this double-entry idea.

Enter the computer, a tool with many shortcomings, of which arithmetic capability is clearly not one. Although computers don't make addition and subtraction errors, most computerized bookkeeping systems religiously use the double-entry system.

When you examine bookkeeping from the point of view of the user's goals, rather than merely examining the familiar, manual tasks, you find that making two entries isn't a goal. If the people in business could get reliable accounting with one entry, they'd do it. If they could do it with no entries, they would! The point isn't the method, it is the objective.

Avoiding Meetings

Returning to the group-calendaring example, how can a program that is supposed to make you attend meetings allow you to avoid them? Let's take the agenda facility in our calendar and turn it to our advantage. This feature lets you write a short note describing the meeting's purpose, attach it to the schedule, and send it to all of the invitees. It might say "Please meet with me on Tuesday, June 17th at 3:00 to decide on the retail price of our new Spam-O-2000." Normally, everyone will trudge to the meeting and yawn through long-winded pleas for various prices. Instead, you might allow users to create an agenda without attaching it to a meeting. The agenda note now says "What should we charge for the Spam-O-2000?" and is sent to the same list of people. If the responses range from "ten dollars" to "ten thousand dollars," you have a problem and must call a meeting. On the other hand, if everyone replies "a buck-fifty," "whatever you want," or some other useful consensus, then you have succeeded in avoiding a meeting! The software has directly helped you achieve your goal.

What is remarkable about this solution is that most existing group-calendaring systems have agenda features already built into them. It wouldn't take much programming effort to disconnect agendas from meetings. Designing for the user's goals is easier than you think. Mostly, it's a matter of trusting in goals and ignoring the hegemony of tasks.

The Goal Stack

The range of possible goals is not homogeneous. As Table 1 illustrates, I divide goals into four basic categories: false, corporate, practical, and personal.

In the software industry, we are intimately familiar with the items in the false-goals category. Most of the software we use is written with them in mind. These goals can easily be achieved by ignoring users and focusing on the needs of the code. This explains their prevalence in existing software: Because programmers must be concerned with software, they often forget about users.

These goals are false because they apply only to the task of software creation, while ignoring the software's use. The remaining goals are false because they are tasks, features, and tools. They are means to ends, but not ends in themselves, and goals are always ends. A target like "safeguarding data integrity" isn't a goal for a personal mailing-list program the same way it might be for a program that calculates shuttle orbits. A target like "saving memory" is unimportant for the typical database query where downloads are small and computers are big. Even a target like "being easy to learn" isn't a primary goal for the software in a jet-fighter cockpit, where the software's only users will be specially trained pilots. I'm not giving license to make software that's hard to learn, I'm just pointing out that a fighter pilot who found weapons systems easy to learn-but slow and cumbersome to operate-would be at a distinct disadvantage in an aerial dogfight. The pilot's goal is to emerge from combat victorious, not to simplify flight instruction.

Complicating the false-goals issue are two powerful forces-history and innovation.

Technical innovation is the engine that drives our industry. Since the invention of the microprocessor, the computer revolution has surfed a wave of new technology. Any company that ignores new technical ideas is doomed. But don't confuse these techniques with goals. It may be a software company's task to use new technology, but it is never a user's goal to do so. As a user, I don't care if I get my job done with hierarchical, relational, or object-oriented databases (or black magic, for that matter). All I care about is getting my job done with a modicum of ease and dignity. Technology is like salt: You can't make a meal without it, but it doesn't nourish all by itself.

Last year, for example, Visioneer carved out a big share of the desktop-scanner market from well-entrenched competitors. This was remarkable because Visioneer's PaperPort scanner system was only old-fashioned black-and-white, while the competition could scan either gray-scale or full color. But Visioneer's system included goal-directed software that allowed users to easily view and manage scanned images, while other software merely dumped the scans into the file system.

The software-development world labors under many assumptions that are historically true, but have been made utterly false by the march of time. In the '60s and '70s, when you (or the person who taught you) learned about computers, the dominant paradigm was the exorbitant cost and subsequent shortage of processor cycles, main memory, and secondary disk storage. Consequently, most of the really cool techniques in computer science are based on the need to conserve cycles and bytes, even though modern computers have plenty of memory, plenty of storage, and an embarrassment of compute-cycle riches. The other historical ball and chain is the annoyingly persistent falsehood that to use a computer you must become "computer literate." This is just an excuse we in the industry use to salve the guilt caused by our inability to create adequate design. Instead of making software easy to use, we blame users.

Corporate Goals

Corporations have their own requirements for software, and they are as high level as the goals of the individual. "To increase our profit" is pretty fundamental from the viewpoint of the board of directors or the stockholders. Designers can use these goals to help keep their focus on the bigger issues and avoid getting distracted by tasks or other false goals.

Psychologists who study the workplace have a term, "hygienic factors," which Saul Gellerman (Motivation and Productivity, New York, N.Y.: Amacom, 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.

I have adapted this term as "hygienic goals," which I define as goals that are prerequisites for effective functioning, but powerless to achieve success by themselves. All of the corporate and practical goals in Table 1 are hygienic. From the corporation's point of view they are important goals, but the corporation isn't doing the work, people are, and their goals are different.

Practical Goals

Practical goals are the bridge between the objectives of the company and those of individual users. In the calendar example, the practical goal of avoiding unnecessary meetings connects the corporate goal of having good business communications with the user's personal goal of being productive.

Programmers are often practical people, and these goals have much appeal. The touchy-feely nature of personal goals are less appealing to their engineering sensitivities. True to their nature, they create software that-although it admirably fulfills the practical goals-fails utterly to satisfy the individual user. An interface that is complex and obscure can provoke users to make mistakes and obstruct their ability to be personally productive. This makes them feel bad about themselves and the software.

On the other hand, if your software ignores practical goals and serves only user's goals, you have just written a computer game.

Personal Goals

Personal goals are always true and operate, to varying extents, for everyone. If users are made to feel stupid by the software, their self-esteem droops, and their effectiveness is reduced.

Learning how to manage the file system is difficult for most users, and they see it merely as an obstruction to getting an adequate amount of work done. Virtually all software with a "File" menu violates the user's personal goals.

When a program continually badgers users with confirmation dialog boxes, users begin to feel like the program isn't all that eager to help out. Imagine if you had an assistant who continually asked, "Are you sure you wanted me to file this report?" or "Are you sure you wanted to throw away this old paper?"

Probably the worst violator of personal goals are error messages. These obnoxious little idioms serve no purpose that couldn't better be served another way. They blame users for the software's shortcomings.

There is a close parallel between corporate and personal goals: Both are the highest expressions of goals for their respective owners. Neither can be slighted. Software that fails to achieve either one will fail.

Excise and Navigation

Programmers think about software in terms of the individual tasks that users must perform, and their software reflects that orientation. Most software is a collection of features, one per task. Each separate feature has a corresponding user-interface element. Each bit of interface adds overhead, what I call "excise," or extra work that users must perform merely to manage the idiom, with no benefit to the user or the business. This includes things like moving windows around or pressing OK buttons. Lots of interface elements means lots of added excise. After a while, users spend as much time flipping between views, scrolling down lists, and summoning dialogs as doing their work.

In addition, because most business tasks are reasonably complex and have many variants, the feature count climbs rapidly. With it, the interface-element count also climbs, and the difficulty of navigation is added to the burden of excise. Because there are so many features, users need to know how to navigate from one to another at the proper time.

The twin burdens of excise and navigation conspire to make many users feel trapped in an unproductive maze. This feeling is directly contradictory to their personal goals.

A Goal-Directed Exercise

Because the demands of my work week are often so different from the demands of my weekends, I frequently lose track of the relationship between Sunday night and Monday morning. To achieve my goals, then, any schedule program must help me to check and see how the transition between Sunday night and Monday morning will work.

Figure 1 shows my meeting schedule for the week of May 26th. I can see all that I have to do. By pressing the small arrow buttons in the upper-left and right corners, I can switch to the previous or following week. However, if I want to check on what I'm doing Sunday the 25th, I have to change modes first. Merely asking for the previous week only gets me the weekdays of the 19th through the 23rd. The weekly view doesn't show weekends. So I have to go to the tabs running down the left side of the calendar and switch to the "Daily" view. Only then can I press the "previous" button to see Sunday the 25th, as in Figure 2. Of course, then I can see only Sunday, and can't see the juxtaposition between the last day of the weekend and the first day of the work week. Lots of excise, a navigational maze, my practical goals are thwarted, and I begin to feel stupid.

The question that leaps to mind is: Why must we think of our calendar as either a weekly view or daily view? Some paper calendars show a week at a time, some one day per page, and the common wall calendar one month per page. These idioms exist not because they are superior presentations of days, but because they are the best compromises with the limitations of paper. A paper calendar that showed me only three or nine or twenty-one days at a time would be a silly refutation of the technology. However, in the software world, we are not limited to the permanent printed nature of paper. We can dynamically display anything on the screen, and we can morph and change it as we desire. There is no reason my software calendar can't show me a total of twenty-one days, but with seven of them emphasized, and the one currently being focused on fully expanded, as in Figure 3.

Actually, the three views (or modes) of Microsoft's 7.0 Schedule+-monthly, weekly and daily-are really not appropriate for most users. Usually, I want to look at today with a sharp, detailed focus, but I want to see the rest of this week in lesser detail at the same time. It would be good, too, to see all of the next two weeks, even if the detail is minimal. Suppose I had a business trip coming up, where I would travel to Europe this Thursday, returning a week from next Tuesday. I need to see how this trip fits into my schedule at the home office, but I also need to see how individual appointments dovetail into the 12 days I will be on the road. My trip begins in May but ends in June, so unfortunately I cannot see the whole trip with any of Schedule+'s views. The monthly screen (Figure 4) wastes pixels by the thousand by showing useless days. I have to continually flip from a one-screen view of May to a different one-screen view of June. Look again at Figure 3 and you see that the display doesn't treat the division between May 31st and June 1st as anything special, so the entire trip is visible at one time on the screen. It meets my goals, rather than the false goals of "one month per screen."

Dragging the historically familiar paper-based forms of presentation into the digital world merely keeps me from doing what I want-to see a more flexible, fish-eye view of my schedule, where "today" is shown large and in sharp detail, and future days are shown progressively smaller and in lesser detail. As I arrow back and forth between the days, the one day currently under my scrutiny would be shown in rich detail with full supporting text, while days farther away would be shown with decreasing amounts of detail, consuming fewer precious pixels.

This style of calendar dramatically reduces the amount of excise and navigation trauma forced on users. There is only one mode (view), so users never have to flip between "Daily," "Weekly," or "Monthly" settings. Concomitant with this, users don't have to see a shift in the visual context, which can be confusing. Users who still wish to see this week, then the next week, without paying attention to the weekends, can shift a week at a time with a single mouse click. And by simply never pointing to a weekend day, users maintain emphasis on just the work week. For the rest of us, however, scrolling or double clicking on the smaller weekend day brings Sunday night into view, automatically showing its relationship to Monday morning.

Figure 3 isn't meant to be a complete design, but it hints at other advantages, too. Comparing it to Figure 1, you can see that the exacting time ruler that runs down the left of the screen is missing. Prominently displaying the starting time of daily events is critical. The ending time of most business meetings is never as important as the start time, yet Microsoft's Schedule+ demands that you treat durations and end times with the same emphasis on precision, completeness, and graphical perfection as start times. From the goal-directed perspective, several tasks imposed on users can be easily dispensed with. The end of one meeting is easily defined by the beginning of the next one.

Your Mission, Should You Choose to Accept It...

You can create dramatically different and more-powerful software by letting the user's goals be your guide. Comparing features to the goal yardstick gives you the ability to make clear decisions about their efficacy. Sometimes you will even find that eliminating costly features improves programs, as I showed in the Schedule+ example. You don't have to feel guilty about shrinking the feature list if you know that you are reducing excise and navigation.

If you ask users how to design their software, they will ignore their own goals and describe tasks to you with the same alacrity as programmers. The process of designing for users' goals is one that begins with you, the software designer, and not with the user. You must identify the hygienic goals and the users' personal goals and design an interface that serves them directly, ignoring all other demands.

Table 1: Software goals divided into four basic categories.

False       Save memory.
            Save keystrokes.
            Be easy to learn.
            Safeguard data integrity.
            Speed up data entry.
            Increase program execution efficiency.
            Use cool technology or features.
            Increase graphic beauty.
            Maintain consistency across platforms.

Corporate   Increase our profit.
            Increase our market share.
            Defeat our competition.
            Hire more people.
            Offer more products or services.
            Go public.

Practical   Avoid meetings.
            Handle client's demands.
            Record client's order.
            Create a paper model of the business.

Personal    Not feel stupid.
            Not make mistakes.
            Get an adequate amount of work done.
            Have fun (or at least not be too bored).