Goal-Directed Design

When interaction designers analyze goals to solve problems, they typically find very different and much better solutions.

Imagine Jennifer, an office manager in a small company. Her goal is to make her office run smoothly. Of course, she doesn't want to feel stupid or make mistakes, either. Toward those ends, she must make her computer network run smoothly. She must set it up properly, monitor its performance, and modify its configuration periodically to maintain its peak performance. In Jennifer's mind, her job is a seamless blending of these three tasks, contributing to her one goal of smooth running. From Jennifer's point of view, there is really no difference among the three tasks. She doesn't sense a big difference between initial setup and subsequent reconfiguration of the network.

Imagine Clancy, a software engineer, who must write the software that Jennifer uses. In Clancy's Homo logicus mind, Jennifer's software performs three tasks three functions and each will be implemented in a different chunk of software. It seems natural to Clancy that each function also has its own chunk of interface. It's only logical. Clancy is considering an interface with a hierarchical list of system components in the left-side pane, and when a component in that list is selected its details are shown in the right-side pane. This interface has the advantage of being approved by Microsoft, and it makes sense to programmers. The user will have to click on lots of system components to find out what is happening in the system, but all the necessary information is there for the asking.

Imagine Wayne, an interaction designer, who is charged with making both Jennifer and Clancy happy. In Wayne's designing mind, he knows that the software must represent itself to Jennifer in a way that most closely approximates her goals while ensuring that all of the necessary functions are present. (Jennifer is a primary persona.) Wayne also knows that he cannot specify anything that would create unreasonable or impossible effort for Clancy.

Wayne sees that Jennifer has only a single goal smooth running so he designs the interface so Jennifer can see at a glance that things are running smoothly. If some bottleneck occurs, Jennifer's interface clearly shows that one trouble spot in a prominent, visual way and lets her investigate and fix the problem by directly interacting with the onscreen representation of the troubled area. Wayne knows that to Jennifer there is no difference between monitoring the system and modifying it, and the interface reflects that perception. The only time that Jennifer ever has to ask about a component in her system is when she has already learned that there is a good reason for her to do so.

From Clancy's point of view, the code to show the performance of a component and the code to configure that component are two separate procedures. They have no connection in task-think. But in goal-think, they are intimately bound. Jennifer would never choose to reconfigure a component unless she were first apprised of a reason to reconfigure it by seeing a reduction in its performance. Further, Jennifer would always want to carefully monitor that component's performance level while she reconfigured it.

Designing for the user persona's goals clearly shows us an alternative way to think about delivering functionality. It frequently provides dramatically better ways to solve prosaic design problems. Here are some examples.

Goal-Directed Television News

On one of our projects, a client was working on an ensemble of applications that supported the creation of a television news show. From the engineer's task viewpoint, news shows are built the way bridges are built: one piece at a time. But we determined that the newscaster's goal wasn't to "build" a news show over time, but rather, it was to always have a news show that got better over time. Each news show is really a fluid and organic beast that begins and ends life fully grown.

In the news business, anything can happen, so the newscaster wants to always have a fallback position. His goal is to always have a reasonable, broadcastable show. The evening news show begins in the morning as a complete, ready-to-broadcast entity 22 full minutes (not including commercials) and it always exists in a state of completion. Each story segment has a time allowance, and the segments always combine to total 22 minutes. Like a blurry image slowly coming into focus, the boundaries of the show never change, but the contents become sharper and more precise. From 10:00 a.m. on, the news show could be broadcast if need be, but it will be at its best sometime around 5:00 p.m.

Each news show consists of 20 to 30 news stories blocked out with cues, video clips, remotes, and studio presentations. As the morning progresses, the priority of each story shifts, and the presentation order and allotted time change to reflect the judgment of the news director. During the early afternoon, a breaking story might demand attention, altering the order of the other stories and probably even bumping some of them off the program entirely. The reporters and news director will be tweaking and changing the script up until the last second sometimes into the broadcast itself.

The software engineers, looking at the problem from a task and procedure point of view, had created an application that allowed a news show to be built story segment by story segment. It was very logical, very reasonable, but very wrong. The news show wasn't a complete thing until immediately before broadcast, and a change to a single segment disrupted all of the other segments, leaving the show unbroadcastable until it was patched together again.

For our design work, we sketched an application that began with a ready-for-prime-time news show and allowed the reporters and news director to constantly tweak it, just as they worked in a manual world. But unlike the manual method, our design brought the power of the computer to bear. For example, if a segment were pulled at the last minute, the time allotted to it would be automatically distributed to the remaining stories in a weighted allocation scheme.

Goal-Directed Classroom Management

In another design project, we were asked to design a classroom-management system for elementary-school teachers. The engineers had provided facilities for testing students, tracking performance, and accessing a database of lesson plans. From a task point of view, things seemed adequate. We looked metaphorically speaking deep into the teacher's eyes to determine what the typical primary-school teacher really wanted and came up with a surprising answer.

We learned that teachers feel isolated in their classrooms and crave feedback on how they are doing. In order to improve, a teacher needs a way to measure her own performance. This simple need is not obvious when you decompose the teaching process into its component tasks. That human need is easily visible when you examine goals. In our design, we provided a facility that tracked the teacher's achievements from semester to semester and also from room to room. With this tool, the teachers had a better sense of continuity and progress, and their confidence in their work grew.