work models and our system, so all customers can take advantage of it. Once we have this consolidated model, we study it for problems and inefficiencies. We develop an abstract work model that brings together data from all customers, keeping good ideas, fixing problems, and using technology to combine and remove steps. When done, we have a statement of how our users will work, if we can implement the Figure 1. Context model This and the fo l low ing models are examples of work models descr ib ing the use of email. This part ial model shows tha t the company's admin is t ra t ive groups constrain everyone by requi r ing certain repor ts and actions. The boss is also inf luenced by management requirements, and in tu rn sets requirements on the employees. The boss wi l l no t touch the computer, which affects wha t the secretary must do. The secretary asks the boss to change his work sty le to make the secretary 's job easier; fo r example to keep the paper mail in the o rder in which i t is g iven to him to make i t easier fo r the secretary to en te r his replies on-l ine. Figure 2. Physical model ThiS iS the physical env i ronmen t fo r our boss and secretary. Only the aspects re levant to our mail p rob lem are shown, no t the who le physical layout. The secretan /has a p r in te r In her own office. She shares a VAX w i th others. The VAX is over loaded and slow. The boss has no connect ion to the VAXmeven i f there is a terminal in his off ice, he never uses it, so i t is no t shown. The VAX IS ne tworked w i th o the r comput ers at remote sites. This ne twork does go down, so the secretary uses a s tore-andforward mail system. The VAX also has links to publ ic networks which can only handle plain t e x t messages. Figure 3. Flow model ThiS model shows the communi cat ion between people in the organizat ion. Messages sent to the boss are in tercepted by the secretary, who pr in ts them and passes t hem to the boss on paper. The boss wr i tes repl ies and gives t hem back to the secretary who sends the repl ies and o ther messages to the or ig inal sender and somet imes to others. Because the secretary uses s tore-andforward mail, she has no way of knowing i f the repl ies ever ge t th rough. We know the secretary is communica t ing w i th people by phone, bu t we do no t know why -pe rhaps to set up meet ings, we also do no t know how she coord inates w i th the boss offl ine. COMMUllICATIOllS Olin THI! ACM October 1993/Vol.36, No.10 97 r O Project Organization nnd Management F i g u r e 4. : S e q u e n c e m o d e l ThiS model shows the steps the secretary takes to answer the bess's mail from his handwrit ten replies. The secretary gets the stack of printed messages with the boss's; replies wr i t ten on them and works through the stack. The secretary may wri te a reply from the bess's wr i t ten reply, get fur ther cla rification from him, take other action such as calling the sender, or delete the mail w i thout doing anything. When the secretary has dealt with a message she marks the paper copy so she knows it is done. Decide to handle bess's mail Intent: Response Get stack to mail with bess's from boss ~'~, ~, System does not comments ~ ........... ~.~" know about stack Get yesterday's mail No good way to "~ #~ find message Find top message from stD::i i:t sy:ta~m ~ C~lel °r ct ~i ~ e i 2 ~ ~ i i c : r i p ~ D e I e t e ~ ~ . ~ " " " ~ C heckP!ff papa r / ~ / / " J ~ ~ copy and put aside F i g u r e S. A b s t r a c t f l o w m O d e l This is an abstraction of the work of communicating, incorporating the boss and secretary as well as other data. The secretary's role in helping the boss communicate has; been named "communication coordinator." Looking at other customers, we discovered group communication can break down when no one is handling it for the group. We borrow the idea of a communication coordinator frorn the secretary, and use it to solve the group's problem. The coordinator can manage a group's communications in the same way that secretaries manage their bess's. When support ing a group, the coordinator intercepts messages sent to the group as a whole and distributes them to individual members. Messages can still be sent to specific group members. The coordinator may be a group member playing both roles. r / 3 \ I ' ~ o n ' ~ ' ~ ' , ) ~ o r d i n a t o r , / ~ _ _ ] annotated 'it I / ~ , , ~ / " ~ ~ reply stack I / ~1 distributed ~ " ~ ~ " [ rnessage j " ~ message stack ( Notes: • A principal is any person or group whose mail is handled by another • Communication between coordinator and principal may be paper or electronic • Receipts may be for any message system to support it. We validate our redesign of the work by checking it against the data from customers we have visited and through Contextual Inquiry with new customers. When interviewing new customers, we look for aspects of their work our redesigned work model cannot account for. These refine and extend the redesigned work model. Making the work redesign conversation explicit ensures we do not do silly things unintentionally. For example, in creating a presentation, ideas move from slides to handout notes and back again as the creator tries different approaches to presenting the ideas. So a presentation system should support modifying slides and notes in parallel. Providing a notes facility that does not allow the slide to be changed, as some commercial systems do, is not enough. We verify any design idea against the redesigned work model to ensure that it fits into the users ' jobs well. We use it to see that the new work practice our system will support hangs together. We anticipate new problems our changes may cause, and
[1]
Wayne A. Bailey,et al.
Directed dialogue protocols: verbal data for user interface design
,
1989,
CHI '89.
[2]
Pelle Ehn,et al.
From System Descriptions to Scripts for Action
,
1992
.
[3]
Finn Kensing,et al.
Generating visions: future workshops and metaphorical design
,
1992
.
[4]
Marylin M. Keller,et al.
Software specification and design - a disciplined approach for real-time systems
,
1992,
Wiley series in software engineering practice.
[5]
Morten Kyng,et al.
Cardboard Computers: Mocking-it-up or Hands-on the Future
,
1992
.
[6]
Grady Booch,et al.
Object-oriented development
,
1986,
IEEE Transactions on Software Engineering.
[7]
Barry W. Boehm,et al.
A spiral model of software development and enhancement
,
1986,
Computer.
[8]
Morten Kyng,et al.
Design at Work
,
1992
.
[9]
John L. Bennett,et al.
Usability Engineering: Our Experience and Evolution
,
1988
.
[10]
Tom Stewart,et al.
Evolving task oriented systems
,
1992,
CHI '92.
[11]
Peter Bøgh Andersen,et al.
Language, Perspectives and Design
,
1992
.
[12]
Morten Kyng,et al.
Designing for a dollar a day
,
1988,
CSCW '88.
[13]
Michael J. Muller,et al.
Participatory design
,
1993,
CACM.
[14]
Douglas Schuler,et al.
Participatory Design: Perspectives on Systems Design
,
1993
.
[15]
Charles F. Martin.
User-Centered Requirements Analysis
,
1988
.
[16]
Jean-Marc Nerson,et al.
Object-Oriented Analysis and Design
,
1992,
TOOLS.
[17]
K. Mani Chandy,et al.
Software specification and design
,
1977
.
[18]
Michael J. Muller,et al.
Taxonomy of PD Practices: A Brief Practitioner's Guide
,
1993,
Commun. ACM.