Abstract
Designing products well requires a clear and detailed understanding of how people work. However design teams are not usually expert at understanding work, and there are no generally-accepted techniques for representing how people work appropriate to design. Without support for thinking about the customer, design teams tend to focus on the technology and the system delivered. In this paper, we describe the modeling techniques we have developed to represent work and show how they support product design activity.
Introduction
Any system [fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”][I] a design team delivers, in its function and its organization, structures the work its customers [II] do. This imposes the responsibility on designers to ensure they structure the customers’ work well. This requires a shift in the focus of design conversations to customers’ work and the work practice envisioned for a new system. The core challenge of customer-centered design is to enable this shift.
To understand how a system should structure the customers’ work requires discovery of the detail of how they currently work, both with and without technological assistance. Seeing behind the detail reveals what customers are fundamentally trying to accomplish, and uncovers the underlying strategy and structure that drive the work. These fundamental motives are not prone to change, but the means of achieving them can be modified and enhanced. The strategy and structure that people use to organize their work indicate what work styles are natural and can serve as an effective organization of the system. Innovation comes from recognizing these fundamental motivations and natural work styles, and enabling them more directly through the use of technology.
Typical design teams are not used to conversations about the nature of people’s work, how to re-design that work, and the role of a system in supporting the re-designed work. Most designers are not trained to understand the multiple dimensions of work practice. They are not in the habit of having explicit conversations about work practice as part of the design process. Enabling teams to do this work requires that they develop the skill and the language for these conversations.
So design teams need a language for work: an explicit representation of work practice, allowing them to record their understanding and communicate it to others unambiguously. The language acts as a “place” for the conversation to happen. It externalizes the team’s understanding, so it can be checked with each other and against the data. And it provides the symbols and syntax necessary to express important insights about the work.
In this paper, we present the language of work we have developed for our customer-centered design process [1]. This language allows us to express the rich detail about work needed to drive a design. It represents the concepts we have found, through practice, to be necessary to effective design. Using these basic concepts teams have taken on new ways of seeing work and have extended these concepts to develop other work models and variants of these to suit their problem.
We will present the language itself, and place it in the context of the design process by showing how the understanding of work it supports contributes to design.
Aspects of work relevant to design
Many aspects of work may be of interest for study and discussion depending on the purpose of the inquiry. An anthropologist, a sociologist, a psychologist, or a time-and-motion expert might each choose a different set of distinctions as important to their work. But for system design, we have identified four aspects of work which matter: intent, structure, strategy and concepts. We find out about these by looking behind the detail of work as it is done.
By intent we mean the purpose or motive that makes accomplishing a task desirable, independent of the means used to achieve it. The intent may be explicit, known and describable. Or it may be implicit, not enunciated by the customer as something they are trying to accomplish. We use “intent” instead of “goal,” a more traditional term, because “goal” implies a specific, achievable end state [2]. Often the motive driving work is not so definite. We studied a secretary who answers her boss’s electronic mail by typing his written responses into the system. Her explicit stated intent is to answer the boss’s mail. This intent is in service of a higher-order intent of making him more efficient in communicating with others. But she does not give this work, which usually amounts to typing in his written responses from paper copy, to a lower-level secretary, though she could. Through conversation, this led us to an additional implicit intent: to keep informed of what is happening in her boss’s job by monitoring his mail. “Keeping informed” is not a goal to be achieved: it is a state to be maintained.
Our study of work shows that an intent may exist in the work as a means of achieving other higher-order intents. For example, a user is searching through menus looking for a function to change line spacing. But this whole search is part of a larger set of activities in which he modifies font size, margins, and spacing. His larger intent is to give the content of each page a single theme. But this intent is driven by his structure for the brochure as a whole, in which each page expresses a single idea and the whole brochure has a distinctive, consistent look. This intent is driven by his desire to put his unique stamp on the booklet, while meeting his customer’s requirements. If we focus only on the specific behavior, we might improve the UI to make the line spacing function easier to find. But if we understand the higher-order intents driving the work we can respond with design changes that support them more directly.
The most fundamental high-level intents change very little over time. There is little we can do that will get rid of this designer’s desire to produce distinctive work. However, we can change how they accomplish this high-level intent. So we can address the desire for a consistent look through an apply-style function, which takes the style information from one page and applies it to another in a single action. This replaces all the lower-level intents driving the use of separate functions with a single function to meet the higher-level intent.
Several commercial products have provided such a copy/apply style function. This simplifies the customers’ work by eliminating the number of things they must think about to achieve their intent. The higher we go in addressing intents, the closer we get to addressing the fundamental work our users are doing, and the more creative we can be in our designs. The higher we go, the greater the impact we have on the work.
The impact we have on the work is limited by the scope of our project. If we have license to redefine the procedures by which people do their jobs, we can have a large impact on the work and can address high-order intent directly. If we are delivering an information system our ability to change the process it supports may be much more limited. If we are selling a product to a market, we are limited to changes that will be recognized as beneficial and accepted by our customers. Customers must be able and willing to make the transition to the new way of working.
Taken together, these collections of low-order intents comprise a strategy for accomplishing a higher-order intent. A strategy provides a pattern for doing work, breaking it down into manageable units. We have found that there are only a few underlying strategies to any given work task, so we can describe them even for a large market. When customers start work with a particular system, it is this strategy they are attempting to implement and that they expect to see reflected in the system. They do not necessarily plan their strategy explicitly. As they react to particular work situations, they may hypothesize what each next step should be. Or, they may have developed effective habits for similar situations, and apply it automatically. A strategy unfolds as we observe the details of how people work, seeing the steps and abstracting from them the patterns that guide the work.
Understanding the customers’ strategy guides design by showing the flow of work from action to action. The system should provide the function, access to function, and access to different parts of the system needed to support this pattern of work. By looking at the strategies of different customers, we can recognize the most effective strategies and build them into the system, making them available to all. By making strategies explicit, we can discover problems in how they are accomplished and build fixes into our systems. When the need to accomplish an entire intent is eliminated by our system, the strategies to accomplish that intent are also eliminated.
To implement strategy people put physical, organizational, or conceptual structure in place. People structure their world physically: certain tools ready to hand, organized for easy access; support material visible as necessary; less frequently used tools, material, and storage locations further away. For example, in every case of creative work we have studied, the first step involves collecting tools and reference material together to support creation. The intent of this step is to structure the environment to support the work of creation, so all the necessary materials are ready to hand. Or again, one company has as strategy for achieving their business goals to encourage community and communication between people. To implement this strategy, the company has structured their physical environment to support community. Communal break areas and reading areas encourage “hanging out” together. Work areas consist of communal places surrounded by individual offices.
Physical structure also shows where customers have to work around their environment to create structure meaningful to their work. A system can build in structure that matches. So, for example, a restrictive office environment requires a design team to hold impromptu meetings in hallways to get their work done; a restrictive file system directory structure requires users to invent elaborate naming conventions to represent meaningful relationships between files.
Physical structure gives hints for how to structure the system so that coherent activities are supported coherently, functions that are needed together are available in the same part of the system, and frequently used function is easy to access. As we support more of customers’ work on-line, we can harvest data about the structure necessary to the work and support it in the system directly, allowing users to work as they expect. Physical structure also implies strategy and intent which themselves drive system design.
People also structure their world organizationally: they partition the job among themselves to give everyone clear responsibilities which allow them to work usefully in parallel. They define expectations of how people will work, what they will do, and how they will coordinate in producing the result. In the work of developing software, we find there is always someone maintaining the integrity of the system-ensuring that the right code is included with each system baselevel to make a usable system. This person may be recognized by the organization with a job title and defined responsibilities, or it may be an entirely informal role. Either way, it is a common structure explicitly or implicitly put in place to get the job done.
Communication and coordination become part of the work any product must consider. A product which treats work as done entirely by individuals will fail. The different responsibilities show what types of work the system must support and how they are organized into coherent activities. The system can then respect the bounds of these jobs, so that it supports the work as people do it, or deliberately choose to change the structure of work to make work more efficient.
People structure their world conceptually: they make conceptual distinctions between parts of the work. These distinctions help people think about their work and how to do it. In software development we have the concepts module, version, change, baselevel, release. These concepts become the “matter” of the work-they are what people work on. Programmers work not only on modules-usually made real in the file system-but also on coordinated modifications to sets of individual modules (a “change”). A “change” may not be real in the configuration management system they are using (it is in some), but it is real in their talk and in the work.
When people work with a system, they expect to identify concepts they are used to manipulating. If concepts in their work and language are real in the system, it matches their expectations and allows users to do their work directly. If the system introduces new concepts they should not conflict with users’ existing concepts and terminology, or should be sufficiently close to the users’ expectations that they are easily learned.
These fundamental aspects of work-intent, strategy, structure, and concepts-are hidden in the detail of everyday actions. To reveal these details, we find that designers must study work as it is actually performed [3]. People do not spend their time thinking about the structure and implications of their work-they just do it. Even when a process is written down as policy, this rarely reflects what people really do, and is not sufficiently detailed to define what they do on a daily basis.
Designers can study the details of how people currently perform a task to abstract the key aspects of work from the details. From this understanding of work, designers can build an effective system. They need not duplicate current actions exactly in the system, but the details give us important clues to the natural structure and organization of work. Making the discussion of work the center of the design effort moves a team away from focusing on technology and re-centers that focus on the customer. Our approach to customer-centered design makes this conversation possible by defining a graphical language about work.
The four faces of work
We have found four perspectives on work to be useful for design. They model work with simple drawing techniques that describe the most basic aspects of work relevant to design: the culture and physical environment it takes place in, the pattern of human interaction and communication, and the basic tasks and steps involved in getting the work done. We provide separate modeling techniques, work models, to represent work from each perspective: context, physical, flow, and sequence models, respectively. Keeping the perspectives separate allows the designer to understand each aspect of work and think about design implications separately. Looking across the models allows the designer to integrate the four perspectives and understand the work as a whole.
The context model
Expectations and constraints may be embodied in business practices, such as compensation structure, reporting requirements, or the budget planning process. It is easy enough to discover explicit cultural effects. More challenging is to uncover their effect on the work, which may not be what is intended. An explicit statement that the organization values teamwork may be rendered moot by a compensation structure that rewards individual achievement. Prescribed procedures for doing work may not match what happens in practice. An organization may be demoralized by exhortations to “work smarter, not harder” with no support for changing work practice. Uncovering these effects requires looking behind the words of the explicit culture, to understand how it interacts with the work as it is actually done.
Distinctions: In the context model we describe the influencers who affect or constrain work. These may be an individual or formal group in the organization. It may be a collection of people who are not a formal group but thought of together (“management”). It may be external influencers such as the customer (and possibly multiple customer organizations), government regulatory bodies, standards groups, or competitors.
We represent the extent of the effect on the work: whether essentially everything about the work is affected by this influence or whether the influence is more partial. So the Food and Drug Administration influences the work of food and drug companies through its reporting and testing requirements, but this influence does not constrain everything about developing the food or drug product. On the other hand, everything an assembly-line worker does is affected by the requirements of the assembly process.
The context model represents the nature of the influence on the work. We represent the direction of influence (who is primarily affecting whom) and how pervasive it is (whether this is an influence of one individual or group on another or whether it is more pervasive across an organization). We also represent push-back-in real situations it is rare that influence is all in one direction.
The following kinds of influence tend to be relevant to design:
- Standards and policy which define and constrain how work is done or what can be used or bought, or the lack of such standards as a policy. So many companies define a standard PC configuration which they will support. Other companies live with standard procedures defined by themselves or imposed on them by customers or by the government.
- Power, both formal in the organizational structure and informal through people’s networks, expertise and history. Power shows up in who has the right to decide who will do what in their work and the extent of autonomy a person can have. So one boss sets up his secretary’s computer environment, limiting her ability to recover when anything breaks down. In another organization, reimbursement for expenses is controlled by administration, which enforces the requirements for filling out paperwork and can choose to allow exceptions.
- The values of a company or team: what they stand for that produces a set of expectations about how people will interact and work. So one organization has the expectation that a project will be completed the same way as it was the last time, resulting in a feeling that innovation is not welcomed.
- A group’s own sense of identity, the way in which what they do is affected by how they think of themselves. So one UNIX shop held that they did not need to do formal up-front analysis and design because “we don’t do process.”
- People’s emotions about what they do including fear about being laid off or getting in trouble for raising issues, or people’s pride in what they do. So knowing that email could be read by management led people in one organization to discontinue its use.
- The idiosyncratic style, values, and preferences of an individual or team create a work environment that circumscribes others. So one boss will not use the computer, forcing his secretary to handle all his email communication; another likes to play with technology, changing her secretary’s system out from under her.
Questions for Design: Each work model focuses designers on a different set of issues-each answers certain questions designers must ask to make design decisions. The context model enables a conversation around questions such as the following:
Is there anything in the context that we want to support so as to enable the culture (e.g. set up standards or enforce policy)?
Is there anything here we want to discourage because we want to foster a different way of working (e.g. open communication or equal power)? Since any design embodies assumptions about culture we should do it on purpose, taking account of the consequences of our actions.
What do our customers want and what will they buy? What do those who make the buy decision think important? If tools are considered worth spending money on but training is not, spending effort on improved training may be a waste of time.
What will resonate with customers’ values and identity? ®sthetics might be essential to a product for design shops. This might drive the entire focus of the product’s design. What aspects of the context are changeable and what do we have to accommodate, given the system under design? Government regulations, for example, can usually be treated as unchangeable. Internal climate may or may not be changeable, depending on the scope of the project.
Physical work models can be drawn at different scales: the overall work environment, an individual work place within that environment, or a single work artifact. The work site may be structured as an open “bull pen” with supervisors’ offices around the outside. It may consist of many individual cubicles dividing up a large room. A person’s workplace may be an entire building or buildings, if they are maintaining equipment. It may be a car or airplane if they work on the road. Within a work site there are places to do work, which may be offices, labs, work benches, or work stations. The work itself may involve creating or using artifacts which have their own structure.
An understanding of the physical environment is incomplete unless it includes how people respond to the environment by restructuring it. Do people accept the workplace as it is, or do they work around it? If the environment consists of doorless cubicles, do they put things in front of the door to gain a measure of privacy? Is an artifact used as intended, or do people change its use to suit their work?
Distinctions: Physical work models of a site or of a work place represent the following distinctions:
The placesin which work occurs: rooms, work stations, offices, and coffee stations.
The physical structures which limit and define the space: sites, walls, basements, desks, file cabinets, and other large objects.
The nature of the space itself-small or large, primary or secondary workplace, private or open, cluttered, or empty space available for changing work activities.
The hardware, software and other tools (calculator, rolodex, in basket, measuring tools, Post-Itsª, printer, fax) that are present in the space which support the work or seem related.
The communication lines by which people coordinate with others in doing their work: phone, network connection, beepers, fax, PA system. We show network connections not to model the network per se but to emphasize who is connected to whom, and therefore what communication among people we can automate.
The work objects that people create, modify, and pass around in support of the work-folders, spreadsheets, to-do lists, bills, ID cards, approvals, piles of stuff.
The layout of the tools, work objects, movable furniture, and walls in relationship to each other to support specific work strategy.
The access given by hallways, passages, and distance between users and work objects, tools, other groups, and other sites. This supports visualization of movement between places and the extent of movement necessary to get a job done.
A work object is the thing that is created, manipulated, and used in doing the work. We model work objects to show what people think about when they work and how they think about it. The work object reveals the assumptions, concepts, strategy, and structure that guide people in working with it. We model work objects if they intimately support the work or if we are studying the process of creating the work object itself. Work objects might be to-do lists, forms, documents, spreadsheets, physical objects under construction (circuit board, car, airplane).
Physical work models of an individual work object show: Information presented by the object, such as the content of a form (e.g. a doctor’s name, nurse’s name, patient’s name, and diagnosis). Parts of the object, which are distinct in the usage such as page, kind of page (table of content vs. title page), headline, or figure in a diagram. Structure of the parts, explicitly in the object as given, and implicitly in its usage: the division of a form into a section for the doctor’s use and a section for the nurse’s, the grouping of cells in a spreadsheet to represent part of the data for a single purpose, or the way some people use the top of a day within a calendar for meetings and the bottom for reminders. Annotations which indicate the informal usage of the object beyond that allowed for by its explicit structure: Post-Itsª stuck to a document, highlighting, and notes written on the side of a report Physical characteristics of the object: color, shape, number, nature of attachment (folder, paper clip, staple). Additional work distinctions that are reflected in a work object and that matter in its creation and use: past, current, and future in using a calendar, structure and content which repeats in a report from month to month, x-height and caps height in page layout.
Questions for Design : Taken together, physical work models show how the work structures and is structured by the physical environment. They give us hints about how customers organize their work to get things done and connect with others. Physical work models ensure we do not forget what our customers’ work environment is like. Our clients are often surprised at the “primitive” technology of their customers compared to their own. Physical work models give us ideas for how to structure the system and how to present it so that users can make natural hypotheses about system behavior (as in the desktop metaphor). Some of the questions stimulated by physical work models include:
How is work limited by the physical environment? The team’s charter determines what must be considered a limitation that must be accommodated, and what is open for change in a new system.
What are the strategies that the layout implies? Corporate strategy for how work should be performed is implied by the layout of a site. For example, we can infer from the nature of conference rooms in most organizations that they act as “meeting space” not “work space”-they are not dedicated to any specific work and have none of the supporting material for specific work in them. At the individual level, one person’s strategy for accomplishing work can be inferred from their layout and use of their space. So the collection of telephone, rolodex, and calendar in one corner of a desk implies that they are strategically placed to support communication and coordination with others.
What social interaction supports the work? How do we ensure that computer technology does not result in isolating people from each other? How is separation or interaction fostered by the current environment-do people hang out in the hallway or crowd into one office to work together? Does the real work happen in a common lab, with individual offices essentially unused? Can we create virtual communities with appropriate structure and communication mechanisms given what we know about actual communities, boundaries, space, and access?
What networks exist or are possible? Personal computers on the desk have a very different impact on the work if they are networked than if they are not. Computers linked into a network make it possible to automate communication between people and to provide on-line access to information; standalone PCs are individual tools. What other communications technology is appropriate and should be considered as part of a solution (beepers, fax, etc.)?
What needs to be easily accessible in doing the work? Proximity implies what is important in supporting the work and is therefore kept nearby.
Do people have to move around to do the work? Is this something they object to and put off for as long as possible? Or do they make excuses to go out when the work does not strictly require it? Is the work itself entirely mobile? How does mobility restrict the tools which can be effectively used?
Models of work objects support discussion of the following questions:
If the system is to support creating the work object, what does it need to support: what kinds of information should it present, what parts, structure and distinctions should it allow manipulating? What physical characteristics matter, and how can they be supported? What specific distinctions are used in manipulating the object, and how can we build them into the system?
If the system does not create the work object, how does it fit into the work the system does support? What strategies are implied by the work object and its use which the system might support?
How is the object used in practice? Is it written on, annotated, or otherwise used as a support to the work beyond its explicit function? How will these usages be supported by the new system-if the work object is automated, can the on-line version be annotated? Can we eliminate the object altogether, and if so can we account for its usage as well as its explicit purpose?
The flow model
All significant work is accomplished by multiple people cooperating to achieve a result. To understand the structure of work, we must understand how work is coordinated among people and the patterns of communication between people that get the job done. The flow model allows us to look at and represent these patterns independent of time order so that we can support and optimize them.
Distinctions: Work is partitioned into roles: named collections of responsibilities organized to accomplish a coherent part of the work. When people cooperate to do work, they separate the responsibilities, explicitly or implicitly. “You write the paper,” they say. “I’ll review it.” Some responsibilities naturally go together: the writer might be responsible for researching the literature, as well as producing the initial text. The reviewer might be responsible for checking consistency with other writers, as well as factual accuracy. Other responsibilities are naturally distributed among people. It is ineffective for someone to be their own reviewer, so this responsibility is usually split from the writer.
Roles are not the same as job titles. A job is an organization’s formal definition of responsibilities to the organization. We find that people always add their own idiosyncratic structure around this. So a manager may also be coach, first line help, and system maintainer; a secretary may also be organizer, conscience, and taskmaster. The important roles in accomplishing work always exceed formal job definitions-some of the more creative job definitions, such as Apple’s “software evangelist,” give explicit recognition to roles that are usually implicit. Roles also break down the work to a finer level of detail than formal jobs. I may be writer on one document, reviewer of another, and coordinator of still another. One person can play several roles and the same role will often be played by several people, however people do not share roles the way they share responsibilities. Rather, several people may independently play the role and act together to discharge the responsibility.
We often find it useful to represent several people or roles as a unit, a group. We do this when the existence of the group affects how work is done. We may cluster roles this way when the group as a whole has common goals or is taking action together. We may be showing that outside people interact with the group as a unit, or has the same interaction with all the members. We can also show the interaction between a group member and the group as a whole.
Roles interact to get work done. The communication and coordination that make up this interaction are represented as flow. Flow may consist of informal talk and coordination, or it may consist of passing work objects. Representing flow between roles in an organization gives us a bird’s-eye view of how work in that organization is done. Work objects are the “things” of the work-they are thought of and manipulated as if they were real. A work object may be physical, such as a document or message. It may also be conceptual-for example, if a design conversation is thought about as though it has members, a history, attributes (public or private) and an existence separate from any one member or topic, it may warrant representation as a work object.
The communication topic represents the detail of the talk or coordination represented by a flow. These are actions as opposed to work objects, such as talk to set up meetings, arranging for review, asking for help.
On occasion we represent a place that people go in and out of in order to get their work done, if it is central to the work of coordinating and collaborating. This is often a meeting room or communal space such as a coffee area. It may occasionally represent a logical place, such as for the storage of data.
Questions for Design: The flow work model supports the following conversations about the design:
What roles will we support and how? What roles are central to the work? How are they supported in our system? Do we keep these roles as central in our system, or do we enable their responsibilities to be distributed to more people? If we distribute responsibilities do we over-burden other roles?
What is the appropriate clustering of function and the function central to the role? Describing a system only in terms of its function or the tasks it supports obscures the appropriate structure to support a role. Role is the central organizing principle of work: tasks and functions exist to support the work of a role. Understanding the roles a system will support structures the system we deliver.
How do we ensure each user can easily perform their different roles? This applies to users who perform several roles and must switch between them and to those who perform only one role and do not want to be confused by extra function.
What are the patterns of sharing and communication that we need to support? Are people handing work off to each other or reviewing work in multiple passes? How do we support such interaction in our system? What additional informal communication do we need to account for?
What does our support or automation of a role do to people’s jobs? Are we eliminating a job in eliminating a role? Would we free people to do more interesting work? Or would it be better to enable the job than to automate it?
What is getting in the way that we can overcome? How do we coordinate the multiple technologies for communication (email, telephone, fax, beeper, paper mail)? How do we limit the amount of interruption and the volume all these sources of information cause?
How do we support the movement of information and work objects into and out of other work places and how do we support communication from that place. If work is done in a group, how do we support the group’s work place?
The sequence model
The sequence model represents the steps by which intents are achieved. A sequence model can describe work at varying levels of abstraction, from the overall sequence of actions across an organization to the detailed steps of interacting with the UI of a specific system. Depending on the granularity of the view, modeling the steps in their exact sequence will reveal different aspects of how intents are achieved. At a high level we might model the hand-offs between group playing different roles. For example, a change request review board reviews incoming requests and passes accepted requests to a development group; the development group distributes them for completion; the developer gives the completed module to a configuration management group to build and test. At the individual level for the same task, we can model the actual steps that a person takes to create the module including when he receives the requests, when he asks others for help or review, and when he hands it to configuration management. This permits us to see work on a single module in its relation to the organizational process. At the UI level, we represent menu picks, dialog boxes, and other interactions with the system’s interface.
The sequence model is most similar to flow diagrams or task analysis [4, 5], but is unique in stating the intent and trigger for the sequence.
Distinctions: In the sequence model, we state explicitly the intent the sequence is intended to achieve. Secondary intents will be embedded in this primary intent, and they are named as they are identified.
A trigger causes a sequence of actions. It is the notification to the user to take action. Triggers we have seen include the height of a stack of paper on a desk, the arrival of mail, receiving a request, seeing a misplaced line of text in a document.
A step is the action or thought preceding an action. In an actual sequence model a step represents what actually happened. As we step back from the actual steps and look for purpose and strategy the steps become more abstract. They move away from specific behaviors toward fundamental purpose.
Arrows connecting the steps indicate order, loops, and branches. These reveal strategic and repetitive patterns of work. When the customer must make a decision about how to proceed we show that as a branching path. The order gives us an access road map to ensure smooth transitions between tasks and allows us to see what steps could be combined or skipped without serious violation to the users’ conception of what is going on in their work.
Questions for Design: The sequence model shows the particular steps needed to achieve some task in the work. Examination of the sequence model addresses the following questions about the design:
What is the underlying strategy of a person, team, or group in doing the work? How does each step contribute to this strategy? The strategy is implicit in the steps of the work and the intents they address.
What are the fundamental tasks of the work? Of all the possible ways people might approach the problem, which do they choose? At any decision point, there are many decisions that could be taken. But when we understand work from its underlying intent and strategy, we discover that only a few decisions actually will be taken in any particular case. This representation allows us to design to the actual nature of work rather than designing a set of features to solve all possible problems. The result is systems that are simpler to understand and easier to build.
What functions and clustering of functions are needed to support the work? The sequence models tell us how to cluster the function supporting a task to give the system a coherent structure, with convenient access between the parts of the system. The other work models place the tasks in a meaningful context and show how they relate to jobs done by people. This allows us to design the system as a whole, to support the work as a whole. It allows us to see the underlying intent of the work and support it directly, rather than addressing individual problems by providing individual features.
What are the triggers that notify the user to start a work task? When we automate work practice which is currently manual, we take away the physical triggers that start work happening. For example, if the trigger to read my mail is that the stack of mail has gotten precariously high, what happens when mail goes on-line? What is the trigger to deal with the backlog of mail if unread messages are decorously hidden away in a folder in a window in the mail application? To support the work well, we need to replace those triggers which are necessary to get work started. At the same time, we need to ensure our triggers do not disrupt the work. A stack of paper is a gentle, persistent reminder that there is work to do. A flashing icon, a beep, or a dialog box are all insistent demands that work be attended to now. We must ensure that our triggers match the importance of the work as the user sees it.
What gets in the way? We often discover that the user is completely derailed from their intent by the need to work around some problem. This is the first and easiest opportunity for re-design-making the work more efficient by eliminating and streamlining steps. The second opportunity for re-design is by changing the steps to a new process to achieve the intent. The third is to eliminate the intents themselves by addressing higher order intents directly.
Conclusion
Each of the above work models presents a different perspective on the work. These perspectives interlock: a role has responsibilities and undertakes tasks to discharge these responsibilities. The sequence models show how these tasks are accomplished in detail. The responsibilities and manner of accomplishing them are driven by organizational context and culture as shown on the context model. The work represented by the sequences is done within the work environment described by the physical environment model, and is done with and to the work objects represented by the individual work object models. When we step back and look at the models together, we see all the different aspects of the work and how they relate to each other.
Work models are built by first observing, inquiring into, and representing particular instances of work. Each work model shows work as it is and any problems that impede the work. Once we have a set of each type representing a cross-section of the customer community, we can build an abstraction of each type, and for sequence models, an abstraction for each intent. These abstraction make the underlying patterns of work across customers explicit. These abstractions can be documented on-line and kept as part of the project’s working documents. At the same time, it captures the variation between customers by showing any unique structure or details put into practice by each customer site. We can then decide the kind of work we want to support. We can take a good idea for approaching the work implemented by one of our customer sites, and build it into the system to make it available to all. We can streamline the work, removing extra steps and taking advantage of technological possibilities. From this re-designed work practice we can design a system that supports our new work practice and drives the design of the user interface and system implementation. Our customer-centered design approach provides techniques for all these steps.
Work models shift design teams to considering work as the center of design activities. They do this by providing a graphical language and representation of work. Any language, in the symbols it provides, chooses concepts to emphasize and concepts to ignore. If a symbol is provided for a concept, we can talk about it; otherwise the concept can only be addressed with difficulty, by indirection. The graphical languages used for design can provide only a limited set of symbols. If a symbol is provided in this small set we are almost forced to think about the concept it represents, if only to choose not to use it. If such a limited language is to guide design, it must contain exactly the necessary concepts for effective design. Additional concepts will distract; missing concepts will limit the resulting design. The right language allows us to have effective conversations, rich in detail where the detail is important, but abstracting out aspects which are unimportant to our purpose.
The four views of work described in this paper give designers four perspectives to take when looking at any work situation. Each perspective incorporates its own set of distinctions about work relevant to that perspective. Most people are not trained and do not naturally see the structure, strategies, concepts and relevant dimensions of work in the context of customers and systems. Certainly such training is not typically part of a design and engineering curriculum. These work models embody the knowledge we have developed over years of working with customers, teams and systems. Using these modeling techniques helps a team see rich aspects of work relevant to design. The multiple models encourage the team to explore each aspect of work separately and coherently before trying to understand them all together.
Modeling the work makes a team’s understanding of their customers’ work concrete. It gives them something which they can create, touch, talk about, and collaborate in making. It turns the conversation about work, which is nebulous, into a conversation around an explicit model so that all members of the team can refer to the same external representation. Because the conversation is grounded in an concrete representation based on real customer data, teams find it easier to agree on how the customer works, what in that work should be re-designed, and how the re-designed work practice should be supported by the system.
When used as part of the design process, models such as these drive the team’s understanding of the customer. These models cause the design conversation to shift from technology to the customer. These models become the content of the design conversation, the agreement among the team that all team members can refer back to, the touchstone for testing design ideas, and the historical record of the design conversation. They are the linchpin of understanding the customer, and so of customer-centered design.
Footnotes
[I] Throughout this paper we will use “system” to mean both software or hardware products sold to a market and also whole systems of hardware, software, and procedures designed for internal use within a corporation.
[II] Throughout this paper, we will use “customer” to indicate those who depend on a system in some way, and “user” to denote those who interact with it directly.
References
[1] K. Holtzblatt and H. Beyer, “Making Customer-Centered Design Work for Teams,” Communications of the ACM, October, 1993.
[2] S. K. Card, T. P. Moran, and A. Newell, The Psychology of Human-Computer Interaction. Lawrence Erlbaum Associates, Hillsdale, NJ, 1983.
[3] K. Holtzblatt and S. Jones, “Contextual Inquiry: A Participatory Technique for System Design,” Participatory Design: Principles and Practice . Aki Namioka and Doug Schuler (Eds.), Hillsdale, NJ: Lawrence Earlbaum Pub. 1993.
[4] M.D. Phillips, H. S. Bashinski, H. L. Ammerman, and M.F. Claude, “A Task Analytic Approach to Dialog Design” Handbook of Human Computer Interaction , p835. M. Helander (Ed.). New York: North Holland, 1988.
[5] J. Carter Jr., “Combining Task Analysis with Software Engineering for Designing Interactive Systems” in Taking Software Design Seriously . John Karat (Ed.), p. 209. Academic Press, NY, 1991.[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]