Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf)
Page 7
Designers as researchers
If design is to become product definition, designers need to take on a broader role 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 overspecialized: 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.
Market Research
performed by market
?
analysts and ethnographers
Design of Form
performed by graphic/GUI
and industrial designers
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.
05_084113 ch01.qxp 4/3/07 6:00 PM Page 19
Chapter 1: Goal-Directed Design
19
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 that 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 is 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 an explicit, systematic process to bridge the gap between research and design for defining user models, establishing design requirements, and translating those into a high-level interaction framework (see Figure 1-5). 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.
05_084113 ch01.qxp 4/3/07 6:00 PM Page 20
20
Part I: Understanding Goal-Directed Design
A process overview
Goal-Directed Design combines techniques of ethnography, stakeholder interviews, market research, 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. This process can be roughly divided into six phases: Research, Modeling, Requirements Definition, Framework Definition, Refinement, and Support (see Figure 1-5). These phases follow the five component activities of interaction design identified by Gillian Crampton Smith and Philip Tabor — understanding, abstracting, structuring, representing, and detailing — with a greater emphasis on modeling user behaviors and defining system behaviors.
Research
Modeling
Requirements
Framework
Refinement
Support
users
users
definition of user,
definition of
of behaviors,
development
and the
and use
business, and
design structure
form, and
needs
domain
context
technical needs
and flow
content
Figure 1-5 The Goal-Directed Design process.
The remainder of this chapter provides a high-level view of the five phases of Goal-Directed Design, and Chapters 4–7 provide more detailed discussion of the methods involved in each of these phases. See Figure 1-6 for a more detailed diagram of the process, including key collaboration points and design concerns.
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 and brand strategy, 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 behavior 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 into professional roles; for consumer products, they tend to correspond to lifestyle choices. Behavior patterns and the goals associated with them drive the creation of personas in the Modeling phase. Market research helps select and filter valid personas that fit business
05_084113 ch01.qxp 4/3/07 6:00 PM Page 21
Chapter 1: Goal-Directed Design
21
models. Stakeholder interviews, literature reviews, and product audits deepen the designers’ understanding of the domain and elucidate business goals, brand attributes, 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, behavior 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 behaviors, attitudes, aptitudes, 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.
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 provide the much-needed connection between user and other models and the framework of the design. This phase employs scenario-based design methods 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.
05_084113 ch01.qxp 4/3/07 6:00 PM Page 22
22
Part I: Understanding Goal-Directed Design
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 terms 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. In addition to these scenario-driven requirements, designers consider the personas’ skills and physical capabilities as well as issues related to the usage environment. Business goals, desired brand attributes, 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, designers create the overall product concept, defining the basic frameworks for the product’s behavior, visual design, and — if applicable — physical form. Interaction design 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 provide guidance in determining appropriate system behavior in a variety of contexts. Chapters 2 and 3 and the whole of Part 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 first developed by Christopher Alexander, and more recently brought to the programming field by Erich Gamma, et al. 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.
05_084113 ch01.qxp 4/3/07 6:00 PM Page 23
Chapter 1: Goal-Directed Design
23
When the product takes physical form, interaction designers and industrial designers begin by collaborating closely on various input vectors and approximate form factors the product might take, using scenarios to consider the pros and cons of each. As this is narrowed to a couple of options that seem promising, industrial designers begin producing early physical prototypes to ensure that the overall interaction concept will work. It’s critical at this early stage that industrial designers not go off and create concepts independent of the product’s behavior.
As soon as an interaction framework begins to emerge, visual interface designers produce several options for a visual framework, which is sometimes also referred to as a visual language strategy. They use brand attributes as well as an understanding of the overall interface structure to develop options for typography, color palettes, and visual style.
Refinement
The Refinement phase proceeds similarly to the Framework Definition phase, but with increasing focus on detail and implementation. Interaction designers focus on task coherence, using key path (walkthrough) and validation scenarios focused on storyboarding paths through the interface in high detail. Visual designers define a system of type styles and sizes, icons, and other visual elements that provide a compelling experience with clear affordances and visual hierarchy. Industrial designers, when appropriate, finalize materials and work closely with engineers on assembly schemes and other technical issues. 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.
Development Support
Even a very well-conceived and validated design solution can’t possibly anticipate every development challenge and technical question. In our practice, we’ve learned that it’s important to be available to answer developers’ questions as they arise during the construction process. It is often the case that as the development team prioritizes their work and makes trade-offs to meet deadlines, the design must be adjusted, requiring scaled-down design solutions. If the interaction design team is not available to create these solutions, developers are forced to do this under time pressure, which has the potential to gravely compromise the integrity of the product’s design.
05_084113 ch01.qxp 4/3/07 6:00 PM Page 24
24
Part I: Understanding Goal-Directed Design
Initiate
Design
Build
Test
Ship
Goal-Directed Design
Stakeholder
Activity
Concerns
Collaboration
Deliverable
ch
Scope
Objectives, timelines, financial
Meetings
Document
define project goals
constraints, process, milestones
Capabilities &
Statement
& schedule
Scoping
of Work
Resear
Audit
Business & marketing plans,
Review existing work
branding
strategy, market research,
& product
product portfolio plans,
competitors, relevant technologies
Stakeholder
Product vision, risks opportunities,
Interviews
Interviews
constraints, logistics, users
with stakeholders
Understand product
& users
vision & constraints
User interviews
Users, potential users, behaviors,
Check-in
& observations
attitudes, aptitudes, motivations,
Preliminary
Understand user
environments, tools, challenges
Research findings
needs & behavior
Personas
Patterns in user & customer
Check-in
User & customer
behaviors, attitudes, aptitudes,
Personas
archetypes
goals, environments,
tools, challenges
Modeling
Other Models
Workflows among multiple
Represent domain factors
people, environments, artifacts
beyond individual users
& customers
Context Scenarios
How the product fits into the
Check-in
Tell stories about
personas life & environment &
Scenarios &
ideal user
helps them achieve their goals
Requirements
ements
experiences