corel Exhibit 2016
`Microsoft v. Corel
`IPR2016-01083
`
`Corel Exhibit 2016
`Microsoft v. Corel
`IPR2016-01083
`
`

`
`Contextual Design: Defining Customer-Centered Systems
`is the premier title in the Morgan Kaufmann Series in
`Interactive Technologies.
`
`Stuart Card, Jonathan Grudin, Mark Linton, Jakob Nielsen,
`Tim Skelly, Series Editors
`
`

`
`CONTEXTUAL
`
`DESIGN
`
`Defining Customer-Centered Systems
`
`HUGH BEYER
`
`KAREN HOLTZBLATT
`
`INCONTEXT ENTERPRISES
`
`Morgan Kaufmann Publishers, Inc.
`San Francisco, California
`
`

`
`Senior Editor
`Production Manager
`Production Editor
`Cover Design
`Cover Photo
`
`Diane Cerra
`Yonie Overton
`Elisabeth Beller
`Ross Carron Design
`Will Crocker/
`THE IMAGE BANK
`
`Text Design
`Copyeditor
`Proofreader
`Compositor
`Illustrator
`Indexer
`Printer
`
`Ross Carron Design
`Ken DellaPenta
`Jennifer McClain
`UpperCase Publication Services
`Cherie Plumlee
`Valerie Robbins
`Courier Corporation
`
`Designations used by companies to distinguish their products are often claimed as trademarks or
`registered trademarks. In all instances where Morgan Kaufmann Publishers, Inc. is aware of a claim,
`the product names appear in initial capital or all capital letters. Readers, however, should contact the
`appropriate companies for more complete information regarding trademarks and registration.
`
`Morgan Kaufmann Publishers, Inc.
`Editorial and Sales Office
`340 Pine Street, Sixth Floor
`San Francisco, CA 94104-3205
`USA
`Telephone 415/392-2665
`Facsimile (cid:9)
`415/982-2665
`E-mail (cid:9)
`mkp@mkp.com
`WWW (cid:9)
`http://www.mkp.com
`
`Order toll free 800/745-7323
`
`O 1998 Morgan Kaufmann Publishers, Inc.
`All rights reserved
`Printed in the United States of America
`
`02 (cid:9)
`
`01 (cid:9)
`
`00 (cid:9)
`
`99 (cid:9)
`
`98 (cid:9)
`
`5 (cid:9)
`
`4 (cid:9)
`
`3 (cid:9)
`
`2
`
`No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or
`by any means—electronic, mechanical, photocopying, recording, or otherwise—without the prior written
`permission of the publisher.
`
`Library of Congress Cataloging-in-Publication Data
`Beyer, Hugh
`Contextual design : defining customer-centered systems / Hugh
`Beyer, Karen Holtzblatt.
`p. cm.
`Includes bibliographical references and index.
`ISBN 1-55860-411-1 (pbk.)
`1. System design. 2. System analysis. I. Holtzblatt, Karen.
`II. Title.
`QA76.9.S88B493 1998
`004.21--dc21 (cid:9)
`
`97-35927
`CIP
`
`

`
`20 (cid:9)
`
`Chapter I Introduction
`
`THE EVOLUTION OF CONTEXTUAL DESIGN
`
`Contextual Design grew over many years of working with design teams on different
`problems. As we recognized places in the process that teams had difficulty with, we modified
`the process or introduced new steps to address the problem. Here's a summary of how the
`process grew.
`Contextual Inquiry (CI) was the first part of the process. Karen Holtzblatt developed it as
`a response to a challenge from John Whiteside: design a process that would lead to new kinds
`of systems rather than iterating existing systems (Holtzblatt and Jones 1995). Prototyping and
`usability testing could iterate an existing system, but couldn't suggest wholly new directions.
`CI meets the challenge by putting designers and engineers directly in the customers' work con-
`text, thereby giving them the richest possible data to invent from. From this beginning, inter-
`personal issues were central; cross-functional CI teams developed a shared understanding of
`the customer from the beginning to alleviate the transition to development. The core process
`for CI was worked out with Sandy Jones by working with several engineering projects.
`Contextual Inquiry produces vast amounts of detail, and managing the quantity of infor-
`mation became difficult. So Holtzblatt adapted the affinity diagram process to reveal the order
`and structure in the data collected during contextual interviews. This became the classic CI
`process taught for many years at places such as the Conference on Computer-Human Interac-
`tion (CHI).
`Paper prototyping to test a design is an adaptation of Participatory Design methods, espe-
`cially those developed at Aarhus University (Ehn 1988; Greenbaum and Kyng 1991), combin-
`ing them with the style of interviews used in CI. Paper prototypes were introduced to iterate
`designs with customers without the need to commit anything to code. In this way, a design
`could be tested with minimal investment.
`Working intensively with design teams revealed that when designing for the customer,
`there wasn't a good way to represent design alternatives. The Pugh matrix process provided a
`way to envision several design alternatives and combine them to produce new alternatives,
`while keeping team members from butting heads (Pugh 1991). This process, much modified,
`became the visioning process in Contextual Design.
`In sketching out system designs, we tended to get into unwanted arguments in the teams.
`UT sketches tended to divert the team into UI design prematurely, and no other formalism
`existed to show the structure of the system from the user's point of view. We developed the
`User Environment formalism as a way to capture in standard form the sketches we wanted to
`represent our early designs. One of the first uses of the formalism was to represent a complex
`design integrating nine point products, showing each product team their place in the overall
`design.
`But we discovered that teams still had a hard time seeing design implications in the hier-
`archical structure of an affinity diagram. An affinity doesn't show the structure or pattern of
`work; it reveals issues but doesn't show how to structure a solution. Work models are a formal-
`ization of informal sketches of customer work. As we used these models in different design sit-
`uations, we became more confident that they did represent the key aspects of work for most
`design problems, and we standardized the five that Contextual Design now includes. C>
`
`

`
`Contextual Design (cid:9)
`
`21
`
`Finally, we found that it was too hard to lead a team through the transition from consoli-
`dated models to User Environment Design; it was still too much like magic. So we introduced
`an explicit visioning step to create the new design. At first we had people work out the details
`in redesigned sequence models, but then found they preferred to think pictorially in story-
`boards.
`At each point in the evolution of Contextual Design, we had a process that worked well
`enough for the problems at hand. But at each point we recognized problems we did not have a
`good way to solve. Contextual Design grew by taking a problem and using our principles of
`design to redesign the process to address it. Solving that problem would then reveal the next,
`and so on, until the process got reasonably stable. The result of this evolution is the process
`you now have. 0
`
`CONTEXTUAL DESIGN
`
`Contextual Design is a customer-centered process responding to these
`issues. It supports finding out how people work, so the optimal
`redesign of work practice can be discovered. It includes techniques that
`manage the interpersonal dimension of designing in cross-functional
`teams and keep designers focused on the data. And it leads the team
`through the process of discovering design implications for redesigning
`work practice, developing a corporate response, and structuring a sys-
`tem in support of the redesign.
`Contextual Design provides explicit steps and deliverables for the
`front end of design, from initial discovery through system specifica-
`tion. As such it works well for organizations putting ISO 9000 or SET-
`compliant processes in place: well-defined steps and measurable deliver-
`ables support the requirements of those standards for defined, repeatable
`processes. Though optimized for large, complex projects, Contextual
`Design has been successfully used on small projects as well. And be-
`cause Contextual Design provides a complete structure for the front
`end, teams have used it very effectively as a scaffolding into which they
`incorporate additional techniques and processes as the need arises.
`In our approach to process design, we recognize that much of
`what we do is to make explicit and public things that good designers
`do implicitly. Each of the parts of Contextual Design reflects a part of
`the design process that has to happen anyway—either informally in
`
`

`
`22 (cid:9)
`
`Chapter 1 Introduction
`
`CD externalizes good
`design practice for a team (cid:9)
`
`Talk to the customers (cid:9)
`while they work (cid:9)
`
`one person's head or publicly as an explicit design step. Making a step
`explicit makes it something that a team can do together and makes it
`possible to share the thinking process and results
`with others. It may also make the step take longer,
`but if you're currently going through a lot of argu-
`ment in design and rework, making that step explicit
`may well reduce the time it takes. And if your cus-
`tomers are complaining about usability and integration across ap-
`plications, taking the time may be what's required. Make sure, when
`you look at your processes, to take into account not just the formal
`time a step takes, but the amount of time it really takes in your organi-
`zation. If your engineering team is still arguing over what functions
`should be included in a release two weeks before test, you are still in
`the requirements analysis phase no matter what your project calendar
`says or how much code you've written. Deciding how you will use a
`design process—which steps are critical, which can be omitted—is an
`important first step for any project. (Chapter 20 gives guidance on
`how to tailor Contextual Design to specific situations.)
`The parts of Contextual Design, and the parts of the book that
`cover them, are as follows:
`Contextual Inquiry: The first problem for design is to under-
`stand the customers: their needs, their desires, their approach to the
` work. Even the hacker coding in the basement has
`some notion of who he thinks the customers are and
`what they want. A customer-centered process makes
`an explicit step of understanding who the customers
`really are and how they work on a day-to-day basis.
`Contextual Design starts with one-on-one interviews with customers
`in their workplace while they work. These are followed by team inter-
`pretation sessions in which everyone can bring their unique perspec-
`tive to bear on the data. This supports the team in developing a
`shared view of all the customers they interview. We'll describe Contex-
`tual Inquiry and how to apply it in Part 1.
`Work modeling: Understanding the customer is good, but cus-
`tomer work is complex and full of detail. At the same time it's intangi-
`ble; work practice is not naturally a concrete thing to be manipulated.
`Designers might be able to get away without an explicit representation
`of a simple work domain they are familiar with. But what happens
`when the work domain is complex and unfamiliar? What happens
`
`(cid:9)
`

`
`Contextual Design
`
`23
`
`Represent people's work in
`diagrams
`
`Pull individual diagrams
`together to see the work of
`all customers
`
`when it crosses multiple departments in an organization? How do you
`communicate and share knowledge of a way of working? For these sit-
`uations, Contextual Design provides a concrete rep-
`resentation. Work models, built during interpretation
`sessions, provide a concrete representation of the
`
`work of each customer interviewed. There are five (cid:9)
`kinds of work model, each providing a unique per-
`spective on the customer. Each perspective is complete, showing the
`whole work practice, yet focused on a single set of issues. These work
`models are described in Part 2.
`Consolidation: Systems are seldom designed for a single customer.
`But designing for a whole customer population—the market, depart-
`ment, or organization that will use the system-
`means being able to see the common structure inher-
`ent in the work different people do. Studying
`
`different customers will give designers a feel for the (cid:9)
`common approaches to work across the population, (cid:9)
`but it takes special techniques to make that "feel"
`explicit so that a team can see the common pattern without losing
`individual variation. The consolidation step of Contextual Design
`brings data from different customers together and looks across multiple
`customers to produce a single picture of the population a system will
`address. This is done through an affinity diagram (Brassard 1989),
`bringing individual points captured during interpretation sessions
`together into a wall-sized, hierarchical diagram showing the scope of
`issues in the work domain, and consolidated work models, showing the
`underlying pattern and structure of the work the design will address.
`Together, they show what matters in the work and guide how to struc-
`ture a coherent response. Consolidation is described in Part 3.
`Work redesign: Any system is put in place because its designers
`hope to improve their customers' work practice. That improvement is
`often implicit, presented as the result of adopting
`some technological solution. In Contextual Design,
`the team uses the consolidated data to drive conver-
`sations about how work could be improved and (cid:9)
`what technology could be put in place to support (cid:9)
`the new work practice. The team invents improved
`ways to structure the work rather than focusing on technical solu-
`tions. This vision drives changes to the organizational structure and
`
`Create a corporate
`response to the customers'
`issues
`
`(cid:9)
`

`
`24 (cid:9)
`
`Chapter I Introduction
`
`Structure the system work
`model to fit the work (cid:9)
`
`procedures, as well as driving the system definition. Using storyboards,
`the team develops the vision into a definition of how people will work
`in the new system and ensures that all aspects of work captured in the
`work models are accounted for. (Storyboards act like stories of the
`future in the sense used by Rheinfrank and Evenson [1996].) This
`process is described in Part 4.
`User Environment Design: The new system must have the appro-
`priate function and structure to support a natural flow of work. This
` structure is the system work model—the new way of
`working implicit in the system. It's the floor plan of
`the new system, hidden behind user interface draw-
`ings, implemented by an object model, and respond-
`ing to the customer work—but typically not made
`explicit in the design process. In Contextual Design, the system work
`model has an explicit representation in the User Environment Design.
`As a floor plan for the system, the User Environment Design shows the
`parts and how they are related to each other from the user's point of
`view. The User Environment Design shows each part of the system,
`how it supports the user's work, exactly what function is available in
`that part, and how it connects with other parts of the system, without
`tying this structure to any particular UI. With an explicit User Envi-
`ronment Design, a team can make sure the structure is right for the
`user, plan how to roll out new features in a series of releases, and man-
`age the work of the ptoject across engineering teams. Basing these
`aspects of running a project on a diagram that focuses on keeping the
`system coherent for the user counterbalances the other forces that
`would sacrifice coherence for ease of implementation or delivery.
`Building and using a User Environment Design for development is
`described in Part 5.
`Mock-up and test with customers: Testing is an important part
`of any systems development, and it's generally accepted that the soon-
` er problems are found, the less it costs to fix them.
`Rough paper prototypes of the system design test
`the structure and user interface ideas before any-
`thing is committed to code. Paper prototypes sup-
`port continuous iteration of the new system, keep-
`ing it true to the user and giving designers a data-based way of
`resolving disagreements. In prototyping sessions, users and designers
`redesign the mock-up together to better fit the user's work. The results
`
`Test your ideas with users
`through paper prototypes (cid:9)
`
`(cid:9)
`(cid:9)
`

`
`Contextual Design
`
`25
`
`Tailor Contextual Design
`to your organization
`
`of several of these sessions are used to improve the system and drive
`the detailed UI design. Paper prototyping is described in Part 6.
`Putting into practice: In the last chapter, we look at practical
`issues of putting a new design process in place. You'll encounter resis-
`tance, you'll have to work with the limitations of the
`organization you have, and you'll have to build on
`the skills you have in place. Altering Contextual
`Design to fit your organization and your specific
`design problems means recognizing which parts are
`critical and which are less necessary in each case. What works for a
`two-person team won't work for a fifteen-person team; what works to
`design a strategy for a new market venture won't work for the next
`iteration of a 10-year-old system. We'll discuss common project situa-
`tions, how to tailor the process to them, and how to ensure you don't
`lose the key features of the process along the way.
`Each part of the book has a similar structure: the first chapter
`focuses on the organizational situation and issues driving that phase of
`the design process. If you're looking for an overview of Contextual
`Design and the thinking behind it, concentrate on the first chapter of
`each part. The second chapter of the part describes what makes this
`phase of the design process customer-centered. It discusses how to
`make customer considerations central given the needs and constraints
`of this phase of design. And the third chapter of each part describes
`how to do the work, covering particular procedures and techniques
`that guide a team through the process.
`This book is intended to capture our experience designing customer-
`centered processes to meet a wide variety of team situations and design
`problems. As we describe in Part 3, there's a broad commonality of
`work practice across any industry, so we expect the solutions we've
`developed to be generally useful; there will be a lot here that you can
`pick up and apply in your own situation. However, every situation is
`unique, and you should expect that you will tailor the things you pick
`up to your problem, team, and organization. Treat Contextual Design
`as a coherent design process but also as a collection of techniques and
`a framework for thinking. Where you have other techniques you've
`found to be valuable, slide them into the appropriate place in the
`process. This is a starting point. What you do with it is up to you.
`
`(cid:9)
`

`
`Principles of
`Contextual Inquiry
`
`The core premise of Contextual Inquiry is very simple: go where
`
`the customer works, observe the customer as he or she works,
`and talk to the customer about the work. Do that, and you can't help
`but gain a better understanding of your customer.
`That is the core of the technique, but we find people are generally
`happy to have a little more guidance. What do interviewers do at the
`customer's site? How do they behave? What kind of relationship
`allows customers to teach designers the depth of knowledge about
`their work necessary to design well?
`In Contextual Design, we always try to build on natural human
`ways of interacting. It is easier to act, not out of a long list of rules,
`but out of a simple, familiar model of relationship.
`A list of rules says, "Do all these things"—you have
`
`to concentrate so much on following the rules you (cid:9)
`can't relate to the customer. It's too much to remem- (cid:9)
`ber. A relationship model says, "Be like this"—stay in (cid:9)
`the appropriate relationship, and you will naturally
`act appropriately (Goffman 1959).
`Many different models of relationship are available to us. A for-
`mal model might be scientist/subject: I am going to study you, so be
`helpful and answer my questions; it doesn't really matter whether you
`understand why I'm asking. A less formal model
`might be parent/child: I'll tell you what to do, and
`you'll do it because you want my approval (or else (cid:9)
`you'll rebel to show your independence). Each of (cid:9)
`these models brings with it a different set of atti- (cid:9)
`tudes and behaviors. Everyone knows what it is like
`
`Use existing relationship
`models to interact with
`the customer
`
`Design processes work
`when they build on
`natural human behavior
`
`
`
`
`
`(cid:9)
`(cid:9)
`

`
`42 (cid:9)
`
`Chapter 3 Principles of Contextual Inquiry
`
`when someone treats us like a child, and the resentment it generates.
`Ironically, the natural reaction is to behave like a child and fight back.
`Relationship models have two sides, and playing one side tends to pull
`the other person into playing the other side. Find a relationship model
`that is useful for gathering data, and as long as you play your role, you
`will pull the customer into playing theirs.
`
`THE MASTER/APPRENTICE MODEL
`
`The relationship between master craftsman and apprentice is an effec-
`tive model for collecting data. Just as an apprentice learns a skill from
`a master, a design team wants to learn about its customers' work from
`its customers. Though the model is no longer common, it is still suffi-
`ciently familiar that people know how to act out of it. When they do,
`it creates the right behaviors on both sides of the relationship for
`learning about the customers' work. We find that people with no spe-
`cial background in ethnography learn how to conduct effective inter-
`views much more quickly by acting like an apprentice than by memo-
`rizing a list of effective interviewing techniques. Building on this
`relationship model creates a strong basis for learning about work.
`Craftsmen, like customers, are not natural teachers, and teaching
`is not their primary job. But they do not need to be; the master crafts-
`man teaches while doing. A master does not teach by designing a
`course for apprentices to take. Nor does a master teach by going into a
`conference room and discussing his skill in the abstract. A master
`teaches by doing the work and talking about it while working. This
`makes imparting knowledge simple.
`Teaching in the context of doing the work obviates any need for
`the craftsman to think in advance about the structure of the work he
`does. As he works, the structure implicit in the work
`becomes apparent because both master and appren-
`tice are paying attention to it. It is easy for the master
`to pause and make an observation or for the appren-
`tice to ask a question about something the master
`did. Observation interspersed with discussion re-
`quires little extra effort on the part of either master or apprentice.
`Similarly, in Contextual Inquiry, team members go to the cus-
`tomers' workplace and observe while they are immersed in doing their
`
`When you re watching
`the work happen, learning (cid:9)
`is easy (cid:9)