Teaching Goal-Directed Design as a User Design Tool 

Gary B. Randolph
Computer Information Technology, Purdue University
Anderson, IN, 46012, USA


Abstract

Few generally accepted techniques exist for approaching the unstructured problem of user interface design. This lack of tools complicates the teaching of this skill to beginning students. This paper briefly describes one such technique, Goal-Directed Design, (Cooper, 1999) and recounts the experiences and insights gained from using this technique in teaching user design concepts and techniques in an introductory systems analysis and design course.


Keywords:  User interaction design, systems analysis, personas


The discipline of systems analysis and design benefits from many established tools and techniques, including Project Evaluation and Review Technique (PERT) for project management, Entity Relationship Diagrams (ERDs) for data design, Data Flow Diagrams (DFDs) for process design, and Unified Modeling Language (UML) to name a few. One area that generally lacks formal tools and techniques is user interface design.

The design process involves two creative leaps: a leap from system requirements to the design implications and then from those implications to ideas for specific features and an implementation solution (Beyer & Holtzblatt 1998). Designers have traditionally emphasized the second leap, the implementation of a user interface. In the pre-Windows days, grid sheets were used to lay out screens and reports. Today we can teach the use of Graphical User Interface (GUI) controls, instruct students on GUI interface standards, and provide guidelines for human factors and terminology. However, there is more to interfaces than windows, icons, pull-down menus, and mice (Raskin, 2000). These things are just the "nuts and bolts" of the interface. 

Designers cannot ignore the first leap, the interaction design implications of user requirements. To do so would be like a carpenter focusing on the hammer instead of the house. By-and-large, however, we lack a technique for discovering the system requirements for user interaction. 

One useful technique is Goal-Directed Design developed by Alan Cooper (Cooper, 1999). The principle tool of goal-directed design is the creation of what Cooper calls personas (p. 123). With personas, the goal-directed designer develops "a precise description of our user and what he wishes to accomplish" (pg. 123). During the Fall 2000 semesters as part of a beginning system design class, System Analysis and Design Methods, a lecture and assignment using personas as a user interface design tool were added.

1.  PERSONAS

Personas can be thought of as hypothetical users - fictional people who represent classes of users. Persona design begins with brainstorming on the types of people who will use the system. These characters are then named and fleshed out with back story and an understanding of their goals for using the system until they become like real people. 

Personas are defined by their needs and goals. These include their personal goals as well as their goals for the system. All too often designers begin by focusing on tasks that have to be performed. However designing a system that merely accomplishes tasks without meeting user needs and goals is a recipe for failure. This is evident in so many of the cell phones, remote controls, and digital cameras that we struggle to operate every day. They accomplish many tasks but are so complex to operate that they fail to satisfy our needs or meet our goals. 

A goal-directed design project may, and probably will, have multiple personas because different kinds of users with different goals will use the system. The system may not be designed for all personas. However, each system will have at least one primary persona (pg. 137). A primary persona is someone who must be satisfied with the system for it to be considered a success and who cannot be satisfied with an interface designed for another persona. The user interface designed for each primary persona should be based on the needs and goals of that persona.

Designers have traditionally understood that users do not interact directly with the system but rather interact indirectly with it through the user interface. With an understanding of user goals, designers can take this one step further. The user's interaction with the user interface is filtered by the user's needs, goals, and characteristics. This is presented graphically in Figure 1. User interfaces are not one size fits all because different users have different needs, goals, and characteristics. To be effective the user interface must "inherit" the needs, goals, and characteristics from the user persona for which the interface is being designed. For instance, given a user goal to run ad hoc reports combined with a user characteristic of not understanding SQL, we can derive a requirement for a user interface with wide reporting options using drop-down boxes, checklists, etc.

By focusing on user goals, goal-directed designers also avoid the trap of false goals, such as saving memory, using "cool" technology, or even being easy to learn. These are things that the industry says are goals, but users may or may not care about them. Design should be driven only by what users care about.

Many designers have for years used actual users to fulfill the persona role. However, a conceptual persona can serve the designer better for same reason that a conceptual ERD is created instead of just launching the DBMS and creating the tables. Actual users are implementation-oriented. A design created for a specific data entry clerk will surely serve that clerk. But what about the other clerks that also work on the system now and in the future? In addition, being a victim of a problem doesn't automatically provide insight into the problem's solution. In other words, users don't have all the answers. So, while actual users should be interviewed and used to evaluate design and prototypes, logical personas are better for guiding the design.

In goal-directed design, every project gets a cast of 3-12 unique personas. One persona is needed for each unique set of goals. The design team will not necessarily end up designing for every persona, but all are useful for articulating the user population. Indeed, some are defined simply to make clear whom the team is not designing for.

2.  RULES FOR DEVELOPING PERSONAS

Be Specific
The more specific our personas, the more effective they are as design tools. Suppose we are designing an informational kiosk for airports and one of our personas is Greg. We don't just say that Greg is a businessperson. We might specify that Greg is 50 years old, married to Nancy, with a daughter, Jennifer, in college, and a son, Doug, in High School. Greg works as a division manager for a Fortune 500 company. He flies for business 10-15 times a year and generally travels by air for vacations with his family during the summer and at Christmas. Greg knows his way around airports and is looking for ways to get in and out of them as quickly as possible. While at airports, comfort is important to him. Greg is computer-literate. However, as an aging baby-boomer, his eyesight isn't what it used to be and is often bothered by small type and glare on computer screens.

Why do we go to such detail? The detail makes Greg a real person. This avoids what Cooper calls the problem of the elastic user (p. 126) - a user who is sometimes computer savvy and sometimes not depending on who is doing the talking. Greg is Greg and does not change.

Precision, Not Accuracy
Personas must be precise in that they should be defined well enough so that their characteristics do not slip or change. However, personas do not have to accurately reflect every single person who will ever interact with the system. Personas exist to guide the design, not to cover every possible user. For instance, in designing an airport information kiosk, designers might have personas for Greg, as well as Gunter, a senior captain flying 747s from Vancouver to Frankfurt, but they might not have a persona for Cameron, a six-year-old who is flying for the first time and can barely read. Cameron is an edge case (p. 100) or exception. The needs and goals of edge case people are important, but you can't design for them. You design for the center and then accommodate the edge.

Design for One Person (at a time)
Once the cast of personas is developed, at least one, but not everyone, is designated as a primary persona. If only one persona must be satisfied, then the user interface is designed for that one persona. If more than one persona is primary, then the designers may end up with more than one product or, in the case of software, more than one user interface to the system.

3.  PERSONA CLASS ASSIGNMENT

In the beginning system design class the persona assignment was given in the context of a semester-long case study. In various phases of the case study, students developed ERDs, DFDs, and other design deliverables. Cooper (1999) provides no standard tools for developing personas. However the present author developed a Microsoft Word template for this purpose shown in Figure 2.

The normal lecture material on elements of user design as presented in the course textbook was given. This was then supplemented with information on goal-directed design. The class next brainstormed on possible personas for the case study system. 

Being given the persona template, students were told that their assignment was to create some specific personas, making assumptions as to their demographics, personal goals, and system goals. They were to fill out all the columns of the template except "User Interface Implications."

In the following class session, each student's personas were shared with all other students. This was feasible because the class was small. This allowed students to see the creativity and specificity possible in persona creation. From this universe of personas, a class discussion selected a handful of personas to use as the cast of characters and primary personas. Given the goals and needs of these personas, the class then brainstormed and analyzed implications for the user interface. Students created a final draft of the primary personas and the interface implications, shown in part in Figure 2.

4.  DISCUSSION

In the instructor's opinion, the persona assignment was very successful. It provided a tool for conceptually discussing how to approach the problem of user interface design. It also became a tool for evaluating the use of GUI controls and other design factors discussed in the textbook. 

In the past, the class had constructed proposed screen layouts. This tended to be less than satisfactory and gave the impression that the students' choices of controls and layout were made based on whatever the students thought of at the moment (like people setting up a database without first thinking through normalization). Overall, the goal-directed approach seemed superior. 

The students also seemed pleased with personas and goal-directed design. When asked their opinion of goal-directed design, one wrote, "With personas you can get an idea of what your target users will be so you can build a system that would...fit [them]. With an idea of what the users may be, you can set goals that may help benefit the user... and meet the goals of what the users are wanting."

Of course, every technique has its disadvantages as well as advantages. Students also gained a realistic understanding of the disadvantages of this technique. 
One wrote: "You can spend too much time on user design and get caught up in designing it rather than the actual program. If you have set personas, but they are not the right ones... you could wind up making a program for the wrong users."

One idea for improvement would be to have the students first create the personas and then design screen layouts based on those personas. Another idea is to have students design a screen layout before the persona analysis and then again afterward for comparison. This is being tried in the current semester's class.

In conclusion, goal-directed design has seemed to help students think through the issues of good user interface design and was a helpful technique for them to use in application design.

5.  REFERENCES

Beyer, H. & Holtzblatt, K. (1998). Contextual Design. San Francisco, CA. Morgan Kaufman Publishers.

Cooper, Alan. (1999). The Inmates are Running the Asylum. Sams, Indianapolis.

Raskin, Jeff. (2000). The Human Interface, New Directions for Designing Interactive Systems. Addison Wesley Longman, Inc., USA