A Participatory Design Technique High-Level Task Analysis, Critique, and Redesign: The CARD Method

Download as pdf or txt
Download as pdf or txt
You are on page 1of 5

PROCEEDINGS of the HUMAN FACTORS AND ERGONOMICS SOCIETY 37th ANNUAL MEETING-1993

A Participatory Design Technique for High-Level Task


Analysis, Critique, and Redesign: The CARD Method

Leslie Gayle Tudor,’ Michael J. Muller,2Tom Dayton? and Robert W. Root3

‘AT&T Bell Laboratories, Middletown NJ 07748 US


2U S WEST Advanced Technologies, Boulder CO 80303 US
3BeUc~re, Piscataway NJ 08854 US

ABSTRACT points of the practice, and a comparison with other, related


CARD (CollaborativeAnalysis of Requirementsand Design) participatory practices.
is a participatory technique for analyzing task flows and for
redesigning task flows, in software systems. It provides a FOUNDATIONS
macroscopic complement to the more microscopic design CARD is based on several types of evolving practice in the
activitiesthat are supportedby thePICTIVEtechnique. CARD field of participatory design.
uses the metaphor of a card game as the vehicle for commu- Observed Weaknesses in the PICTIVE Approach
nication and collaboration among users, developers, and de- While the PICTIVE technique has been quite effective, some
signers. We describe the technique, and provide illustrative practitioners have noted that it is time-consuming for the
sessionprotocolsand assessment data. The paper closes with design of large systems (Muller, 1992). Sessions tend to dive
a comparison to other relevant participatory practices, and a immediately into detailed design, and the task flow is often
discussion of CARD’Sshortcomings. assumed to be correct, rather than critically examined. How-
INTRODUCTION
ever, the hands-on nature of PICTIVE appears to be desirable
This paper describes a techniquefor participatorytask analy- for directly involving users, and the low-tech nature of its
sis and participatory redesign of one or more task flows that materials appears to be essential in maintaining its “equal
are to be supported by a software system. The technique is
opportunity” qualities (Muller, 1 9 9 1 ~see also Aiken and
called CARD (Collaborative Analysis of Requirements and Madsen, 1992).
Design). CARD is an informal or semi-structuredcard game In CARD, we attemptedto develop a different type of artifact
that supportscollaborativeanadysis and critiqueof a software (see Kensing and Munk-Madsen, 1992)from the paper-and-
system by a group of people -including users -who have pencil screen details of the PICTIVE technique. CARD
a variety of disciplines and skill sets. Heterogeneous design artifactsare focusedon the flow of the user’s task, and help the
groups are becoming more common and more important facilitator postpone detailed design questions until after the
(Dayton, 1991; Muller and Cebulka, 1990). Like the PIC- high-level task fiows have been fully analyzed. Detailed
TIVE procedure4(Muller, 1991b, 1992),CARD can be used design work can then be done collaboratively through PIC-
in one-on-one sessions, or for small groups. Unlike these TI?% or other participatory design practices (Bjerknes,Ehn,
activities, CARD operates at the level of a task analysisrather and Kyng, 1987; Greenbaum and Kyng, 1991; MuUer, Kuhn,
than of detailed design. and Meskill 1992; Namioka and Schuler, 1990,1993).
We begin with the background of the technique. We then Games for Group Design of Systems
describe CARD basics, and some of the issues in conducting To do this, we made use of the principle of famiry resem-
a CARD session. We provide assessments based work with blances (Ehn and Kyng, 1987). That is, collaborationis easier
two projects. We close with a criticaldiscussion of the weak for diverse groups of developers, users, and human factors
workers if they have some common language that provides a
1. AT&T Bell Laboratories, 200 Laurel Avenue, Middletown NJ bridge for communication (Dykstra, 1991) that is based in
07748-4801 US +1-908-957-6448lgt@rntqua.att.com. familiar activities. Most people in our culture have some
2. U S WEST Advanced Technologies, 4001 Discovery Drive, experienceof playing card games, and cards have been used
Boulder CO 80303 US +1-303-541-6564 for the “organizationalkit” approach to participatoryscenario
michael@advtech.uswest.com. development (Ehn and Sjogren, 1991). We therefore devel-
3. Bellcore, 444 Hoes Lane, Piscataway NJ 08854 US. Dayton: oped an informal, semi-structuredgameto support the design
Room RRC-1H226 +1-908-699-6843tdayton@ctt.bellcore.com process (e,g., Wildman, White, and Muller, 1993).
Root. Room RRC-1J205 +1-908-699-7763
broot@cttbellcore.com. Need to analyze an existing complex system
4. PICTIVE stands for Plastic Interface for Collaborative Technol- CARD was developed when human factors support was
ogy Initiatives through Video Exploration. requested for an existing in-house source code maintenance

295

Downloaded from pro.sagepub.com by guest on March 20, 2016


PROCEEDINGS of the HUMAN FACTORS A N D ERGONOMICS SOCIETY 37th ANNUAL M E E T I N G 1 9 9 3

system. The system was command-based and complex, greatly, of course.) The cards helped our realization,because
consisting of a maze of hierarchical screen arrangements. each card’s appearance on the table stimulated at least 15
Users had complained that (a) the sheer number of screens minutes of talk- not just about the screen appearanceof that
they were forcedto navigate through to accomplishtheir tasks particular step in the task, but about whether that step should
was excessive, and (b) the system task flow did not map onto andcouldexist! Gettingthroughthecardstack-showing the
the users’ conceptualization of their tasks. In the previous task flow -took the entire day.
iteration of the interface, task analysis and usability testing This third use of cards is appropriateat this intermediatestage
were conducted by the developers of the system. The users of task analysis - that is, immediately after conventional
had felt that they had clearly communicatedtheir frustrations. communication about business needs and task flow have
However, despite their input, the system had not been sig- reached an apparentasymptote,becauseparticipantshave run
nificantly modified, and their alleged involvement in out of topics they can easily represent and communicate
analysis and testing had been used as a justification for the through wordsalone. Eventuallythisuse of cardsalsoreaches
developers’decisions. asymptote. When this happens, each card simply ceases to
This tense working situation caused us to attempt to analyze excite prolonged discussion, and the laying down of cards
the shortcomingsof the existing system,and to attemptto find fmally begins to speed up -that is, the pacing of the CARD
amoredirect,concrete,effectivemeans for usersto make their sessionbegins to approximatethat of the one-on-onesessions
views clear, and to contribute their expertise to the design. describedabove. When this happens, the appropriatefocusof
CARD BASICS discussion is now the user’s day to day work flow, so all
One-on-One Sessions (Source Code Maintenance managers should be politely shuffled out of the room. The
System) cards are then used in the ways described in the previous
During our initial task analysis sessionson the fmt version of paragraphs.
the source code maintenance system, users had difficulty Materials
communicatingtheir task conceptualization,andattemptedto The physical details of the card artifacts appear to be impor-
describe their task goals in terms of the microscopic compo- tant. In preliminary work on a Metaphors Card Game for
nentsofthecurrentsystem(i.e.,thedatafieldspresentoneach design (Wildman, White, and Muller, 1993), we had at-
screen). Even this proved to be difficult,as users often failed tempted to use card-sizedslips of paper. Our initial version of
to recall the names of specific data fields and could not the game was unsuccessful, in part because people did not
describethem adequately. To help the users focusmore on the treat our cards like cards until we provided the Same informa-
task flow, and to refer to specific data fields which were tion on stiffer cardstock. In another project, we attempted to
difficult to recall, the analyst introducedflash cards of screen teach experienced developers how to design graphical user
images. She reduced each screen image and printed it onto 4 interfaces (Nielsen, Bush, Dayton, Mond, Muller, and Root,
by 6 inch card stock. As the user referred to a specificscreen 1992). While someof our materials had the stiffnessof cards,
or described an activity that took place during a specific they were also enormous: 9 by 12 inches. Participants’
subtask, the analyst would display the card that reflected the difficulty in manipulatingtheseoversizecardsinterferedwith
screen or activity. This process continued throughout the their learning of the graphical concepts.
session, until all cards for all subtasks were displayed so that Combining these lessons, we made the cards in CARD to be
the entire system could be viewed. closer to the size and stiffness of conventionalplaying cards.
Up to this point, the cards had been used as memory aids. We We hoped that this would permit the users to apply their tacit
developed a second process which was quite different from knowledge and attitudes about conventional card games.
the one in which the user was initiallypresentedwith the entire This, in turn, should allow them to focus on the task flows,
view of the system via the card display. In this second case, because they would have to spend less attention and effort
the user expressed her or his ideas €orimproving the system making the artifact do what they wanted. Although we made
directly through the cards. The user was requestedto show - no formal analysis,we observedmany cases of users manipu-
through card-tocard transitions, with commentary - an lating the screen image cards with gestures common to con-
improved task flow. This improved flow was captured on ventional card games.
videotape for analysis,and for combinationwith othersusers’ CONDUCTING A CARD SESSION
proposed task flows. Like PICTIVE sessions, CARD sessions usually work as
Group Sessions informal, semi-structured,small goup brainstorming activi-
GraphicalLayout System ties. Communication is facilitatedand given some structure
A third use of the cards arose when we tried to apply them in through the use of artifacts(e.g., Kensing andMunk-Madsen,
the above two ways for group task analysis sessions on a 1992; Mogensen and Trigg, 1992).
graphical layout system. These sessions were conducted in Our work with CARD is less mature than our work with
the field. We realized that the business needs analysis for the PICTIVE. Therefore, we will not attempt to characterize a
interface was unfinished, and that managers were the major “CARDprocessmodel” in the sameway that we have donefor
experts on the business needs. (The users also contributed

296

Downloaded from pro.sagepub.com by guest on March 20, 2016


PROCEEDINGS of the HUMAN FACTORS A N D ERGONOMICS SOCIETY 37th ANNUAL MEETING-1993

PICTIVE (e.g., Muller, 1992). Instead, we provide several separate screens?


session protocols that illustrate some of the more important A ...Let's go through the flow fust, and then we can
and characteristic aspects of CARD process. go into how we might combine them.
Protocol 1: Laying Out the Current Work Process U All right...And this- I don't believe is necessary,
In the fmt excerpt, the analyst is attempting to repeat back to because Idon't think I've ever doneanythingon this
the user her understanding of the user's task flow and usage of screen.
the system. The user corrects the analyst's account: A okay, so -?
Analyst: [Places first screen image card, which an- U So, I would say -W o w s card onto discard pile
nounces the project name] So that's the fust thing with disdainful gesture.] Yeah.
you see, the good old X X r r Y screen.' Then, that This excerpt shows the user easily indicating her preferred
comes up [places a screen image card of an initial task sequence, and removing those user interface activities
menu screen]. You press the return key. that had been interfering with her work. Of course, her view
User: You actually have to enter the word "APPL" - of the work flow was validatedagainstsimilar data from other
A Yeah- users.
U -to get the list of applications... Staying macroscopic
A And then you select ... Is this correct so far? One problem that had dogged the earlier task analysis work
U Yeah. was the users' tendency to explain and critique the task flow
in terms of detailed screen design issues and individualfields.
In this protocol, the analyst has used the cards to do a concrete
At one point in Protocol 2, the analyst clearly guided the
run-through of the task description that the user gave to her
discussionaway from suchfinegranularitydiscussions("Let's
earlier. The card image materials have supported the user's
go through the flow first, and then we can go into how we
clear understanding of the analyst's story, and the user's
might combine them."). This sort of maneuver was possible
correction of that story where required.
only after the analyst and the user had worked together for a
Protocol 2: Critiquing and Innovating on the Work complete session,and had built up some trust -trust that the
Process analyst would return to the users' detailedconcernslater in this
The CARD techniquealso supportsthe user taking the initia- or future sessions.
tive. In the following sequence, the user begins to rearrange
the screen images to indicate her preferred work flow: INITIAL ASSESSMENTS FROM TWO PROJECTS
Simplepost-session survey data are presented in Figure 1, for
A Now what I need for you to do, is to look at this and both the source code maintenance project (one-on-one ses-
tell me which screens - show me, by moving sions), and the graphical layout system project (group ses-
screens, if there are any screens that you think sions). In general, user responses were similar. Users had
should not even be there ... high confidencethatCARDsupprtedthemin making effective
U: Okay. Fakes the XX/YY project announcement comments, and in communicating their views to the analyst.
screen and pantomimes throwing it away] They also believed that they had had the opportunityto check
A [laughs] Okay. the analyst's understanding of the users' views. Finally, users
u [Removes the initial menu screen, and indicates indicated that they had found the sessions interesting, valu-
xx/w and menu screens in discard pile] In my able, and enjoyable,and that they would like to participate in
fantasy world, both of these would be gone, be- them again. There was some preference expressed for group
cause there's no reason why I should have to first sessions rather than individual one-on-one sessions. This
call up XX and then call up ZZ. First, at the preferencewas expressedmost stronglyby participants in the
systemcommand line, I type "zz" but that's not group sessions.
enough. Then I have to call up all the applications, PROJECT OUTCOMES
and then go to ZZ again. So, you know, I've just In the source code maintenance system, CARD resulted in
gonethrough three stepswhere, you know,it should several positive outcomes. First, it provided an effective
have been one in my opinion ... So I'l get rid of means of communication between the users and the system
those. analyst. Co-creationandco-evaluationof new taskflows,and
A Okay, great. What else? shared responsibility for the resulting design, helped to r e
u [Indicatingtwo screensthat are not yet discarded] establish trust in what had been a tense political situation.
...I guess these two are necessary, at least for the A second positive outcome in the source code maintenance
task flow - system was that the analyst left the sessions with a complete
A: -for the task - high-level design. She was able rapidly to convert this into
u -I don't know if they really need to be on two paper-and-pencil materials for subsequent detailed design
with the users in PICTIVE sessions. After the PICTIVE
5. Systems names have been replaced with letters "XX," "YY", sessions, the analyst created experimental prototypes based
" ~ " , WZZ"

297

Downloaded from pro.sagepub.com by guest on March 20, 2016


PROCEEDINGS of the HUMAN FACTORS AND ERGONOMICS SOCIETY 37th ANNUAL MEETING-1993

ee

I could describe my job.

I could make critical comments

............................... I believe that the analysts understood me.


...............................................
help me do my job better.

.... .................
%

t
I believe thatthe analysts understood me.
.................................................................................................................................... ..................... .........
check whether the analysts understood me.
..................................................................................... ....................................................
I understood the current system better as a result of this session. 0
I understood the prcpsed new system better as a result of this session.

I felt fiee to express mys


................................................
Procedure was interesting.
0 Source code maintenance system (d) Procedure was valuable.
@ Graphical layout system IF^)

I would Fefer to participate one-on-one with an analyst. I 1

Figure 1. Assessment data from two analyses using C.A.R.D.

on the CARD-generatedhigh-level design and the PICIIVE- CARD is also somewhat similar to the participatory tech-
generated detailed design. In usability testing with these niques used in the Amsterdam Conversation Environment
prototypes, users rated the new design highly. project (Dykstra and Carasik,1991). In this work, Dykstra
Theuse of CARD in the gmphicallayoutsystemwas different, used paper airplanes as simulations of electronic mail mes-
as described ("CARD Basics: Group Sessions"). The par- sages, and varied some of the physical attributesof the paper
ticipants did not achieve a completedesign: rather, the initial airplanes to signifyattributesof the messages(e.g., private vs.
design that the developers had brought to the session was public, etc.). Dykstra appears to have made use of the family
questionedby the users in fundamentalways. All participants resemblanceandfamiliarityof her users'handling of thepaper
agreed that these insightswere important,and that the changes airplane artifacts, similarly to our use of card analogies.
should be made before the design was implemented. They Althoughwe have found CARD to be a successfultechnique,
also agreed that whatever design was created to meet the new it is not without its flaws. First, CARD may easily omit
requirementswould better supportthe users' work objectives, important detailed design issues. This is why we have used
because the designers now better understood the users' real PICTIVE as a microscopic complement to the macroscopic
goals, subgoals, preferences in work flow, and constraints. CARD technique. Other fine-grained design activities (e.g.,
The redesign based on the CARD session is in progress. Halskov Madsen and Aiken, 1992)might also meet the need
CONCLUSION: CRITIQUE AND DEFENSE OF CARD for the more fine-grained analysis and user action.
In someways, CARD is similarto the Scandinavianmock-up A secondproblemmay be more subtle. Protocol 2 showed the
procedures (e.g., Bodker et al., 1987; Ehn and Kyng, 1991). need for the analyst to serve as a kind of process manager,
CARD may provide a more hands-on means for the users to responsible for guiding the session from high-level task flow
make direct changesin the workflow. Whilemock-ups do not to low-leveldesign issue, and back again. This puts too much
appear to have the CARD'S family resemblance to common power in the hands of the analyst, and too little in the hands of
activities(card games), they may provide a more encompass- the user or users. The analyst's conscious or unconscious
ing view and critique of the work environment. personal agenda may interfere with the expression of the

298

Downloaded from pro.sagepub.com by guest on March 20, 2016


PROCEEDINGS of the HUMAN FACTORS AND ERGONOMICS SOCIETY 37th ANNUAL MEETING-1993

users' ideas. We criticized the current state of the art in Kyng, M. (Eds.),Computers and Democracy: A Scandi-
software rapid prototypingon exactly these grounds (Muller, navian Challenge. BrooHield, VT: Gower.
1991b). Unhappily, we have no convincing solution to this Ehn, P., and Kyng, M. (1991). CardboardComputers: Mock-
problem for CARD ing-it-up or Hands on the Future. In J. Greenbaum and M.
A third potential problem is that CARD may sometimes be Kyng (Eds.), Design at Work: Cooperative Design of
biased by the current work flow. That is, the use of existing Computer Systems. Hillsdale NJ: Erlbaum.
screens and existing task flows may inhibit the creation and Ehn, P., and Sjogren, D. (1991). From System Descriptions
design of innovative task flows and work processes. We do to Scriptsfor Action. In J. Greenbaumand'M. Kyng (Eds.),
not have a formal counter-argumentto this criticism. How- Design at Work: Cooperative Design of ComputerSystems.
ever, in our informal experiences in the source code mainte- Hillsdale NJ: Erlbaum.
nance project, we observed that the results of the CARD Greenbaum, J., and Kyng, M. (1991). Design at Work: Co-
sessions were consideredradically different from the existing operative Design of Computer Systems. Hillsdale NJ:
design. In fact, the degree of changethat werecommendedas Erlbaum.
a result of CARD sessions led to controversies with the HalskovMadsen,K.,andA&en,P. (1992). Someexperiences
developers and with the users' management. This suggests with cooperative interactive storyboard prototyping. In
that CARDinfactdoes supportindependentanalysisby users. PDC'92: Proceedings of the Participatory Design Con-
Lastly, we recognize that CARD is not a formal task analytic ference. Cambridge MA: Computer Professionals for
method. It is too pragmatic, and too grounded in the users' Social Responsibility,in press.
daily practice. CARD might be used to provide some of the Kensing, F., and Munk-Madsen, A. (1992). Participatory
s o w e data for a more formal analysis. design: Structurein the toolbox. InPDC'92: Proceedings
ACKNOWLEDGMENTS of the Participatory Design Conference. CambridgeMA:
We thank the following people for advice, criticism, and ComputerProfessionatsfor SocialResponsibility,in press.
encouragement: ElizabethErickson, Cathy House, and Steve Mogensen, P., and Trigg, R.H. (1992). Artifacts as Triggers
Stein. Constructive criticism of thePICTIVE techniquewas for ParticipatoryAnalysis. In PDc'92: Proceedings of the
provided by practitionersJanice Housten, Darren Kall, Ellen Participatory Design Conference. Cambridge MA:
White, and Daniel Wildman, and also by Mike Atwood, ComputerProfessionalsfor SocialResponsibility,in press.
Elizabeth Dykstra Erichon, Jean McKendree, and Thea Muller, MJ. (1991a). No Mechanization without Represen-
Turner. We thank Ellen White and Daniel Wildman for tation: Who Participates in Participatory Design of Large
continuing collaborations on PICTIVE and on games for SoftwareProducts? In CH1'9I ConferenceProceedings.
participatory system design. New Orleans L A ACM, 391.
REFERENCES Muller,MJ. (1991b). PICTLVE-AnExplomtion in Partici-
Bjerknes, G., Ehn, P.,and Kyng,M. (Eds.) (1987). Computers patory Design. In CH1'91 Conference Proceedings. New
and Democracy: A ScandinavianChallenge. Broolrfeld, Orleans LA: ACM, 225-231.
V T Gower. Muller, MJ. (1992). Retrospectiveon a Year of Participatoq
Bodker, S., Ehn, P., Kammersgaard,J., Kyng, M., and Sund- Design using the PICTIVE Technique. In Proceedings of
blad, Y. (1987). A UTOPIAN Experience: On Design of CH1'92. Monterey CA: ACM, 455-462.
Powerful Computer-Based Tools for Skilled Graphic Muller, MJ., and Cebullra, K.D. (1990). Software Profes-
Workers. In G. Bjerknes, P. Ehn, and M. Kyng (Eds.), sionals in the Year u300: Technologies to Support an
Computers and Democracy: A Scandinavian Challenge. Enhanced SocialCommunicationsFabric. In Proceedings
Brookfield, VT: Gower. of the National Communications Forum, 44. Chicago:
Dayton, T. (1991). Cultivated Eclecticism as the Normative Professional Education International, 864-869.
Approach to Design. In J. Karat (Ed),Taking SofnSare Muller, MJ., Kuhn, S., and Meskill, J.A. (1992). PDC'92:
Design Seriously: Practical Techniques for Human- Proceedings of the Participatory Design Conference.
ComputerInteractionDesign. New York: AcademicPress, Cambridge MA: Computer Professionals for Social Re-
21-44. sponsibility.
Dyksm, E.A. (1991). PracticalRequirementsfor Participa- Namioka, A., and Schuler, D. (1990). PDC'90: Conference
tory Design. In CH1'91 Conference Proceedings. New on Participatory Design. Seattle W A Computer Profes-
Orleans LA: ACM, 390-391. sionals for Social Responsibility.
Dykstra,E.A., and Carasik, RP. (1991). Structure and Sup- Namioka, A., and Schuler, D. (1993). Participatory Design:
port in CooperativeEnvironments: The Amsterdam Con- Principles and Practices. HillsdaleNJ: Erlbaum.
versation Environment, International Journal of Man- Wildman,D.M.,White,E.A.,andMuller,MJ.(1993Games ).
Machine Studies 34(3), 419434. and Other Participatory Techniquesfor Group Design of
Ehn, P., and Kyng, M. (1987). The Collective Resource Systems. Tutorial at INTERCHI'93. Amsterdam, April
Approach to SystemsDesign. In Bjerknes, G., Ehn,P., and 1993.

299

Downloaded from pro.sagepub.com by guest on March 20, 2016

You might also like