21i n t e r a c t i o n s . . . m a r c h + a p r i l 1 9 9 8

methods& tools

AN DREW MONK AND STEVE HOW ARD

TThe Importance of Concerns

Have you ever observed the following situation? A computer system is built to satisfy well-specified

requirements. The requirements clearly describe the task to be supported, and the system

satisfies them. Despite all this care and attention, the system is universally condemned by

management and users. Why does this happen? Surprisingly often, the task supported is not one that

users actually perform. More likely, the model of work underlying the computer system interferes

with other tasks the user wants to perform.

The Rich Picture: A Tool forReasoning About Work Context

22 i n t e r a c t i o n s . . . m a r c h + a p r i l 1 9 9 8

Andrew Monk

Department of

Psychology

University of York

York, Y01 5DD

United Kingdom

AM1@york.ac.uk

Steve Howard

Swinburne CHI

Laboratory (SCHIL)

Swinburne University

of Technology

PO Box 218,

Hawthorn, 3122

Australia

SHoward@swin.edu.au

The really catastrophic side effects are thosethat prevent other people from doing theirwork. If the chief accountant can no longer getthe figures she needs, the system will never seethe light of day!

A new computer system will affect the waypeople work; if it does not there is no point inintroducing it in the first place. These effectswill be deleterious if the developers do notconsider the implications for both the system’susers and other people who may be affected byuse of the system. All work has numerous, andsometimes competing, objectives. A singleuser may have the objectives “to complete ajob well” and “to get home soon.”Management may have the objectives “to cutthe head count in this department” and to“minimize the transaction times for cus-tomers.” We call these objectives “concerns.”Concerns are the high-level objectives that sig-nificantly constrain the way work is done.Effective systems can be designed only by tak-ing into account the divergent concerns ofstakeholders. A designer may think she is tak-ing an “impersonal view of the problem,” butthe very act of identifying the problem impliesa particular viewpoint.

How is a designer therefore to reason aboutthese divergent concerns that motivate theway different stakeholders view the systemthey are designing? This paper discusses a sim-ple graphical device, called a rich picture, thathas been found to be useful in this respect. Arich picture is a cartoon-like representationthat identifies all the stakeholders, their con-cerns, and some of the structure underlyingthe work context. A rich picture is a tool forrecording and reasoning about these aspects ofthe work context, in particular, how theyshould affect the design. It is a tool in thesense that a notation or representation is atool. Rich pictures have been used as an ele-ment of various methods. The next sectionbriefly explains the origin of rich pictures inthe Soft Systems Methodology and how theylook. The sections thereafter sketch someexamples of how they may be used in HCI. Arich picture is a small but effective idea. It canbe incorporated into any design process.Perhaps it would be useful in yours.

Origins of Rich Pictures Rich pictures originated in the Soft SystemsMethodology (SSM) [4, 3, 18]. SSM, in turn,had its origins in sociotechnical approaches tosystem design [15]. Within this tradition,identifying multiple viewpoints of a work sit-uation is a recurrent problem. SSM was devel-oped during the 1960s and 1970s by PeterCheckland and his students at LancasterUniversity. At the core of SSM is a desire tounderstand human activity systems in a waythat is meaningful to the actors in that system.SSM consists of seven main stages that pro-ceed from articulating the problem situation,through building alternative systems models,to making recommendations for action.Checkland proposes the rich picture as a rep-resentation to be used at the beginning of thisprocess.

Rich pictures are generally constructed byinterviewing people. The ideal interviewshould take place at the workplace because theartifacts people use to do their work will beclose at hand. They will be able to show youdocuments and products, and you may evenbe able to observe them doing their work. Therich picture serves to organize and reasonabout all the information that users provide.Drawing the picture will point to places whereyou need to find out more or to apparent con-tradictions in the conclusions you have drawn.In the latter case you will need to go back toyour informants and then make changes basedon what they tell you. Drawing a rich picturethen is an iterative process of understandingand refining that understanding.

What does a rich picture look like? Therich picture depicts the primary stakeholders,their interrelationships, and their concerns. Itis intended to be a broad, high-grained viewof the problem situation. There is no singlebest way of producing a rich picture; the sameanalyst will use different styles under differentcircumstances. To illustrate this, Figures 1 and2 present rich pictures of contrasting styles.They depict a pub and a Web design compa-ny, respectively. Figure 1 is intended to cap-ture the viewpoints of✱ The brewery owning and supplying the

pub;

23i n t e r a c t i o n s . . . m a r c h + a p r i l 1 9 9 8

✱ The employees that work in it; ✱ The customers that frequent it; and ✱ Indirectly involved stakeholders such as

the community, the police, and otherpubs in the vicinity. Contrast this with Figure 2, which is

intended to capture the internal structure ofthe Web design company and viewpoints ofthe roles within it, as well as the viewpoints ofexternal bodies such as clients. Figure 1emphasizes the flow of goods and servicesfrom supplier to customer, whereas Figure 2emphasizes the flow of influence. So, forexample, the Professional Society of WebDesigners influences the company throughexpectations and standards. The directorinfluences the work of the analyst and thecoder through strategy documents, and so on.

The three most important components of arich picture are structure, process, and con-cerns. ✱ Structure refers to aspects of the work

context that are slow to change. Thesemight be things such as the organizationalhierarchy of a firm, geographic localities,physical equipment, and so on. Mostimportant, it includes all the people whowill use or could conceivably be affectedby the introduction of the new system. InFigure 1 the structure described is a brew-ery, owning a pub, having a landlord andcustomers, and situated in a community.In Figure 2 the structure includes theboundaries between the company and theworld in general and those of a given pro-ject within the company. The analysts

Figure 1 Rich Picture of a Pub

Am I earningenough?

The Landlord The Employee

The Community

The Customers

EnjoymentGoods

Competition

Profits

Cash

Value for MoneyQuality of Facilities

Image

Noise?Disturbance?Convenience?

Profit?

Capital InvestmentManagement

Goals

Closing time?Drunk driving?

The Brewery

The Police

Other Pubs

The Pub

���������������yyzzz{{{{||||||����������yyyzz{{{||

Based on Patching, 1995

24 i n t e r a c t i o n s . . . m a r c h + a p r i l 1 9 9 8

drawing the rich picture are included inthis structure to remind themselves thatthey too have a separate viewpoint, con-cerns, and possible bias.

✱ Process refers to the transformations thatoccur in the process of the work. Thesetransformations might be part of a flow ofgoods, documents, or data. In Figure 1 theprocesses depicted are transformations ofgoods, money, and enjoyment. In Figure 2the emphasis is more on the process bywhich different roles influence one another.

✱ Concerns is the most useful component,for the purposes of this paper. Checklandcalls them “issues.” We prefer the word“concern” because it captures more clearlythe idea of a particular individual’s moti-vation for using the system. These differ-ent motivations give rise to the differentperspectives each person has. Each of thepeople captured in the rich picture willhave concerns. A manager might have aconcern arising from the pressure being

put on her to reduce the number of staffin her department. Someone in thatdepartment may have a concern that hisjob may be de-skilled or that he may belaid off. The thought bubbles coding con-cerns in Figure 1 make it clear that thebrewery, the employees of the pub, andthe customers each have very differentperspectives on what the pub is for. Finally, tensions between stakeholders can

be highlighted. The “crossed swords” iconserves this purpose. In Figure 1 the pub isshown to be in tension with other pubs, pre-sumably through their competition for a lim-ited pool of customers. Identifying tensionswith crossed swords is a useful preliminarystep to precisely identifying the conflictingconcerns and how they may be resolved.

Table 1 lists some of the features that makefor an effective rich picture. The first threeserve to prevent the rich picture from becom-ing overloaded with detail. The advantage ofhaving a rich picture that is comprehensible tothe people who have given you the informa-tion (Item 4 in Table 1) is that you can take itback to them for review. In this way you canelicit new information and correct mistakes ofinterpretation. The discipline of using the lan-guage of the work context may also help pre-vent the inclusion of structure, process, andconcerns that are not real but that the analystthinks should be there. The last point in Table1 is that work context analysis requires imagi-nation and creativity, just like design itself.Examining the examples given here and in thereferences should provide plenty of ideas forpotential users of this technique.

The remainder of this article illustrates therole that rich pictures can play in two relatedcontexts: participatory design and lightweightusability engineering.

Uses of Rich PicturesRich Pictures in Participatory DesignDrawing a rich picture requires that the analystwork closely with the stakeholders so that thepictures capture the situation and related con-cerns from the stakeholders’ points of view.Stakeholders participate in the process byworking with the analyst to identify structures,

Table 1. Elements of an Effective Rich Picture

Element Comment1. Include structure Include only enough structure to allow

you to record the process and con-cerns. The latter requires that all the people who will use or could con-ceivably be affected by the introduc-tion of the new system be included.

2. Include process Do not attempt to record all the intri-cacies of process; a broad brush approach is usually all that is needed

3. Include concerns Caricature the concern in a thought bubble (see Figures 1–3 for exam-ples). A fuller explanation may be provided in a supplementary docu-ment

4. Use the language of This will make the rich picture com-the people depicted in it prehensible to your informants

5. Use any pictorial or textual There is no correct way of drawing a device that suits your purpose rich picture. There are as many styles

as analysts and the same analyst will find different styles useful in differ-ent situations

25i n t e r a c t i o n s . . . m a r c h + a p r i l 1 9 9 8

processes, and concerns significant to them.SSM’s focus on the stakeholders’ viewpointshares much with various participatory designmethods [e.g., 7]. There is, however, an impor-tant difference between participatory designand SSM: the role of the user in the designprocess. In participatory design the user takesan active role in the analysis and designprocess; in SSM this is often not the case.

Rich pictures can be used to record, reasonabout, communicate, and negotiate signifi-cant issues as they arise during or after partic-ipatory design. Essentially the role of the richpicture is to make explicit the stakeholders,their interrelationships, and their concerns.Interestingly, this can be done at two levels. Arich picture of the work context can be drawn

that identifies the stakeholders and the worksetting. Figures 1–3 are examples of this typeof rich picture. | Additionally, a rich picture ofthe participatory design team itself can beused to identify the necessary managers,hands-on users, beneficial users, analysts,designers, and other participants. This type ofrich picture can be useful in “designingdesign,” in composing the stakeholder meet-ings, and in reasoning about design processes.Comparing the work-context rich picturewith the design-context rich picture provides away of checking whether there is appropriatestakeholder representation on the designteam. Consider the use of rich pictures withthe following techniques seen frequently inapproaches to participatory design.

Figure 2 Rich Picture of Web Design Consultancy

FISHY WEB INC.

Profit?Long term reputation?

Director

AdministrationMarket Research

Web Analyst

HTML Coder

StrategyDocuments

Need moretime

CompetitorCompanies

CurrentClients

ResourcesData

Work

ProblemsSolutions

Analysts

I don’t haveenough time

to talk to the user

Concepts

If only I hadmore powerful

tools

PotentialClients

Focus?Bias?

Marketing

ExpectationsStandards

Professional Societyof Web Designer

Good jobdone dirt cheap

Marketing

Fishy Web Inc.

Project Team

i n t e r a c t i o n s . . . m a r c h + a p r i l 1 9 9 8

✱ Brainstorming: Brainstorming is oftenused to generate ideas about the problemsand potential solutions of the work situa-tion. Because rich pictures can be drawn“on the fly” during a brainstorming ses-sion, ideas can be captured without undulydisrupting or constraining a necessarily cre-ative, unstructured process. Rich pictureshere present an alternative to the multitudeof sketches and doodles that participantsoften walk away with from brainstormingsessions. A rich picture helps everyoneinvolved in its construction to take a con-sistent view of the problem situation with-out demanding that they all agree on whatthe problem is. Multiple conflicting con-cerns can be captured in the pictures asshown in Figures 1–3.

✱ Storyboarding: Storyboarding is oftenused to describe the flow of, for example,the users’ activities so that they can bereviewed and evaluated by both designersand users. Rich pictures can provide anelegant adjunct to a connected series ofstoryboards by representing, in a singleabstract summary, the major structuresand flows, at an organizational level, rele-vant to a work situation. Rich pictureshere present a supplement to the flowcharts and procedural descriptions oftenused to connect the separate episodes of astory.

✱ Paper-Based Prototyping: Many partici-patory design techniques use paper-based

mock-ups and prototypes to repre-sent design ideas early in the

development process [e.g.,14]. Such techniques pro-vide a way for stakehold-ers to comment on thedetails of the design andthe extent to which itmeets the user’s charac-teristics and needs. Incapturing the primary

concerns of the usersand, potentially, the major informationflows likely to affect the system, the richpicture places the emerging design in itsoverall social and technical context.

Using a rich picture does not, in itself, solveany of the delicate problems encountered inparticipatory design: how to deal with privateor confidential concerns, how to bring togeth-er different constituencies that have very dif-ferent ways of describing the work context, orhow to deal with minorities within a con-stituency. However, constructing a rich pic-ture with the help of the relevant stakeholderswill make the concerns apparent, and identi-fying a problem is an important first step insolving it.

Rich Pictures in Lightweight Usability MethodsWhen people think of user interface designthey usually think of large, high-profile pro-jects, such as word processors or military com-mand and control systems. The majority ofuser interface design projects are in fact verysmall: perhaps, for example, someone hasrequested a Windows 95 interface for somesmall part of the company database. Anotherexample is the design of a Web page. The oneor two developers given the task probably donot even consider themselves user interfacedesigners; yet cumulatively these small pro-jects significantly affect the productivity of anorganization.

On a large project one can afford to recruitor train developers in specialized techniques;indeed, an elaborate, well-specified designmethodology may be necessary just to managethe large number of personnel involved [11].On a small project the techniques used mustbe “lightweight,” that is, the costs to the orga-nization must be minimal. Nielsen [16] hasdubbed these techniques “discount.” Theymay only achieve 90 percent of what is possi-ble with more elaborate methods, but they doso for very much less than 90 percent of thecost. Costs here are measured in training andin the time it takes to apply the technique;therefore, lightweight techniques have to beeasy to learn and quick to apply. If a project isassigned only 4 person-weeks of effort, a tech-nique for improving some aspect of the quali-ty of a user interface is unlikely to justify morethan 1 day of training and 2 or 3 days of appli-cation. Examples of lightweight techniques

P

27i n t e r a c t i o n s . . . m a r c h + a p r i l 1 9 9 8

include Monk et al.’s simplified user testingprocedure Cooperative Evaluation [13] andNielsen’s simplified usability inspection tech-nique, Heuristic Evaluation [17]. With thesetechniques, prototypes and scenarios are cru-cial parts of communication between designerand user. Without these concrete representa-tions of the design, little communication canoccur. With them, however, both user and

designer can develop common ground byfocusing on actions and tasks. A rich picturecan serve a similar communicative functionmuch earlier in design when one is thinkingabout the general work context and the con-straints this imposes.

Monk [12] describes how a rich picture canbe used as the first step in a lightweight designprocess, to reason about the redesign of the

Figure 3. Rich Picture of aCold Storage Warehouse

28 i n t e r a c t i o n s . . . m a r c h + a p r i l 1 9 9 8

work context that will be required. He sug-gests that “before” and ”after” rich pictures bedeveloped. The former records critical aspectsof the work context as it now exists, and the

latter illustrates how the contextwill change when the new sys-

tem is introduced. The beforepicture can be presented to

one’s informants to checkthat the analysis does not

misconstrue oromit crucial fac-tors. If more thanone developer is

working on the project,the before picture can also be invaluable incommunication between developers and get-ting everyone to think on the same wave-length. As the prototype design is developedan after picture will emerge. The after picturecan be presented to management to alert themto the implications of the new computer sys-tem. If they are unhappy it is still early enoughfor changes to be made. If they accept thedesign then they can make appropriate adjust-ments, change reporting structures, organizeretraining, and so on.

The procedure suggested by Monk firstinvolves talking to stakeholders about theirjobs. A rich picture can be a useful way fordevelopers who are not used to this sort ofwork to focus their thoughts. Normally a des-ignated contact in the user organization willbe interviewed first. The people who will endup actually using the system should also beinterviewed. It is then a matter of judgmenthow many of the additional stakeholders iden-tified by these initial informants one alsoneeds to talk to. It is always a good idea tointerview people in their workplace, wherethey can show you documents, screens, and soon. A portable tape recorder may be useful tocheck what was said, and you should alwayshave a prepared list of topics or interviewschedule so that you cover all the criticalpoints. Clegg et al. [5] give useful and practi-cal advice on how to get the best out of yourinformants.

When drawing a rich picture for this pur-pose, you normally start by sketching in the

middle of a large sheet of paper some figurewho represents the primary user or operator.Monk’s lightweight technique is to encourageuser centered-design and to avoid the naturaltendency for developers to take a system-ori-ented view. Putting the operator at the centerof the picture makes her the focus of atten-tion. Next, the stakeholders that directlyinfluence the operator’s work can be picturedalong with the elements of structure needed toexplain the process of work. Monk illustrateshis methods with a real example of design fora cold storage warehouse; the rich picturedeveloped in this process is shown in Figure 3.The operator is given a fictitious name, Jenny.Jenny’s job involves taking delivery notes fromthe drivers of vehicles bringing goods into thewarehouse (depicted as stick figures wearingcaps). Jenny enters the data from the deliverynote into a computer system to provide tallylists for the deliveries to be checked by thewarehouse men (signified by stick figureswearing black hats). The roles described thusfar then are the core stakeholders in theprocess of getting the work done. The richpicture also identifies other clerks and a super-visor. Finally, the most peripheral stakeholdersare drawn in. In Figure 3 they appear at thetop edge of the picture. They are the directorsand computer systems people of the two orga-nizations taking part of this operation—theowners of the cold store and the owners of thestores supplied.

When the major structures and processeshave been added, the concerns can beaddressed. The thought bubble for Jenny inFigure 3 codes the wide variations in workloadshe has to put up with. Other concernsincluded are the need for the drivers to getaway as soon as possible, worries about jobsecurity, and so on. Thought bubbles may besomewhat cryptic to someone who was notinvolved in generating a rich picture, so Monksuggests that an additional sheet be addedexplaining in slightly more detail the concernsof each stakeholder. The same sheet mayexplain the process and specific responsibili-ties not coded on the picture.

One of the important reasons for drawinga rich picture is to clarify one’s thoughts. For

29i n t e r a c t i o n s . . . m a r c h + a p r i l 1 9 9 8

this reason one should not be afraid to throwaway an early version and start again. Richpictures can also be presented to informants(although you may need different versions fordifferent informants) to make amendments orradical revision. The rich picture is only thefirst step in Monk’s lightweight method. Thenext is to identify work objectives and userexceptions, which are then used to developscenarios that can be used to refine early pro-totype designs and to make sure that thedesign supports all relevant aspects of thework. The rich picture serves as a startingpoint and a context for all these activities.Readers wishing to know more about thisprocess should consult Monk [12].

Monk’s lightweight method is a relativelyinformal technique; that is, it is not preciselyspecified. This has the advantage of making itrelatively easy to learn and apply. The disad-vantage is that different people will apply it indifferent ways. This is not a problem when thedesign team is small and coordination isstraightforward. However, when design teamsget larger a much more precisely specifiedmethod is needed, just so that everyone knowswhat everyone else is doing [11]. Examples ofmore tightly specified procedures that makeuse of rich pictures are✱ TheoryBuilder [10, 19]; ✱ Howard and Smith’s [8] use of rich pic-

tures with Johnson’s [9] KnowledgeAnalysis of Tasks; and

✱ Multiview [2].

Some Final CommentsOne recurring theme in this review has beenthe value of using more than one techniquewhen analyzing a work context. We are notsuggesting that using a rich picture will solveall your problems. It is just one of many smallbut useful ideas that may be applied to anydesign problem. The value of using a widevariety of techniques is eloquently discussedby Dearden and Wright [6]. They report on acase study that borrowed from a number ofmethodological traditions to analyze a workcontext. According to this approach an SSM-style rich picture is just one of the techniquesused. Dearden and Wright also used contextu-

al interviews, “train me” sessions, work log-ging, semistructured interviews, scenarioanalysis, model building, wish lists, andassumption challenging. They argue that nosingle technique is capable of capturing fullthe diversity of the work setting.

Dearden and Wright draw an interestingdistinction between techniques that are situat-ed in the work context and those that gobeyond the immediate situation. The formertechniques can be used only in the work place.The latter allow the analyst and the user todetect issues beyond the range of the observ-able situation, for example, the organizationaland historical contexts. Dearden and Wrightassert that different techniques have differentstrengths and weaknesses. Observation allowsone to separate what people say they do fromwhat they really do, but it has practical limita-tions. With only a limited amount of time inthe workplace it may be impossible to see thefull process. Infrequent, but nonethelessimportant, problems may not crop up whileyou are actually there. Only by using a varietyof situated and nonsituated techniques canthe fullest account emerge, given the prevail-ing practical constraints. The rich picture canserve as a representation to motivate all thesedifferent sources of information about thework. It can also serve as a representation tointegrate information regarding the higherlevel work context coming fromthe sources.

The versatility of the richpicture arises from its sim-plicity. We suspect thatmany readers willalready have seen ways ofincorporating rich pic-tures into their own meth-ods and we would encouragethem to do so. The foregoingexamples of good practiceshould allow you to do thiseffectively. Perhaps one daythe rich picture will be as familiara diagram to see at a design meeting as thenow ubiquitous data flow diagrams and flowcharts. When that day arrives we will havemoved much further toward removing our

METHODS & TOOLS

COLUMN EDITORS

Michael Muller

Microsoft Corporation

One Microsoft Way

Redmond, WA 98052

mullerm@acm.org

Finn Kensing

Department of

Computer Science

Roskilde University

Building 20.2

P.O. Box 260

DK 4000 Roskilde

Denmark

+45-4674-2548

Fax: +45-4674-3072

kensing@ruc.dk

30 i n t e r a c t i o n s . . . m a r c h + a p r i l 1 9 9 8

PERMISSION TO MAKE DIGITAL/ HARD

COPY OF PART OR ALL OF THIS WORK

FOR PERSONAL OR CLASSROOM USE IS

GRANTED WITHOUT FEE PROVIDED

THAT COPIES ARE NOT MADE OR

DISTRIBUTED FOR PROFIT OR COM-

MERCIAL ADVANTAGE, THE COPYRIGHT

NOTICE, THE TITLE OF THE PUBLICA-

TION AND ITS DATE APPEAR, AND

NOTICE IS GIVEN THAT COPYING IS BY

PERMISSION OF ACM, INC. TO COPY

OTHERWISE, TO REPUBLISH, TO POST

ON SERVERS, OR TO REDISTRIBUTE TO

LISTS REQUIRES PRIOR SPECIFIC PERMIS-

SION AND/OR A FEE.

© ACM 1072-5220/98/0300 $3.50

blinders and making a genuine attempt to seethe other person’s point of view. System designcan only benefit from such a change.

AcknowledgmentsDr. Monk was supported by the ESRCCognitive Engineering Program. Dr. Howardwas supported by a grant from SwinburneUniversity of Technology, Australia. Wewould like to thank the editors of this sectionfor valuable comments on an earlier manu-script.

References 1. Avison, D. and Fitzgerald, G. Information Systems

Development: Methodologies, Techniques and

Tools. Blackwell Scientific Publishers, Oxford,

1988.

2. Avison, D. and Wood-

Harper, T. Multiview

Methodology. Blackwell

Scientific Publishers,

Oxford, 1990.

3. Checkland, P. Systems

Thinking, Systems Practice. John

Wiley and Sons, Chichester, 1981.

4. Checkland, P. and Scholes, J. Soft

Systems Methodology in Action. John Wiley and Sons,

Chichester, 1990.

5. Clegg, C., Warr, P., Green, T., Monk, A., Kemp, N.,

Allison, G., and Lansdale, M. People and Computers:

How to Evaluate Your Company’s New Technology. Ellis

Horwood, Chichester, UK, 1988.

6. Dearden, A. and Wright, P. Experiences Using

Situated and Non-situated Techniques for Studying

Work in Context. In S. Howard, J. Hammond, and G.

Lindgaard, eds., Human Computer Interaction—INTER-

ACT’97. Chapman and Hall, London, 1997.

7. Greenbaum, J. and Kyng, M. Design at Work:

Cooperative Design of Computer Systems. Lawrence

Erlbaum Associates, Hillsdale, NJ, 1991.

8. Howard, S. and Smith, R. Using the Soft Systems

Methodology to Front-end Task Analysis. In HCI: A

Light Into the Future, Proceedings of OZCHI’95

(Wollongong, Australia, November 1995), pp. 88–94.

9. Johnson, P. Human Computer Interaction: Psychology,

Tasks Analysis and Software Engineering. McGraw-Hill,

London, 1992.

10. Khushalani, A., Smith, R., and Howard, S. What

happens when designers don’t play by the rules: towards

a model of opportunistic behaviour in design.

Australian Journal of Information Systems 1, 2 (1994),

pp. 13–31.

11. Kraut, R. E., and Streeter, L. A. Coordination in

software development. Communications of the ACM 38,

3 (1995), pp. 69–81.

12. Monk, A. F. Lightweight techniques to encourage

innovative user interface design. In L. Wood & R.

Zeno, eds., Bridging the Gap: Transforming User

Requirements into User Interface Design. CRC Press,

Boca Raton, 1997.

13. Monk, A. F., Wright, P., Haber, J.,

and Davenport, L. Improving

your human-computer

interface: a practical tech-

nique. BCS Practitioner

Series. Prentice-Hall,

Hemel Hempstead, 1993.

14. Muller, M. J. PICTIVE—An exploration in partici-

patory design. In S. P. Robertson, G. M. Olson, and J.

S. Olson, eds., CHI’91 Human Factors in Computer

Systems (New Orleans, 1991). ACM, New York, pp.

225–231.

15. Mumford, E. Sociotechnical system design: evolving

theory and practice. In G. Bjernes, P. Ehn, and M.

Kyng, eds., Computers and Democracy: A Scandinavian

Challenge. Avebury, Aldershot, UK, 1987.

16. Nielsen, J. Usability Engineering at a Discount. In

G. Salvendy and M. J. Smith, eds., Proceedings of the

Third International Conference on Human-Computer

Interaction, HCI-International ‘89, Boston, September,

Elsevier Science, 1989, pp. 394–401.

17. Nielsen, J. and Mohlich, R. Heuristic evaluation of

user interfaces. In J. C. Chew and J. Whiteside, eds.,

Human Factors in Computer Systems, CHI’90. CHI ’90,

Seattle, April, ACM, New York, 1990, pp. 249–256.

18. Patching, D. Practical Soft Systems Analysis. London,

Pitman Publishing, 1990.

19. Smith, R., Howard, S., Sutherland, T., and

Khushalani, A. TheoryBuilder: A Behavioural Perspective

on Modelling and Improving Systems Development.

Proceedings of First Australian Seminar on Modelling and

Improving Systems Development. School of Information

Technology, Swinburne University, 1994.