Corporate Goals
Practical Goals
Personal Goals
False goals
In the software industry, we are all intimately familiar with the items in the false goals category. Most of the software we use everyday is written with them in mind. These goals can easily be achieved by ignoring the user 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 the user.
Many of the goals are false because they are the programmer's goals, applying only to the task of software creation, but 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" isn't very important for typical database query programs because 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 its only users will be specially trained pilots. I'm not giving license to make your software hard to learn, but just pointing out that a fighter pilot who found it easy to learn to use her weapons systems, but then found them slow and cumbersome to operate, would be at a distinct disadvantage in an aerial dogfight. Her goal is to emerge from combat victorious, not to have an easy time in flight instruction.
Complicating the confusion surrounding false goals 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 databases, relational databases, object-oriented databases, flat-file systems or just plain black magic. All I care about is getting my job swiftly 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.
For example, last year the Visioneer company carved out a big share of the desktop scanner market from well-entrenched competitors. This was remarkable because their new scanner was only old-fashioned black-and-white while their competition could scan either gray-scale or full color. But Visioneer's product included goal-directed software that allowed the user to easily view and manage her scanned images, while the other's software merely dumped the scans into the file system.
The software development world labors under many assumptions historically true but now 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, but 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 a sufficiency of adequate design. Instead of making software easy to use, we blame the user.
Corporate goals
The corporation has its own requirements for software, and they are as high level as the personal goals of the individual. "To increase our profit" is pretty fundamental from the viewpoint of the board of directors or the stockholders. The designer can use these goals to help keep her 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: 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. Every one of the corporate and practical goals shown in the list 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 the objectives of the individual user. In our 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 very practical people, and these goals have much appeal to them. 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.
Of course your software has to have the features built into it to accomplish the goals of the business. The user must perform the tasks necessary to handle client's demands and process orders, but these are only hygienic, because offering these features without addressing the user's personal goals will fail. If the user fails to achieve her own personal goals she cannot effectively achieve the company's. It is a simple fact of human nature that happy, satisfied workers are more effective ones. This is more true than ever in the modern information economy, where the true assets of a company are human and not mechanical.
If your software were to lean the other way and ignore the practical goals and serve only the user's goals, you will have just invented a computer game.
Personal goals
The personal goals are always true and operate-to varying extents-for everyone. If a user is made to feel stupid by the software, his self-esteem droops and consequently his effectiveness is sharply reduced.
Learning how to manage the file system is very difficult for most users, and they see it merely as an obstruction to their getting an adequate amount of work done. When they fail to grasp its nuances, they feel stupid for no discernible gain in productivity. Virtually all software with a "File" menu violates the user's personal goals somewhat.
When a program continually badgers users with confirmation dialog boxes, the user begins 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 the user for their own shortcomings. If one of your colleagues blamed you for their mistake, you'd certainly be upset. Users have the same reaction to software error messages.
There is a close parallel between corporate goals and personal goals: both are the highest expressions of goals for their respective owners. Consequently, they are the most important and neither can be slighted. Software that fails to achieve either one will fail. Software that fails to achieve the personal goals of its user may not fail at first, but it won't earn loyalty from its customers, and will be very vulnerable to competition that does.
Excise and navigation
Let's examine how goal confusion leads directly to inferior interface design. 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 involves a little bit of added overhead, what I call "excise," or extra work that the user 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, the user spends as much time flipping between views, scrolling down lists and summoning dialogs as she does useful and productive 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, the user needs 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 like they are trapped in an unproductive maze. This feeling is directly contradictory to their personal goals. If you were trapped in a maze, wouldn't it make you feel stupid? If you found yourself spending much of your time telling the program to do the same useless thing over and over, wouldn't it make you feel like you weren't getting an adequate amount of work done? I'd like to show you some simple ways to reduce excise and ease navigation in real world software. I'll use Microsoft's Schedule+ program as an example.
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 - The basic Weekly view in Microsoft's Schedule+ Version 7.0 is crowded with information we don't want, like durations and end-times of meetings, and refuses to show me information that we do want, like more detail for today. The graphical presentation gives equal emphasis to every day and every appointment, but in real life some days and some appointments are more important than others.
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 shown 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 week. Lots
of excise, a navigational maze, and my practical goals are thwarted. A perfect
recipe for failing to achieve my personal goals, and I begin to feel stupid.
Figure 2 - The Daily view in Schedule+ devotes plenty of space to a single day, but now it is removed from its context and I can't see how it fits into the week. Although I can't see what I want, most of the pixels on the screen are wasted and show me nothing useful. The software achieves the programmer's goals better than the user's.
The question that leaps to my mind is: why must we think
of our calendar as either a weekly view or a daily view? It's because we
have been taught to think this way by our familiarity with paper calendars.
Some paper calendars show a week at a time, some show one day per page,
and the common wall calendar shows 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 shown in Figure 3.
Figure 3 - Here is a sketch of a proposed solution to the problem described in the text. Notice that the size of the rectangles is different from day to day, and that the selected day, Sunday, May 25th is the biggest rectangle visible. This unequal allocation of space would be problematic on a printed calendar, but on a dynamic screen it makes perfect sense. Notice also how phone calls and the airplane trip are shown with different visual idioms than the one used for more rigid appointments. This sketch is far from a complete design, simply hinting at a new approach.
Actually, the three views, or modes, of Schedule+, monthly,
weekly and daily, are really not very appropriate for most use. 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 here at the home office, but then I also need to see how individual
appointments dovetail into the twelve days that 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, shown in Figure
4, wastes pixels by the thousand showing me useless days, but not the ones
I want. 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 can 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 arbitrary task of "one month per screen."
Figure 4 - Microsoft's obligatory Monthly view is a model of pixels sacrificed on the altar of meaningless regularity. The gray days are evidence that developers in Redmond have grappled unsuccessfully with the problem of showing events just over the boundary into the next month. Instead of leaving the partial weeks at the beginning and ending of the month blank, they color them gray and show the appointments scheduled in them. Why not take the next logical step and eliminate the rigid border between the months? After all, it's just a vestigial artifact of another, older medium.
It should be obvious that dragging the historically familiar paper-based forms of presentation into the digital world merely keep me from doing what I want, which is to see a more flexible, fisheye 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.
The advantage of this style of calendar presentation is starkly better because it dramatically reduces the amount of excise and navigation trauma forced on the user. There is only one mode-one view-so the user never has to flip between "Daily," "Weekly," or "Monthly" settings. Concomitant with this the user doesn't have to see a shift in the visual context, which can be dislocating and disturbing. The user who still wishes to see this week, then the next week, without paying attention to the weekends, can still shift a week at a time with a single mouse click, and simply by never pointing to a weekend day, can maintain emphasis on just the work week. However, for the rest of us, scrolling or double-clicking on the smaller weekend day brings Sunday night into view, automatically showing its relationship to Monday morning.
The sketch in 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 side of the screen is missing. It is critical that the starting time of daily events be prominently displayed. After all, being late to a meeting would make us feel stupid. But it isn't critical that meetings be proportionally mapped to a graphical time scale or that their end times be monitored with equal vigor. 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. Looking at the problem from a goal-directed point of view, we see that several tasks imposed on the user can be easily dispensed with. The end of one meeting is easily defined by the beginning of the next one.
You mission, should you choose to accept it...
You have seen how 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. What's more, you don't have to feel guilty about streamlining the interface and shrinking the feature list because you know that you are reducing excise and the pain of 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. You must observe users to determine their goals, but don't be fooled by their own ignorance of their objectives. The process of designing for user's goals is one that begins with you, the software designer, and not with the user. You must identify the hygienic goals and the user's personal goals and design an interface that serves them directly, ignoring all other demands. If you don't, you risk creating yet another computer program that makes the user feel stupid, which will ultimately make them fail to achieve the goals of the business.
The phrase "Goal-Directed" is a registered trademark of Cooper Interaction Design.