The Goal-Directed Design Process

Most technology-focused companies don't have an adequate process for user-centered design, if they have a process at all. But even the more enlightened organizations, ones that can boast of an established process, come up against some critical issues that result from traditional ways of approaching the problems of research and design.

In recent years, the business community has come to recognize that user research is necessary to create good products, but the proper nature of that research is still in question in many organizations. Quantitative market research and market segmentation is quite useful for selling products, but falls short of providing critical information about how people actually use products—especially products with complex behaviors (see Chapter 5 for a more in-depth discussion of this topic). A second problem occurs after the results have been analyzed: Most traditional methods don't provide a means of translating research results into design solutions. A hundred pages of user survey data don't easily translate into a set of product requirements, and they say even less about how those requirements should be expressed in terms of a logical and appropriate interface structure. Design remains a black box: "A miracle happens here." This gap between research results and the ultimate design solution is the result of a process that doesn't connect the dots from user to final product. We'll soon see how to address this problem with Goal-Directed methods.

Bridging the gap

As we have briefly discussed, the role of design in the development process needs to change. We need to start thinking about design in new ways, and start thinking differently about how product decisions are made.

DESIGN AS PRODUCT DEFINITION

Design has, unfortunately, become a limiting term in the technology industry. For many developers and managers, the word has come to mean what happens in the third process diagram shown in Figure 1-1: a visual facelift on the implementation model (see Chapter 2). But design, when properly deployed (as in fourth process diagram shown in Figure 1-1), both identifies user requirements and defines a detailed plan for the behavior and appearance of products. In other words, design provides true product definition, based on goals of users, needs of business, and constraints of technology.

DESIGNERS AS RESEARCHERS

If design is to become product definition, designers need to take on broader roles than that assumed in traditional design, particularly when the object of this design is complex, interactive systems.

One of the problems with the current development process is that roles in the process are over-specialized: Researchers perform research, and designers perform design (see Figure 1-4). The results of user and market research are analyzed by the usability and market researchers and then thrown over the transom to designers or programmers. What is missing in this model is a systematic means of translating and synthesizing the research into design solutions. One of the ways to address this problem is for designers to learn to be researchers.

Figure 1-4: A problematic design process. Traditionally, research and design have been separated, with each activity handled by specialists. Research has, until recently, referred primarily to market research, and design is too often limited to visual design or skin-deep industrial design. More recently, user research has expanded to include qualitative, ethnographic data. Yet, without including designers in the research process, the connection between research data and design solutions remains tenuous at best.

There is a compelling reason for involving designers in the research process. One of the most powerful tools designers bring to the table is empathy: the ability to feel what others are feeling. The direct and extensive exposure to users that proper user research entails immerses designers in the users' world, and gets them thinking about users long before they propose solutions. One of the most dangerous practices in product development is isolating designers from the users because doing so eliminates empathic knowledge.

Additionally, it is often difficult for pure researchers to know what user information is really important from a design perspective. Involving designers directly in research addresses both issues.

In the authors' practice, designers are trained in the research techniques described in Chapter 4 and perform their research without further support or collaboration. This is a satisfactory solution, provided your team has the time and resources to train your designers fully in these techniques. If not, a cross-disciplinary team of designers and dedicated user researchers is appropriate.

Although research practiced by designers takes us part of the way to Goal-Directed Design solutions, there is still a translation gap between research results and design details. The puzzle is missing several pieces, as we will discuss next.

BETWEEN RESEARCH AND DESIGN: MODELS, REQUIREMENTS, AND FRAMEWORKS

Few design methods in common use today incorporate a means of effectively and systematically translating the knowledge gathered during research into a detailed design specification. Part of the reason for this has already been identified: Designers have historically been out of the research loop and have had to rely on third-person accounts of user behaviors and desires.

The other reason, however, is that few methods capture user behaviors in a manner that appropriately directs the definition of a product. Rather than providing information about user goals, most methods provide information at the task level. This type of information is useful for defining layout, workflow, and translation of functions into interface controls, but less useful for defining the basic framework of what a product is, what it does, and how it should meet the broad needs of the user. Instead we need explicit, systematic processes for defining user models, establishing design requirements, and translating those into a high-level interaction framework (see Figure 1-5).

Figure 1-5: Bridging the gap between research and design. Three primary activities close the gap. A process of modeling that synthesizes research results into design tools, a process of synthesizing and defining requirements from these models, and a process of translating the knowledge captured in the models and requirements into a design framework that reflects the goals and needs of users, while also addressing business and technical imperatives.

Knowledge about users must be synthesized into a model that leverages user data as a design tool. Other models, such as workflows and environmental contexts, are also important and useful, but appropriate user models are singularly critical. After user models are created, the usage patterns, mental models, and user goals captured by them can be systematically mapped to an interaction framework that also addresses the business and technical imperatives that are captured in other models.

Goal-Directed Design seeks to bridge the gap that currently exists in the digital product development process, the gap between user research and design, through a combination of new techniques and known methods brought together in more effective ways.

A process overview

Goal-Directed Design combines techniques of ethnography, stakeholder interviews, market research, product/literature reviews, detailed user models, scenario-based design, and a core set of interaction principles and patterns. It provides solutions that meet the needs and goals of users, while also addressing business/organizational and technical imperatives (see Figure 1-6). This process can be roughly divided into five phases: Research, Modeling, Requirements Definition, Framework Definition, and Refinement. These phases follow the five component activities of interaction design identified by Gillian Crampton Smith and Philip Tabor (1996)—understanding, abstracting, structuring, representing, and detailing—with a greater emphasis on modeling user behaviors and defining system behaviors.

Figure 1-6: The Goal-Directed Design process

The remainder of this chapter provides a high-level view of the five phases of Goal-Directed Design. Chapters 4, 5, and 6 provide a more process-oriented overview of the methods involved in each of these phases.

RESEARCH

The Research phase employs ethnographic field study techniques (observation and contextual interviews) to provide qualitative data about potential and/or actual users of the product. It also includes competitive product audits, reviews of market research and technology white papers, as well as one-on-one interviews with stakeholders, developers, subject matter experts (SMEs), and technology experts as suits the particular domain.

One of the principal outcomes of field observation and user interviews is an emergent set of usage patterns—identifiable behaviors that help categorize modes of use of a potential or existing product. These patterns suggest goals and motivations (specific and general desired outcomes of using the product). In business and technical domains, these behavior patterns tend to map to professional roles; for consumer products, they tend to correspond to lifestyle choices. Usage patterns and the goals associated with them drive the creation of personas in the Modeling phase. Market research helps select and filter for valid personas that fit corporate business models. Stakeholder interviews, literature reviews, and product audits deepen the designers' understanding of the domain and elucidate business goals and technical constraints that the design must support. Chapter 4 provides a more detailed discussion of Goal-Directed research techniques.

MODELING

During the Modeling phase, usage and workflow patterns discovered through analysis of the field research and interviews are synthesized into domain and user models. Domain models can include information flow and workflow diagrams. User models, or personas, are detailed, composite user archetypes that represent distinct groupings of behavior patterns, goals, and motivations observed and identified during the Research phase.

Personas serve as the main characters in a narrative, scenario-based approach to design that iteratively generates design concepts in the Framework Definition phase, provides feedback that enforces design coherence and appropriateness in the Refinement phase, and represents a powerful communication tool that helps developers and managers to understand design rationale and to prioritize features based on user needs. In the Modeling phase, designers employ a variety of methodological tools to synthesize, differentiate, and prioritize personas, exploring different types of goals and mapping personas across ranges of behavior to ensure there are no gaps or duplications.

Specific design targets are chosen from the cast of personas through a process of comparing goals and assigning a hierarchy of priority based on how broadly each persona's goals encompass the goals of other personas. A process of designating persona types determines the amount of influence each persona has on the eventual form and behavior of the design.

Possible user persona type designations include:

• Primary: the persona's needs are sufficiently unique to require a distinct interface form and behavior

• Secondary: a primary interface serves the needs of the persona with a minor modification or addition

• Supplemental: the persona's needs are fully satisfied by a primary interface

• Served: the persona is not an actual user of the product, but is indirectly affected by it and its use

• Negative: the persona is created as an explicit, rhetorical example of whom not to design for

A detailed discussion of persona and goal development can be found in Chapter 5.

REQUIREMENTS DEFINITION

Design methods employed by teams during the Requirements Definition phase provides the much-needed connection between user and other models and the framework of the design. This phase employs scenario-based design methods (Carroll, 1995), with the important innovation of focusing the scenarios not on user tasks in the abstract, but first and foremost on meeting the goals and needs of specific user personas. Personas provide an understanding of which tasks are truly important and why, leading to an interface that minimizes necessary tasks (effort) while maximizing return. Personas become the main characters of these scenarios, and the designers explore the design space via a form of role-playing.

For each interface/primary persona, the process of design in the Requirements Definition phase involves an analysis of persona data and functional needs (expressed in term of objects, actions, and contexts), prioritized and informed by persona goals, behaviors, and interactions with other personas in various contexts.

This analysis is accomplished through an iteratively refined context scenario that starts with a "day in the life" of the persona using the product, describing high-level product touch points, and thereafter successively defining detail at ever-deepening levels. As this iteration occurs, both business goals and technical constraints are also considered and balanced with persona goals and needs. The output of this process is a requirements definition that balances user, business, and technical requirements of the design to follow.

FRAMEWORK DEFINITION

In the Framework Definition phase, teams synthesize an interaction framework by employing two other critical methodological tools in conjunction with context scenarios. The first is a set of general interaction design principles that, like their visual design counterparts (see Chapter 19), provide guidance in determining appropriate system behavior in a variety of contexts. Chapters 2 and 3 and the whole of Section II are devoted to high-level interaction design principles appropriate to the Framework Definition phase.

The second critical methodological tool is a set of interaction design patterns that encode general solutions (with variations dependent on context) to classes of previously analyzed problems. These patterns bear close resemblance to the concept of architectural design patterns developed by Christopher Alexander (1977). Interaction design patterns are hierarchically organized and continuously evolve as new contexts arise. Rather than stifling designer creativity, they often provide needed leverage to approach difficult problems with proven design knowledge.

After data and functional needs are described at this high level, they are translated into design elements according to interaction principles and then organized using patterns and principles into design sketches and behavior descriptions. The output of this process is an interaction framework definition, a stable design concept that provides the logical and gross formal structure for the detail to come. Successive iterations of more narrowly focused scenarios provide this detail in the Refinement phase. The approach is often a balance of top-down (pattern-oriented) design and bottom-up (principle-oriented) design.

REFINEMENT

The Refinement phase proceeds similarly to the Framework Definition phase, but with greater focus on task coherence, using key path (walkthrough) and validation scenarios focused on story-boarding paths through the interface in high detail. The culmination of the Refinement phase is the detailed documentation of the design, a form and behavior specification, delivered in either paper or interactive media as context dictates. Chapter 6 discusses in more detail the use of personas, scenarios, principles, and patterns in the Requirements Definition, Framework Definition, and Refinement phases.

Goals, not features, are the key to product success

Programmers and engineers—people who are intrigued by technology—share a strong tendency to think about products in terms of functions and features. This is only natural, as this is how developers build software: function by function. The problem is that this isn't how users want to use it.

The decision about whether a feature should be included in a product shouldn't rest on its technological underpinnings. The driving force behind the decision should never be simply that we have the technical capability to do it. The deciding factor should be whether that feature directly, or indirectly, helps to achieve the goals of the user while still meeting the needs of the business.

The successful interaction designer must be sensitive to users' goals amid the pressures and chaos of the product-development cycle. Although we discuss many other techniques and tools of interaction in this book, we always return to users' goals. They are the bedrock upon which interaction design is practiced.

The Goal-Directed process, with its clear rationale for design decisions, makes persuading engineers easier, keeps marketing and management stakeholders in the loop, and ensures that the design in question isn't just guesswork, or a reflection of the team members' personal preferences.

AXIOM 

Interaction design is not guesswork.

Goal-Directed Design is also a powerful tool for answering the most important questions that crop up during the definition and design of a digital product:

• How do I find out who my users are?

• How do I learn what my users are trying to accomplish?

• How should my product behave?

• What form should my product take?

• How will users interact with my product?

• How can my product's functions be most effectively organized?

• How will my product introduce itself to first-time users?

• How can my product put an understandable and controllable face on technology?

• How can my product deal with user problems?

• How will my product help infrequent users become more expert?

• How can my product provide sufficient depth for expert users?

We will help you to answer these questions in the remainder of this book. You will get tools you need to identify key users of your products, understand them and their goals, and translate this understanding into winning design solutions using Goal-Directed Design.