Rationale for user oriented design technique selection

Rochester Institute of Technology

RIT Scholar Works

Theses

Thesis/Dissertation Collections

2004

Rationale for user oriented design technique

selection

Susan M. Saeger

Follow this and additional works at:

http://scholarworks.rit.edu/theses

This Thesis is brought to you for free and open access by the Thesis/Dissertation Collections at RIT Scholar Works. It has been accepted for inclusion in Theses by an authorized administrator of RIT Scholar Works. For more information, please [email protected].

Recommended Citation

Rationale

for

UserOrientedDesign Technique Selection

By

Susan M. Saeger

Thesissubmittedinpartialfulfillmentofthe requirementsforthe degreeofMasterofScience in Information

Technology

Rochester Instituteof

Technology

B. Thomas Golisano College

of

Student Name:

Project Title:

Name

Rochester Institute of Technology

B. Thomas Golisano College

of

Computing and Information Sciences

Master of Science in Information Technology

Thesis Approval Form

Susan M. Saeger

Rationale

for

User Oriented Design Technique Selection

Thesis Committee

Signature

Date

=..!Ev~el..J-!.'yn~R~oz=an~ski~· p~hD=---_E_v_e_l~y_n_R_o_z_a_n_s_k_i _---=-.j_-:~d

g

---0

y

Chair

Anne Haake PhD

Committee Member

Deborah Coleman

Committee Member

Anne Haake

Thesis Reproduction Permission Form

Rochester Institute of Technology

B. Thomas Golisano College

of

Computing and Information Sciences

Master of Science in Information Technology

Rationale

for

User Oriented Design Technique Selection

I, Susan Saeger, hereby grant permission to the Wallace Library of the

Rochester Institute of Technology to reproduce my thesis in whole or in part.

Any reproduction must not be for commercial use or profit.

Acknowledgments

I wouldliketoextendedathankyouto_my wonderfulparents, TheresaandJoe

Wanchissen,

whohave alwaysencouraged meto "pushthepencil

harder"

Also,

thank

youto

brothers,

JoeandSteve for

listening

at_every

family

eventabout_myeducational status.

Iwouldalsoliketo thankEdandJackie Saegernot_{only for}

believing

in me,but for allowing metovisitthemwhenIneededtorecharge and reestablish_myperspective.

I am gratefulforall of_{my friends}and_{my husband's friends} whohave become

myfriends. You have allbeenso _{understanding}of_myschedule when school hadto

come first. Atthesametime youallknewwhenIneededto takeabreakandlivealittle. Youarethepeople whohelpedto

keep

mebalanced. You are all alittleresponsiblefor

theinitial ideaofthispaperbecause itcrystallizedasJeffandIwere

training

forthehalf marathon you all organizedin 2003.

My

co-workers and managers alsodeserveathankyoufor

listening

and

encouragingme not_only

during

thecreation ofthispaper,but forthepast6 years. Allof you who have beenthere fromthestartknowthechallengesIfacedand your supporthas been greatlyappreciated.

Thankyoutoall of_myprofessorswhohavecontributedto_myeducational experience. Mostof allIwouldliketo thank_mycommittee members and_especially Evelyn Rozanski PhD. Shewastheperson who established and_{fostered my}excitement aboutthe topicofthis paper. She isnot_only a wonderful_professor,but also a mentor and afriend. Iam_goingto miss our

bi-monthly

meetingsthatincludedtopicsfar beyond whatis presentedinthis paper.

Mostof_all, a_veryspecial thankyou goes to_{my husband}whohas beentherefor methroughitallfromthe_{very beginning. Thank} youforalways

believing

inme and

helping

to

keep

_{my life appropriately balanced. Thank} youfor

knowing

whenIneededto

TableofContents

1. Introduction 9

2. Statementoftheproblem 12

3. Hypothesis 13

4. Definitions 13

5. Background 14

6.

Participatory

Design

(PD)

15

6.1

History

15

6.2 Definition 16

6.3 Techniqueand process_summary 17

6.4 Projectteam type 20

6.5 Application domain 20

6.6 Integration

feasibility

21

6.7 Advantages 21

6.8 Expectations 22

7. Scenario-Based Design

(SBD)

23

7.1

History

23

7.2 Definition 24

7.3 Techniqueandprocess _summary 24

7.4 Projectteamtype 26

7.5 Application domain 26

7.6 Integration

feasibility

26

7.7 Advantages 26

7.8 Expectations 26

8. Contextual Design

(CD)

₂₆

8.1

History

₂₆

8.2 Definition ₂₆

8.3 Techniqueandprocess_{summary 26}

8.4 Projectteam type ₂₆

8.5 Application domain 26

8.6 Integration

feasibility

26

8.8 Expectations 26

9. UserCentered Design

(UCD)

26

9.1

History

26

9.2 Definition 26

9.3 Techniques and process_summary 26

9.4 Projectteam type 26

9.5 Application domain 26

9.6 Integration

feasibility

26

9.7 Advantages 26

9.8 Expectations 26

10. Performance Centered Design

(PCD)

26

10.1

History

26

10.2 Definition 26

10.3 Technique and process _summary 26

10.4 Projectteam type 26

10.5 Applicationdomain 26

10.6 Integration

feasibility

26

10.7 Advantages 26

10.8 Expectations 26

11.

Learning

Centered Design

(LCD)

26

11.1

History

₂₆

11.2 Definition ₂₆

11.3 Techniqueandprocess _{summary 26}

11.4 Projectteamtype 26

11.5 Application domain 26

11.6 Integration

feasibility

₂₆

11.7 Advantages ₂₆

11.8 Expectations ₂₆

12.

Usability

Engineering

(UE)

26

12.1

History

₂₆

12.2 Definition 26

12.3 Technique andprocess _summary 26

12.5 Application domain 26

12.6 Integration

feasibility

26

12.7 Advantages 26

12.8 Expectations 26

13. Fictional Case

Study

Purpose 26

13.1 Formulation ofProblem Statement 26

13.2 Background Scenario 26

13.3 Criteria fortechnique selection 26

13.4 AnalysisoftheCCTA Project 26

13.5 CCTA Project Goal andScope 26

13.6 CCTA Project Timeline 26

13.7 CCTA Project Team SizeandExperience 26

13.8 CCTA Project Team Type 26

13.9 CCTA Project Team Location 26

13.10 CCTA Project Team Dynamics and organizational culture 26

13.11 User Oriented Design approach recommendation 26

13.12

Participatory

Design

(PD)

elimination explanation 26 13.13 Scenario Based Design

(SBD)

elimination explanation 26

13.14 Performance Centered Design

(PCD)

elimination explanation 26 13.15

Learning

Centered Design

(LCD)

eliminationexplanation 26 13.16 User Oriented Design

(UOD)

techniquerecommendation analysis 26

13.17 Analysistechniquesincluded 26

13.18 Analysistechniquesexcluded 26

13.19 Designtechniquesincluded 26

13.20 Designtechniquesexcluded ₂₆

13.21

Testing

techniquesincluded 26

13.22

Testing

techniquesexcluded 26

13.23 Additional deliverables 26

13.24 Expectedproject outcome 26

13.25 Otherconsiderationsthat were outsidethescope ofthis case _study 26

14. Conclusion 26

15. AppendixA

-Methodcomparison

by

technique 26

1. Introduction

Intoday'scompetitive_environment,companies cannot affordtoproduce unusable products. This is _particularlytrueforcompaniesthatproduce software, astheirsole revenue generator. Consumers choose software productsthatmaketasks easier. This meansthat_usability and usefulness of a software product are nolongerrequirementsthat

are "nicetohave", butmustbecore requirements of software applications.

Achieving

theserequirements is a complextask thatrequiresintense analysis and commitmentfrom several areas of an organization. Partofthereasonthis taskis sodifficult is becauseof thewide range of perspectivesthatinfluencethe creation ofsoftware products.

Typically,

the creation of a productinvolvesstakeholdersfrom all areas of an

organizationincluding:

Marketing,

Software

Engineers,

Hardware

Engineers,

Quality

Assurance

Specialists,

Implementation

Specialists,

Project

Management,

andDirectors. Whenpeople with differentperspectives cometogethertomove aproductfroma concept toreality, it is inevitable thatall parties must compromisetoachieve success. Thefirst step toachieving success istounderstandtheoverall organizational goals; thesecond step is understanding theconsumer or end user oftheproduct.

As achieving aclear organizational goal isnotthefocus

here,

theassumptionis that theorganization _{already has}a_{clearly identified} goal.

Rather,

thefocusis to understandhowtoselectthe appropriateuserorienteddesignmethodand techniques to

achievetheorganization's strategic objective andthespecific project's goals.

Userorienteddesign methods are_{multidisciplinary because}

they

considerthe

psychology, ergonomics, sociology, engineering, and visualdesign factors affecting productcreation. Auserorienteddesignperspectivefocuseson theend user andthe

interaction betweenend user and product. Thegoal of userorienteddesignmethods isto

add value

by incorporating

thehuman aspectinto productdesign. Becauseofthis human

nature_perspective, userorienteddesign methodscanbeappliedto_{many different}types

of products and systems.

varietyof reasons. Thequestions

they

askedincluded:

"Which user-centered design

(UCD)

methods are most _widely used andwhy?

What are the benefits and weaknesses of each method in the

eyes ofpractitioners?

What are the organizational impacts of UCD and what measures are in place to assess

progress?"

(Vredenburg, Mao,

Smith,

Carvey

2002p.

471)

(Note: theuse _ofthe termuser-centereddesign

by

theauthorsisequivalentto the termuser orienteddesignmethodsthatare referredto inthis_paper.)

This studyrevealedthatUCD isnot well-establishedintheindustry.

Recently

Rosenbaumcompleted another study.

"Rosenbaum et al.

(2000)

surveyed 134 CHI professionals with a

focus on the contribution of organizational approaches and UCD methodsto strategic usability. It wasfoundthatmajor obstaclesto creating greater strategic impact include resource _constraints, which was mentioned

by

28.6% oftherespondents. Resistance to user-centered design or usability, lack of knowledge about

usability were also stated as obstacles.

However,

_partnering with

marketing was identified as a _very effective

approach"

(Vredenburg, Mao, Smith,

Carvey

2002p.

472)

to UCD.

Hudsonconducted an e-mail _{survey in 2000} and 102 usabilitypractitioners

revealedthat the most_commonlyusedtechniques are: informal usability testing,user analysis,user_{profiling, evaluating existingsystems,}

low-fidelity

_prototyping, heuristic

evaluation, task

identification,

navigation

design,

and scenario-baseddesign

(Vredenburg, Mao, Smith,

Carvey

2002). Asimilar 10-questionweb survey,conducted

in 2001

by

Gunther, Janis,

andButlerthat_{involved 100 usability}practitionersfoundthat 39%oftherespondentsbelieved usability

testing

tobethemostaccurate_{in gauging} success

(Vredenburg,

Mao, Smith,

Carvey

2002). Thestatisticsindicate thattheselection andimplementation ofthe appropriateuser orienteddesignmethodis not simple andthat

thereis a_{gap in knowledge}about user orienteddesignmethods.

results

(Vredenburg, Mao, Smith,

Carvey

2002). Theresultsfoundthat32%of

respondents were notsureif UCDmethodshad helpedsave product developmentcosts;

only 24%believedthatUCDmethods_actually saved productdevelopmentcosts _and; 44% thoughtthatUCD increasedtheproductdevelopmentcost. Similarresults were

foundwhenrespondentswere asked abouttheproductdevelopment time.

Vredenburg,

Mao, Smith,

and

Carey

arguethat theresults areinconclusive becausetherespondents maynothavelooked atthe

"big

picture

including

service cost and

redesign"

(Vredenburg, Mao,

Smith,

Carvey

2002p. 474).

Nevertheless,

the

Vredenburg, Mao,

Smith,

and

Carey

_studywasconsistent withHundson's informale-mail_surveytakenin 2000. Both studiesindicatethat_{usability testing,}prototyping, andheuristicevaluations arethemost_widelyusedlowcost methods.

Vredenburg, Mao,

Smith

Carey

concludedthat:

"UCD method adoption is quite uneven across different organizations.

UCD staff _{in many organizations,} 41% of

[the]

_sample, is centralized, and_{only 15%} oftheorganizations_{have completely} decentralized UCDstaff.

The average _spending on UCD constitutes about 19% of the total projectbudget.

There is a lack of measurement ofUCD effectiveness and _any common evaluation criteria acrosstheindustry.

A multidisciplinary approach to UCD appears to _{be closely} related to perceived UCD _{effectiveness,} although practitioners were not always clear about what constitutedmultidisciplinary. UCD was perceived to have higher impact when there were two or more UCD specialists on the project team compared with_onlyone.

Cost-benefittradeoffs_play a major rolein theadoptionofUCD

methods"

(Vredenburg., Mao,

Smith,

Carvey

2002p. 477-78).

Productively implementing

userorienteddesignmethods requires awarenessof theorganizational structure.

Vredenburg, Mao, Smith,

and

Carey

suggestedthatthe organizations usedinthe studies _maynot_{have properly} alignedits staff

(Vredenburg,

Mao, Smith,

Carvey

2002). "Respondentswere askedtocharacterize theorganization of UCDstaff. In 41%of_{the companies,}UCDstaff were centralizedinan organizational unit, 15%

decentralized,

34% mixed,and 10% unclear"

Carvey

p.474).

Understanding

themethodsandtechniquesprovidesinsightabouthow to _{appropriately}align staffmembers.

Theinformationprovidedinthispaperwillbegin toclosethe_{gap in}the

understandingofthe_varietyof methods andtheirtechniques thatprovide anorganization

thetools to movetowardsa user-centric designapproach. The intent istoprovide a

comprehensive comparison of user orienteddesignmethods,and guidelines formethod

andtechnique selections. Itprovidesthe_{reasoning behind}the selection oftechniques ratherthan randommethod selection. The focusofthis paper willbeon _selectinga user

orienteddesignmethodforsoftware applicationdevelopment.

By

_providingacentral

location fortheinformationrequired when_selecting user orienteddesignmethods and

techniques,thispaper will closethe_gapthat_currentlyexistsItheuser orienteddesign industry.

2. Statementoftheproblem

Userorienteddesign's broadnaturehasprovidedthe_{opportunity for}practitioners tocombinetechniquesin a uniquefashion

thereby

_creating several _similar, yetdifferent approachestouser-centric software productdevelopment. As practitionershave

successfullycombinedtechniques thathavecreatedperceived successful software application

design,

thepractitionershaveclassifiedtheselectedtechniques with methodologynames. Thepractitionersthathavemoved_{into consulting}roles align themselveswith themethodthatcreatedtheirinitialsuccess andthen specializeinthat method. Thepervasive userorienteddesignmethodsthatconsultantshavealigned

themselves withincludethefollowing:

Participatory

Design

(PD)

Scenario Based Design

(SBD)

Contextual Design

(CD)

User Centered Design

(UCD)

Performance Centered Design

(PCD)

Learning

Centered Design

(LCD)

Usability

Engineering

(UE)

Sinceconsultants alignthemselveswith a method it isproblematic foran

sustainingprocess towardsuser-orienteddesign inthe organization.

Speculationcanbemadethat the selection ofauserorienteddesignapproach

within anorganization happensinconjunction with an immediateneed of ahighprofile project. Furtherspeculation canbemadethatfororganizations newto a user oriented

designapproach looktoconsultantsforsupport. Anotherassumptionisthattheinitial

selectionof a user orienteddesign method_{only includes}a review oftheprominent consultantandthemethods

they

offer. Thistypeof selection_mayresolvetheimmediate

understandingoftheprojectobjectives,but maynot resultin a_sustaininguseroriented

design approach.

3. Hypothesis

If knowledge about proper user orienteddesigntechniqueselectionis availablethen an organizationwillbeempoweredtocustomizea user orienteddesign approachfor successful integration into itsunique softwaredevelopmentproject requirements

resulting in a sustainable user orienteddesign approach. Asustainable user oriented

design approach willhavea positive strategic effectfortheorganization.

Theresultofthe analysis containedinthispaperis a set ofguidelines for

selectinga user orienteddesign technique. A fictionalcase_{study is} usedtoillustrate the application ofthe guidelines. Included inthecase _{study is}an analysis ofthemethods and their_{techniques; whereby, the}techniqueshave been

logically

grouped

by

the threemajor stages of a software application projectthosebeing: requirements,

design,

andtesting. In

addition, thedeliverablesprovide

by

each method arediscussed. 4. Definitions

Project_types, cross-functional_teams, andtraditional software developmentareterms

usedthroughout thisdiscussionthatrequires adefinitionto groundthebasesofthe analysis.

Thegeneralreference toprojecttypesis basedon theproject objective andincludes

the

following

list (Olson 2004): Newproduct

Reengineering

project

Maintenanceto an_existingproduct

.

Redesigning

an _existingproduct

Transitiontoa new platform

Also,

throughoutthediscussion referenceis madetocross-functionalteams. Cross-functional teams are composed of peoplefromvariousfunctional areas whose competencies are essential_{for achieving}a successful outcome. Theseteams include

employees fromalllevelsoftheorganizationand_{may include}membersfromoutsidethe

organizationincluding:

key

customers and consultants.

Lastly,

SeffahandMetzker

(2004)

definethe term traditional software

development as

technology

anddeveloper driven with the_{primary focus} onfunctional

requirements with littleregardforend users workflow or end users environments.

5. Background

Atfirstglance,thedifferentuser orienteddesignmethodologies seemto sharea common

theme:

keeping

theuserin mind when

designing

and_creatingsoftware applications.

However,

not all methods are equal. Thesolutionto theproblem_maynotbeas simple as

the selection of amethod,butrathertheselection ofthepropertechniques fromthe differentmethods.

Selecting

therightmethod requiresanalysis ofthetechniques within

themethod. Itrequires consideration of eachtechnique's _abilityto facilitatethecurrent projectgoal alongsidethe strategicdirectionoftheorganization.

This discussionof user orienteddesignmethodologies followsthetimeline ofthe

methods _{emerging into}theindustry. The discussion beginswiththe

Participatory

Design

method. Someofthemethod's names_{may have been} coined earlierthen the

developmentoftheactual method and_{may have}rootsthatgofurther back in

history

however,

thiswas notfactored intothe timeline. Thechartin Figure 1 representsthe timeline ofthe user orienteddesign methods. Noticeseveraloftheuser orienteddesign

methods emergedin 1989. Theorder ofthemethods_{emerging in 1989 is based}onthe

analysis ofthereferences totechniqueswithin a_previouslydefinedmethod. Theanalysis revealsthat eachuser oriented designmethodborrowsconcepts andtechniques fromthe

previous methods and sometimesrenamesthetechniques.

Therefore,

some ofthe overlappingtechniques are_merelyunique

by

thereferenced name. Thechartin

Useroriented

designmethod

(UOD)

Approximated initial availability

Personwho originated

Participatory

design

(PD)

1960 Christina Floyd

Kristen Nygaard Olav Terje Bergo

Scenariobased

design(SBD)

1980 Ivar Jacabs

John Carroll

Mary

Beth Rosson

Contextualdesign

(CD)

1988 Hugh Beyer

Karen Holtzblatt

Usercentereddesign

(UCD)

1989 Don Norman

Dr. Steven Draper Performancecentereddesign

(PCD)

1989 Gloria

Gery

Barry

Raybould

Learning

centereddesign

(LCD)

1989 Elliot

Soloway

Usability Engineering

(UE)

1993 Jacob Nielson

Deborah Mayhew Figure 1- UOD Time Line

6.

Participatory

Design

(PD)

6.1

History

Participatory

Design

(PD)

began in Scandinaviaaround 1960 fromcollaborationbetween

theNorwegianEmployers'

Federation

(NAF)

andtheNorwegian FederationofTrade Unions. Oneoftheoutcomes ofthiscollaboration effort was "arevisedWorker Protectionand

Working

Environment Act

[AML, 77;

S0rensen,

92]"(Levinger 1998). Thisact requiredthatend users participatein thedesignandbe sufficientlytrained touse new systems. Threemajor projects are credited_{for creating}thefoundation ofPD.

They

are:

The Norwegian Iron andMetalWorkers'

Union

(NJMF)

conducted from 1970tol973. Theirobjective wastoincludeworkersinnew

technology

plans.

. The Swedish DEMOS _{project(DEMOkratiske}

Styringssystemer)

was conductedfrom 1975to 1979. This project confirmedthat the

inequalities betweenworkersandmanagementwere _particularly unbalanced when

introducing

new technology. Theoutcome ofthis

project was aninstitutionalizedconflict managementprocess (Levinger 1998).

. TheDanish DUE_project

influence ontheuse of computer systems. Theprojectcontributedto theinitiation of aprofessionalcurriculum and research programin systems development (Levinger 1998).

Thecommon themeofthesethreeprojects was todemocratizethe_unityoflaborand

management when

introducing

newtechnologies. It iscleartoseethat"PD began inan explicitlypolitical_context,as part oftheScandinavianworkplace

democracy

movement"

(Muller 2002p. 1). Theoutcome ofthese threeprojects was thebases for PD whichis also referredtoasthe Collective Resource Approach.

Themore recentdevelopments in PDresultedfromthe first PDconferencethat tookplaceinl990 in

Seattle,

Washington. Theparticipantsincluded "prominent leaders from Scandinaviawhohadpioneered_{participatory} approachestocomputer systems development inthe70's and

80's."

Afterthisconferencefuture conferenceswereheld

everytwo yearstofurther

develop

anddefine PD (Levinger 1998).

There is no_strongevidencethatone personisresponsibleforthe developmentof thePD approach. Christine Floyd isthemainEuropeanfigure given creditfor

bringing

PDout ofScandinavia (Bouvin 2004).

However,

therootsoftheCollective Resource Approach are _generally associated with theeffortsin

Norway by

Kristen Nygaardand Olav Terje Bergo in the_{early 1970s (Levinger 1998).}

6.2 Definition

Defining

PD isnot_easy

because,

similartoother userorienteddesign_methods, practitioners _{vary in}theirperspectives,

backgrounds,

and areas of concern. Themore recentPD definitionsare asfollows:

.

"Participatory

Design

(PD)

is_{a set of}diverse_{ways of}

thinking, planning,and _actingthroughwhich people make_{their work,} technologies,and socialinstitutionsmore responsive tohuman needs"(TriggandClement2000).

.

Participatory

Design

(PD)

is "anapproachto_{the assessment,}

design,

anddevelopmentoftechnological andorganizational systemsthat places a premium on theactiveinvolvementof workplace practitioners

(usually

potential orcurrentusers ofthe_system)in design and

decision-making

processes"

(Trigg

andClement 2000). .

"Participatory

design

(PD)

isasetof_{theories, practices,} and studies relatedtoend-users asfull participantsinactivities

leading

tosoftware andhardwarecomputer products andcomputer-based

PD isnot_necessarilya"unified

ideology

or_{methodology but is} a techniquethatcanbeembraced. It is an approachtowardscomputer systemdesign inwhich thepeopledestinedtouse thesystem_playa criticalrolein

designing

it"

(SchulerandNamioka 1993p. xi).

Althoughthere isno singledefinitionfor

PD,

thecommon theme _among practitioners whousePD isthat theend user must participatethroughout theentire productdevelopmentprocess. This includesparticipationin preliminary discussions

between stakeholders and managers

(Trigg

andClement 2000). PDpractitioners

understandthat the organizational cultureandthe _{setting in}which workis done impacts

design,

and_therefore,PDemphasizestheimportanceof_spendingtimewith end users who are

doing

theworkintheirown environment. PDpractitioners alsohave learned

thattheend users aretheprime source ofinnovationand can _greatlycontributeto generatingdesign ideas. In addition,PDpractitionerslooktoresolve problemsthat extendbeyond

technology

and ofteninclude theprocess and arrangement of people.

6.3 Techniqueand process_summary

According

to

B0dker,

Br0nbaekand

Kyng,

PD is aperspectiveand atechniquenot

necessarily adesignmethod(SchulerandNamioka 1993p. 158). Schuler further

explainsPD as a perspective and not_necessarilyablueprintforadesignprocess. The

perspective ofPD istoachievethedevelopmentof a usableand stress-free software

design. The use ofappropriate_{instructions along}withthe_availabilityoftheappropriate

functions tosupportthe workflow aretwoelementsthatcontributetothe stress-free nature ofa software design (SchulerandNamioka 1993 p. 6-7). PDprovidestheproper techniques toachievethis goal.

Although PD doesnothavea specific _process,thetechniques lendthemselvesto theanalysis anddesignphase oftheprojectlifecycle.

During

theanalysis phasedesign

teammembers, learnabouttheworkthroughworkplace visitswhere theend users participatein interviews or workdemonstrations. Teammembersmeet afterthe

interviews anddemonstrations tocompile what

they

have learned. PDusesthe scenario, contextual

inquiry,

storiesand prototypetechniques all of whichhave been borrowed

by

other user orienteddesign methods.

Thetechniquesthatmake PDuniqueareworkshops and organizationalgames.

phase. PD _specificallyuses a_workshopcalledthefutureworkshop. Thefuture workshoptechniquewas created

by

Robert

Jung

andNorbert Miller

(1987)

toinclude

citizens inthedecision_makingprocess intown_planning and other political venues. This techniquerequires thattheparticipants write short statements oftheirideas on paper and thenplacethem on awallfortheentireteam tosee. Theoutcomeofthe_{future workshop}

resembles an _{affinity diagram. The future workshop}then goesthroughthreephases, whichare; critique_phase,

fantasy

_phase,andimplementationphase. Thepurpose ofthe

critique phaseistodefine specificissuesabout current work practices. Theteamthen

moves intothe

fantasy

phase. Thepurposeofthe

fantasy

phase istodefineanideal futuremodel. Theparticipants generate 'what if statementsthatwould solve current

issues. The lastphaseis theimplementationphase. The implementation phase alignsthe ideasgeneratedinthe

fantasy

phase with reality.

During

this phase, the teambeginsto designa realistic solution. The use ofthe termimplementationhere isnotthemovement

ofthesoftware application to theend_users,butrathertheimplementation ofideas intoa design.

Thetechniqueof

'design-by-playing

games'

alsobridges theanalysis workinto designwork.

Ehn, Sjogren, B0dker,

Gr0mbaekand

Kyng

developedtheideaof

'design-by-playing

games'

because ofthe _abilityofthesetechniques to_{influence participatory} designmethods (SchulerandNamioka 1993 p. 168). Thegames supportthecreation of

alternative work organizations

by

_enactingthecurrent routine andthen

discussing

problems. It includes thediscussionabouttheproblemsthata newalternative _may

create.

Using

games creates alessemotional environmentfor discussion. Games

keep

thework_entertainingand atthesame_time,the teamfocuseson theworkflow. These techniquesallow formembers unfamiliar withthedesign discipline an_{easy way}to contribute. Mullerexplainsthat thegamesremove "theconventional _authorityofthe software professionals [andreplaces

it]

with a sharedinterpretation basedon

contributionsfrom multipledisciplinesand

perspectives"

(Muller 2002p. 18). Thistype ofdiscussion allowstheanalysis anddesignprocesstomove ataquicker pace and produces betterend products becausepeoplelistentoeach other's needs andthe

techniques thatcreateasafeand productive atmosphereforpeoplefrom different perspectivesto_{discuss conflicting}opinions. ThechartinFigure 4 summarizesthese games.

Game Name Description

Organizational Game Acharades-like card gamethatfacilitatesthediscussionof current workflow problems andto achieve a suitable solution. Specification Game A scenario-based gamebasedon a set of 'situationcards',each

of which describeda workplace situation. Thedesignteam takes turns

drawing

acard and

leading

thediscussion ofthe work situation describedonthecard.

Layout Kit A game offloor-plans and equipmentlayout. This illustrates the workers'

perspective ofhowthe_{shop floor}shouldbe redesigned.

Desktop Publishing

Game A story-board gamethatillustrates and annotates on poster size paperthecomponentsof work.

Figure 4 Design Game

Summary

(Muller 2002p.

17)

Stories are anothertechniquePDembraces.

Stories,

just likeworkshops and

game_techniques,

bring

various perspectivestogether

during

theanalysisphase. "Stories in participatorywork_{may function in} atleastthreeways: triggersfor_{conversation,}

analysis,and

feedback"

(Muller 2002p. 11). Ifan end usertells thestory,itprovidesthe

teamwithbackground informationtounderstand whatfunctionsandfeaturestheproduct must provide.

Alternatively,

ifthe _{story is}told

by

amember ofthe_{design team, it is}used

topresenttheirconcept of what adesignedproduct will

do,

how itwill beused, and what changes will occur as a result.

Drama isanothertechnique thatsupportstheanalysisphaseinthePDmethod. "Dramaprovides another_wayto tell stories

-in theformoftheatre or of video"(Muller 2002p. 14). The drama mayrepresent a currentsituation or afuture situation.

However,

it issometimes difficulttodefinewhether agivendramadepictsthepresent orthefuture because the twoare oftenmixed.

Once the teamhas done_{the analysis,}

they

canmoveintothedesignphase withthe

use of prototypes. Prototypes arethe most_commonlysharedtechniqueacross all user orienteddesign methodologies.

However,

_B0dkerandGr0nbaek

(1991)

introducedthe

prototypinginthat traditional _prototypingapproaches_mainlytake theperspectiveofthe

analystor

designers,

whoconductinvestigations intheend user'senvironment,

develop

prototypeson _{their own,} andthen sharetheresults with thesoftware engineers and

eventuallywith theend users

(B0dker,

Gr0nbaekand

Kyng

p. 170). Cooperative

prototypingmeans thattheend users_actuallycreatetheprototype _alongsidetheother

teammembers.

6.4 Projectteam type

PDrequires morethana cross-functional team. PDhas been successfulwhere unions are

popularand when

'Workers'

Billof

Rights'

have beenestablished. The hierarchical

structurethat the_majorityofU.S.companies use isnotconducivefor PD. PDwould

require major_{restructuring for}mostU.S. companies. U.S.software development

companies would needto integratesoftware engineers withtherest oftheorganization,

and allow software engineersto interact

directly

withtheend users.

6.5 Application domain

The PDmethod was_{primarily designed}tofinetune_existingsystems. PD is successful

on projects with well-defined scopes and unlimited_{accessibility}to theend users. PD asa

methoddoesnot work wellforgeneral use software creationorinsituations wherethe

end user_{group is large}anddiverse. GrudinandPruittexplainthat"cooperative design

techniques canbeeffectivein in-houseor customerdevelopmentcontextsbutareless

effective incommercial productor package software

development"

(Grudin andPruitt

2002 p. 1). Theproblem withPD formass-market softwaredevelopmentproducts isthat

it isnot reasonable tohaveend user representativesforeachtype of user_group

participatein the analysis, design andevaluations. Thetimelines do not allowforthis

typeof participation andthecost would not provide enoughbenefit. This isnotto_say

thatPDas atechniqueis worthless,just as an end-to-end methodit isnot reasonablefor

mosttypes of software productdevelopment.

Inaddition, the 'Workers' Bill of

Rights',

thatare established

by

unions_may

contribute to thesuccess ofPD. This 'Workers' Bill of

Rights'

setstheguidelines and

keepsthedesigners andsoftware engineers accountableto theend users. It is

questionableif PD wouldbesuccessfulin an environment were such agreements were

6.6 Integration

feasibility

PD isanapproachthatrequiresa cultural change within an organization whichtodate haspreventedthis method_{from seamlessly}

integrating

intothesoftwaredevelopment industry. Thistype ofchangerequires _changingan organization's culture.

Grudin,

a

Usability

Engineer at

Microsoft,

explains_that,

"participatory

designismoredifficultto accomplish outsideoftheScandinaviancountriesbecauseofdifferencesin legislative environment, workplace_{unionization,} and scale andfragmentation of software

developmentorganizational

models"

(Muller 2002p. 229).

Implementing

atruePD

approach would require an organizationtoallow end usersto

fully

participateon project

teams andbetreatedas equalteammembers and notjustas peripheralteammembers who areinvolved in requirements_gatheringandthenare not spoken tounless

compromisesto therequirements are required.

Changing

the_wayan organizationthinks about end user participationdoesnothappenovernight. Thetraditional one-directional approachtosoftware productdevelopmentwould needtobecomea

two-way

discussion werethe _analysts,

designers,

software engineers and end users all participatein the

discussionofthesolution (Muller 2002p. 6). ThistypeofdiscussionrequiresITto removethe walls and

truly

listento theend usersthroughout theprojectlifecycle. These meansthatunlesssoftwaredevelopmentorganizationsare_willingto_modifythelevelof priority forend userinvolvementand are_willingto

truly

listentotheend users needsthe

bestthePDmethod canhope for istobeused as atechniqueandtocontinuetobe integratedwith other user orienteddesignmethods.

6.7 Advantages

PDgoesbeyondother methodstoinclude end usersas afull-fledgedteammember. It strivesfor designersand end userstohave a practical_{understanding}of each other. Practical understanding differs fromprepositional_{knowledge. Practical understanding}

"is understandingthatcomesfromthe practical experience of

doing

_somethingandthe recall tomind of earlier

experiences"

(Ehn 1993). Prepositional knowledge is

being

able tousedefinitionstoexplain_something thathasnever_actuallybeenexperienced(Stanford

University). PDencouragesdesign

by doing

thus_minimizingthelanguage

AnotheradvantageofPD isthatitencouragesdecentralizeddecision making

because end users participateintheentire designprocess. Endusers are not_only

observedand

interviewed,

_{but actually}participateinthecreation ofthedesign.

Thegoal ofPD istounderstand organizational changethat will occur and_may

include_{restructuring}theend users workflow when

introducing

new ordifferent

technology

in organizational structures (GrudinandPruitt2002p. 99). PDminimizesthe

numberof surprisesthatthenew

technology

_maycreateinthe workflow. This is because

PDencouragesa mix of nonlinguistic andlinguistic design artifacts.

Using

nonlinguistic techniquessuch as mockups and prototypes helpsteammembers see a pictureand

minimizestheamount ofinterpretation.

Using

linguistictoolssuchas scenarios also allowsforallteammembers toparticipatein and understandtheend users process prior

todesigning. PDconsidersmorethan theend usersina_silo,butrathertheendusers

within theorganizational structure.

In _addition,PDencourages and supports_earlyproduct adoptionfromthe end user

community. There isevidencethatanincrease inend userinvolvementthrough

participationin design activities canleadtoincreasedwillingnesstouse theproduct

whenit is implemented (Muller 2002).

Thus,

PD canbevaluable not_{only in shaping}

technology

to theend user's_needs, butalsoin shapingtheenduser's willingnessto

try

a

new

technology

(Muller 2002p. 299).

Theultimate advantage ofPD isthat thenew software product will not _{only be}

useable and usefulbuttheend users willhavea greater_{understanding}ofhow the

application_actuallyworks.

6.8 Expectations

Presentandfuturesoftwareisexpectedtobemoreinteractiveand unobtrusiveto theend

userthanearlier softwareapplications.

Therefore,

new software designcannot exclude

frequentparticipation fromtheend users. PDclaims other user orienteddesignmethods

donot

truly

include end users. The reality isthat theother methods includeend users as

post adhocmembersof ateam that_simplyreview and sign off on requirements.

However,

embracing PDwillbe difficult intheUnited_{States primarily because}of

computer products shouldtakepartin thedecisionsthataffectthesystem andthe_{way it}

is designedand

used"

(Greenbaum 1993p. 28). Although theU.S.cultureisconsidered

democratic,

whenitcomes tosoftwaredesignand

development,

afewpeopledictatethe

outcome. In

theory

software engineers agreethatend users shouldbe

involved, however,

inpractice software engineersoftenfeelthatend users makeimpossiblerequests that

cannotbeaccommodatedin the timeframeandbudgetestablished

by

stakeholders.

"Many

countrieshavelegislatedthatrepresentatives ofdifferent interests be involved in

projects; elsewhere,management andlabor haveagreedtoconsultationover_any proposed change_{in working}conditions.In mostEuropean countriesformal

technology

agreementsbetweentradeunions and employer organizations establish requirementsfor

developmentprocesses"

(Gr0nbaek, Grudin, B0dker,

andBannonp. 80).

Therefore,

althoughPD worksinothercountries,theUnited States has adopted otherdesign

methods, whichlimitend userinput inthesoftwaredevelopmentprocess. "Although sustained userinvolvementseems

desirable,

itseffect on commercial productsisnot clear"

(Grudin andPruitt 2002p. 1). This uncertainty abouttheimpactto thebottom line

limits the_abilityof organizationstoembrace PD.

7. Scenario-Based Design

(SBD)

7.1

History

Theorigin of scenarios is in theatrical studies. Scenarios were and are used

by

_many

people such as _{militaryemployees,}economistsand_policymakers for

long

range planning andtoweigh theconsequences of actions (Carroll 2000ap. 320).

However,

Ivar Jacobsen promulgatedthe_popularityof scenarios withhis use caseapproach to

software_{engineering (Carroll} andRosson 1992 p. 182).

In the_early

1980s,

SBD emergedfrom theHCIfieldtoresolve theneedto

providetherightbalance between modelingapproaches and_purelyexperimental

approachesthatrelied

heavily

on _usability

testing

(Jarke,

Bui andCarroll 1998 p. 159).

As HCIcontinuedto

develop

throughthe

1980s,

focus was placed onthe concept of usabilityandits rolein systemdevelopment. Itwas

becoming

obvious that_usability

of_{every step}ofthesoftware_{development lifecycle starting}with analysis (Rossonand

Carroll 2002p. 13).

Inthe

1990s,

scenario-basedsoftware developmenttechniquesbecamepopularin

software_{engineering because}

they

described

key

situationsin a narrativeformatthat an

audience _representingvarious perspectives could_easilyunderstand(RossonandCarroll

2002p. 7). Thiseliminatedtheneedto share complex models withtheend users and

stakeholders. Scenariotechniquesbridgethe communication_{gap between}the team

membersthatprovide requirements andthe teammembers thatproduce andimplement

thedesign. Scenariosare a mechanismthatcanbeusedto streamlinetheexpectations

aboutthefinalproduct.

7.2 Definition

"Scenario-based designtries to

identify

the critical andtypical things thatpeople door

wanttodoandthe tradeoffsassociated withdesign featuresthatenablethese

activities"

(RossonandCarroll 2002p. 359). Scenariosfocuson thesituation

including

thepeople

involved,

the environment, theobjectives andthegoals. "Inscenario-based

design,

descriptionsofhowpeople accomplish tasks are_{primary working design}

representations"

(Carroll 2000bp.45). Scenario-based design containsfive

key

elements. The

information in Figure 2 definesanddescribestheseelements.

7.3 Techniqueand process _summary

Thegoal ofthe SBDprocessis tofocusthedesign team's

thinking

on the_necessaryend

usertasks (Rosson andCarroll 2002p. 315). The SBDprocessdoesthis

by

_providingan

iterativeapproach_{using different}types of scenarios. Theprocessprovides the_abilityto

refine the_{originally defined}scenarios. The SBD processincludesthe

following

steps:

(RossonandCarroll 2002p.

346)

1. Developmentof requirement scenarios

2. Validation/refinementof scenarios with users andcustomers

3. Developmentofbasic-leveltaskscenarios

4. Refinementofdesignscenarios withdevelopmentteammembersand

customers

5. Developmentofinformationmodel 6. Review withteammembers

7. Developmentof paper prototypes

10. Review withteammembers

11.

Develop

and refinea_runningprototypes

12. Formativeevaluation

13. Analysis oftranscripts/reportpreparation

14. Detaileddesignand prototype driven iterationof previous threesteps

4. Beprecise but include everyone on the team

Figure 2- Five_{elements of}ScenarioBased Design

RossonandCarrollp.21

Thescenarios are_{defined using} a

five-step

_method, whichis: analyzingthe

organizational

decision,

identifying

the

key

decision

factors,

_analyzingenvironmental

forces,

defining

thescenariologicand_analyzingtheimplications forthefinal decisions.

Analyzeorganizational decisions isthe_{first step} and occurs priorto_creating

scenarios. This is becausetheteammust understandtheorganization's goal and vision

forthefuturewithin thescope ofthe topic

being

analyzed. This analysisincludes

investments,

and market strategies. Thesecond_stepto thescenario

building

processis to

identify

thefactors thatinfluence an organization'sdecisions. These factorsprovide

insight intotheorganization'svalues thatcan

help

theprojectteamunderstandthe

strategic goals and provide aframeworktomaketactical decisionswithin theproduct

developmentprocess. Thethird_{step is}to analyze environmentalforces. This analysis

directly

defines future businessstrategy. This includes consideringpotentialcompetitors

and general economicconditions. Thebackgroundanalysis providesthemechanismto

createtheinitial scenarios. The_{fourth step is} todefinescenariologic. This step defines

thescenariotemplatethatwillbeusedthroughouttheprocess. "Scenariologic involves

organizing themes,principles, hypothesisand assumptions thatprovideeach scenario

with a_coherent,consistent and plausiblelogic underpinning"

(Jarke,

BuiandCarroll

1998p. 164). Thisthenmovestheprocess to thefifth andfinal step, whichis analyze

implicationsfor decisionsand strategies. This stepconsiders the implicationsofthe

scenario. The

following

questions shouldbeansweredinthis step:

What dothescenarios_sayaboutthedesign and

timing

of particular strategies?

Whatthreatsand opportunities dothescenarios present

forthefuture?

Whatcriticalissuesemergefrom thescenarios?

Fromtheorganization's_planningperspective, what

kindof

flexibility

dothescenarios suggest are

necessary?

SBDprocessis hierarchal anditerative in its approach to

defining

and_refiningthe

differenttypesof scenarios. SBD defines fivescenario categories: problem_scenarios,

activityscenarios,informationscenarios, interactive scenarios,and edge case scenarios.

Thescenario categories providetheanalysis focus forthe teammembers.

Aproblem scenariofocuses onlyon currenttasks. Theseare created with the

help

ofthestakeholders _{early in} theprojectbecause

they

help

define thescope oftheproject

(RossonandCarroll 2002p. 25).

Activity

scenarios (a.k.a.

daily

use_scenarios)focus ontheinformation theend

user needstocompletethetask. These scenarios attempttoresolve theissues defined in

workflow (RossonandCarroll 2002 p. 142). Thesescenarios definewhatneeds the

process shouldbewithout regardto thedesign.

Information scenarios are an extension of_activity scenarios. Information

scenarios providethedetailabouttheinformationthe system providesto theend user.

Interactionscenarios describethe detailsoftheuser action andfeedback. More

explicitly interactionscenarios explain: theinformationneeds, theactionstheusertakes

tointeract withthe task

information,

andtheresponsesthe system providestothe user's

action. Theseare _verysimilartousecases_{only in}a more narrativeformat (Rossonand

Carroll 2002p.

16,

26).

Thelasttypeof_scenario, edgecase_scenarios, shouldbeused cautiously. Edge

case scenariosincludetasks thatare_uncommon, but analyzingthesecausesand effects

can prevent anincompleteproductdesign. In mostcases, thereisminimal valuein

creatingedge case scenariosbecause

they

have a_verynarrowfocus. As _such,

they

should_{only be} used whenthe time permits,orthelevelof_complexity andimpactof

possible mistakes are so_costlythat thesesituationscannotbe ignored (Cooper 1999p.

181).

Oncethescenarioshave been drafted

they

arefurtherrefined with theuse of claims

analysis. Claimsanalysisis aformof_{participatory design}wherethedesign teamand end

users scan the scenarioforthecauses andeffects andcapturethedesignrationaleforthe

future system. Claims analysisis defined

by

Chin, Rosson,

andCarroll

(1997)

as "a

refinementof_{participatory design in} whichtheusers

directly

analyze current and

envisioned scenarios of

use"

(Carroll 2000bp. 272). Claimsanalysis provides a method

forsystematic_questioning thatis imperative in_{understanding}theuser's needs. This

techniquebringstolight

issues,

conflicts,andcontradictionsthatare notobviousinthe

scenario. Theproblem withclaims analysisis it is an iterativeprocess thatdoesnothave

a well defined startingor_endingpoint(Carroll2000bp. 135). Thismeans thatit is

difficulttoknow whenenoughanalysis has beendone.

Typically,

this_{activity is} time

boxedso thatwhenthe timeruns outthe analysisisconsidered complete.

The diagram in Figure 3 provides an overview of the scenario development

glance, itappears thatscenario developmentis alinearprocess, it is actually an iterative

process.

Scenario

Building

Process

Analyze

Analysisof

stakeholders, fieldstudies.

Metaphors, information

technology,HCI theory,guidlines

Summative

evaluation

Problem Scenarios

T

Design

ActivityScenarios

InformationScenarios

InteractionScenarios

Prototypeand Evalute

Usabilityspecifications

Claimsabout current practice

Iterativeanalysis of

usablityclaims and redesign

Rosson& Carrolp.25

Figure3- Scenario

building

process

1A Projectteam type

Cross-functionalteams workbestwhen_usinganSBD process.

However,

becausetime

lines are_{shrinking due}tomarket

demand,

it is

increasingly

moredifficultto haveall

teammembers participatein every stepoftheSBDprocess. Eachteammember

typically

when _{participating}on across-functionalteam.

Typically,

designteammembers are

assignedtobuildcertain scenariosandthen the teamgatherstoshareknowledge.

7.5 Applicationdomain

ThetwoexamplesCarrollprovides suggests thatSBDis successfulon well

defined,

small-scale_{projects, using existing}

technology

and a_{centrally located}teams. For

example,Carroll describesa project

delivering

a multimedia systemfor educating

engineers in a university. Theproject characteristics

include;

an enormousill-defined

scope,

implementing

complex_technology, and_{geographically distributed}teammembers.

Intheexample ofthemultimediaproject,Carroll explainsthata vision scenario was

createdbut only rarelyreferenced. Themultimedia systemproject veered offthe SBD

approach and used a prototypedrivenprocessbecauseoftheenormous scope. The

second exampleCarroll providesis adesignof a

library

systemthathada_smaller,

well-definedscope, and_{centrally located}teammembers. Carrollexplainsthatthisprojectwas

also not_completelysuccessful. The SBDprocess usedinthe

library

systemdesign did

not_accurately

identify

theroot cause oftheproblem andthis created rework. Carroll

admitsthat themultimedia and

library

examples were not representative ofbestcase

practiceforscenario-baseddesign (Carroll 2000bp. 43). Thiscallsintoquestionthe

capabilityofthismethod.

The capabilityofthis methodis furtherquestionedbecause Carrollexplainsthat

SBDhasnot used on projects thatincludesafety-critical_{applications,} embedded_systems,

or_{concurrencyand,therefore,} isnot sure of_{its ability}tosupport suchprojects(Carroll

2000bp. 327). "Scenario-baseddesign may be

differentially

effectivefor different kinds

ofdevelopment

projects"

(Carroll 2000bp. 327). Carrolladmitsthat"scenariosare often

used

ineffectively

or

inarticulately"

(Carroll 2000bp. 43). Although there_{may be}

benefitsof_using scenarios as a_technique,it issuspectthatSBDwill provide successful

results.

7.6 Integration

feasibility

Scenario-basedactivities canbe integrated into a system developmentmethodology.

"McGraw andHarbison

(1997)

have describedascenario-based_engineeringprocessthat

integrates scenariobaseddesign with traditionalstructureddevelopment_methods, and

these traditionalmethods"

(Carroll 2000bp. 317).

They

explain thatscenarios _closely

mirrorhow software engineers andsoftware_qualityassuranceteammembers reason withintheirfunctionaltasks. Theclaims analysis will seem recognizabletoorganizations thathaveusedtraditional structured analysis methods tosoftware applicationdesign. This is becausesoftware claims are analogousto _usabilityclaims usedinSBD. The

disparity

isthatsoftwareclaims addressimplementation featuresthathaveconsequences

on softwaredesignquality. The usabilityclaims articulatetherationalefor

designing

with end usersin mind.

7.7 Advantages

Scenariosare_easytoproduceand assist with cross-functionalteamparticipation and informationsharing. Thenaturallanguageof scenarios allowsteammembersfrom

various perspectives toparticipate.

They

also provide a mechanismto shareknowledge within theteamandto transferknowledgetomembers outsidethe team.

Scenarios

help

plan thework. "Thescenario-basedprocess allows allthe

activitiesto communicateina common vocabulary: _orientinggoals and_visions,

workplace needs _analysis, designwalkthroughs, envisionment, prototypes and_rationales, evaluation of criticalincidents andtestcases, and potential generalizations and

abstractions"

(Carroll 2000b p. 309). Thereviewofthescenarios helpsthe team

members seethe project goalsin termsoftheend user's needs _alongwith the

organization's goals. In _addition,the scenariosfacilitatethecompletion of eachteam

member'sfunctionaltasks. For_example, usage scenarios can

help

todefine interview questionnaires that the_{interaction designer may be}requiredtocreate.

They

can alsobe

usedto

help

guidetheimplementation anddeployment becausescenarios explainthe

frequency

ofthe tasksand potential peaktimeswhen_{it may}notbeappropriateto

implementa new system. Scenariosexpoundthepatterns andsocial mechanisms thatare

importanttoconsiderinthe design. Thepatterns oftaskcompletionin a scenario

identify

the appropriate

functionality

layout.

Anotheradvantageisthatscenarios

help

designersreflectwhile_givingthema

sense ofaccomplishment. "Ascenarioisaconcretedesignproposalthatadesignercan evaluate and

develop,

but is also roughinthatitcanbe_easily alteredandallows_many

tomovetowards amore concrete design. "Scenariosaregood at_{vividly capturing}the

consequences andtrade-offsofdesignsat variouslevelof analysisand withrespectto

various

perspective"

(Carroll 2000bp. 87). This leadsto thenextadvantage.

SBDprovides a systematic methodto designand evaluate. SBD facilitates design

rationale_usingclaimsanalysis. Theclaimsanalysis technique,whichis alarge aspect of

SBD,

makes the_{relationship between functions}and consequences of use explicit (Carroll

2000bp. 152

-53). Claimsanalysis allows the team toanalyze _explicitlythepros and

consof aspecific design asitrelatesto thescenario. Thesystematic method minimizes

downstreamdesignchanges.

SBD andits techniques matchthedesignanddevelopmentteam

members' cognitive

model _{making it easy for}them to learnthismethod. Carroll stipulates that

object-oriented software requires developersto thinkinterms offunctionsandSBD

complementsobject-orienteddesign reasoning because thevarioustypes of"scenarios

areideal structuresfor engineeringrequirementsand_{usability, that}

is,

for

identifying

the

required

functionality

of systems and_evaluatingtheeffectiveness oftheirrealization

(Carroll 2000bp. 233).

7.8 Expectations

SBD techniqueshave beensuccessful and will continuetobe successful whenintegrated

into other user orienteddesign methods. Scenarios as atechniquehave beenborrowed

by

other user orienteddesign methodsbecause ofthevaluethis techniqueprovides to the

initial analysis phase.

However,

SBD as a user orienteddesignmethodhasnot yet

proven itselfrobust enoughfor anytypeof project. Carroll admitsthat"it is far from

clearthatscenario-baseddesign will provide a_completelygeneral and comprehensive

systemdevelopment

methodology"

(Carroll 2000bp. 327). It isquestionableif SBDwill

everbeperceivedas a useable designapproachbecause itsrelianceon thescenario asits

main deliverable.

Oneofthechallenges for SBD isthattheprojectteammustbeableto tolerate the

vaguenessoftherequirements. Scenarios allow muchinterpretation ormisinterpretation

by

thereader. Softwareengineers _customarilyhavealowtolerancefor_ambiguitywithin

the requirements, whichis themost probablereasonfor SBDnot

being

_widely accepted

usedscenariosin thedevelopmentand analysis of prototypes

typically

aniterative

process ofrequirements

development."

(p. 317). Theuse of scenarios as an analysistool

works _well;

however,

_touse themasthe_{primary deliverable}toasoftware engineerhas

notbeen proven successful.

The informalnature ofSBD isyet another obstaclefor SBD. Carrollexplains,

"Scenarios are not

formal;

they

arenottechnical_{in any}

fancy

sense"

(Carroll 2000bp.

17). SBDtechniquesproduce words ratherthanpicturesor

diagrams,

andmosttechnical

teammembers donot_{enjoy reading}volumesofinformation. Thetechnical team

memberscannot see thepictureif

they

donot readthewords.

In addition,therepeatablesuccess ofSBD hasnot yetbeen proven. Although

Carroll'sultimate goal istomakeSBD the

key

to_{moving design}workintoa_science,this

goalisunrealistic. Theproblemis thatnotwosoftware developmentprojects are_exactly

alike.

Lastly,

SBDsuccess dependsonthe _{training,support,} and creation of scenario

managementtools. There is a critical needfortools thatcreate, modify,organize and

track thescenario creation process. Scenarios canbecome difficulttomanage when there

aretoo_{many iterations} and variations. Although scenariocreation onthesurface seems

easy,producingtheright number withtheright amount ofdetail is achallenge. In

addition,designerand software engineers needtolearn howto transform the scenario

intoa useful and usable softwaredesign.

8. Contextual Design

(CD)

8.1

History

Contextual Design

(CD)

begantoevolvein 1988. "CD wasdesignedatDigital

Equipment Corporation underthe

leadership

ofDr. KarenHoltzblatt"

(Marion 1997a).

HoltzblattcreatedCD toprevent projectteams_{from agonizing}about what shouldbe

designed

by involving

end users upon theprojectinitiation. In

1992,

Karen Holtzblatt

andHugh Beyer founded InContext

Enterprise,

whichis a_{consulting companythatis}

alignedwith theCD method. CDcontinues to

develop

asit is

being

used

by

more

8.2 Definition

ContextualDesign

(CD)

is "anapproachto

defining

software andhardware systemsthat

collect multiplecustomer-centeredtechniques intoan integrated designprocess(Beyer

1997p.3). The CD method providestechniques_{for gathering}

data,

driving

design,

and

managingteams. Thismethod stressestheneedtogather end userdata intheform of

datamodels thatbuildon a structural analysis approach_usingtechniques such as object

modeling,enterprise_modeling, and process reengineering. Thetechniques

help

to

facilitatethedecisions abouthowtheend user willfunction in thefuture. "Contextual

Design provides completesupportforthedesignprocess,from theinitial customerdata

gatheringthrough the transitiontoobject-orienteddesignor whatever other

implementationmodel you favor"

(Beyer 1997 p. 5). Itprovides a clear processand

concrete actions. Thecentral aspect ofCD isthatitpromotes _stayinggroundedinthe

understanding ofhowtheend user works.

8.3 Techniqueand process_summary

Thesteps for CDare as follows:

1. Contextual

inquiry

2. _{Work modeling}

3. Consolidation

4. Workredesign

5. Userenvironmentdesign

(UED)

6.

Mock-up

and evaluation

The initial step in CD is performingcontextual inquiries. Contextual

inquiry

is a

technique thatprovidesinsight intothecurrent workflow and_{includes uncovering}theend

user's tacitknowledge. Contextual

inquiry

typically

begins withone-on-oneinterviews

intheend user's workenvironment. An alternative approachtocontextual

inquiry

_may

beneedediftheworktakes place overa

long

periodoris difficultto observe. Alternative

approaches can be identified in Appendix A.

The subsequent_{step in CD is creating}workmodels. Workmodels consolidate

theinformationgathered

during

thecontextual

inquiry

_{and provideatangible}

representationof end user's work. CDprovides several_{different modeling}techniques

thatassist theprojectteams_{understanding}the

breadth

oftheend usersrequirements.

By

moreflexiblesoftware applicationarchitecturethatsupportsfutureexpansion. In

addition, thesemodels areuseful_{in managing}theprojectandthe_marketingofthe software application because

they

_clearly

display

end user's workflowandthehigh-level

functionality. CDuses five typesof work models: workflowmodels, sequencemodels,

artifactmodels,cultural models and physical models.

Workflowmodels

help

teamstounderstandthe end

users'

communication

patterns. Theteamidentifiestherolesand responsibilities ofthepeople whodothework

andhow

they

interact. "Theconsolidatedflowmodelis the_{best map} tohow workis

done,

_showingthebreadthof work andthe detailsofhow peopleinteract. Theflow

model shows what roles people_play, andifyouhavesystems _{already in}place, youcan

see whatroles

[are]

supported"

(Beyer 1997p. 170).

Typically,

work rolesare consistent

acrossdomainswhich can assisttheteam_{in providing}a softwareapplication thatis

usefultoabroadrange of customersifthatis thegoaloftheproject.

Sequencemodels showtheorder of stepstaken tocompletethework,

including

the trigger thatinitiatedwork. "Sequencemodels show whatthecustomeris

trying

todo

andhow

they

go about

doing

it"

(Beyer 1997p. 197). Thesequence modelillustrates

communicationbreakdownswithin theprocess

being

analyzed. Thesemodels aresimilar to taskon arrowmodels anddecision diagrams thatare usedin structuredsoftware

analysis approaches.

However,

thegoal ofthesequence modelsis not_onlyto showthe

order ofthe stepstocompletethework,butalsotoillustratethecurrentcommunication

breakdowns.

Artifactmodelsinclude job aids,reference_manuals, andguides. Theartifacts

illustrate an _opportunitytoenhancethecurrent software application. "These

[artifacts]

reveal howpeopleorganize and structure workfrom

day

today"(Beyer 1997 p. 178).

Theartifacts are analyzedfor_{structure, usage,} andintent. Thegoalofthisanalysisis to

integrate information intothe softwareapplication.

Culturemodels reveal work constraintscausedboth

by

anorganization's_policyas

a whole and values ofindividualemployees. _{The way} employees dress andthelanguage

they

use defines an organization's culture. Thecultureisfurther defined

by

the

relationship between departmentsandthegeneralregardto thecustomers. "Thecultural models speakthewords peoplethinkbut don'tsay"

toemployees'

regardforeach other andthecustomer assiststhedesignteamto

understandtheorganization'sculture andprovides insightfor establishingthebasic

design standards. Forexample,ifa softwaretooliscreatedfora conservative_company

thelookandfeel shouldnotinclude glitzygraphics.

Physical modelsrepresentthe_groupingof people andequipment, andthe

movementbetweenobjects inordertogetthejobdone. Theenvironmentthatatoolis

usedin will often revealdesign constraints. Themovementofartifacts,communication,

toolplacement, amount ofspace, andtemperatureall affectdesign. Thismodel guides

thedesignteam'screation of asuitablemetaphor andtheplacementoffunctionswithin a

software application.

Eachmodelfocuseson a unique perspective to

help

the team _{stay focused}onthe

end

users'

issues. The flowmodelidentifiestheroles and responsibilitiesforsequence

model. Theresponsibilities arefurtheranalyzedto definethetasksthatmake _upthe

sequences model. Artifactcollection identifiesthe tools_necessarytocomplete one or

moreofthesteps inthe sequence. Thecombination ofthesemodelsis thenusedto

understandthe_companyculture, andthephysicallayoutoftheworkplace inrelationto

theend user's requirements.

CD providesa specific _stepthat_{involves consolidating}the

information,

_{making it}

manageable enough tomoveinto adesign approach. Theconsolidation effort uses

interpretation sessions where_{affinity diagrams} aredeveloped. The interpretationsession

includeparticipation oftheentireteamandbuilds a sense ofcommitmentinthe

developmentoftheappropriate solution. The interpretationsessions allow everyoneto

hearthesamequestions,answers, anddiscussions.

Therefore,

teammembersbuildon

each

others'

ideas. Beyerexplainsthat:

"Interpretation isthechain of_reasoningthat turns afact into an action relevantto thedesigner's intent. Fromthe

fact,

theobservable_{event, the}designermakes a

hypothesis,

aninitial interpretation aboutwhatthefactmeans orthe intent behindthefact. Thishypothesis has animplication forthe

design,

which can berealized asaparticulardesign ideaforthe

system"

Therefore,

theinterpretation sessions provides theappropriateforumto

develop

an

affinity diagramandconsolidatedwork models.

Affinity

diagramming

isone ofthe tools usedtoillustratetheconsolidated work

models. The _affinitydiagram

typically

hasahierarchical structureinwhich the_{affinity is}

an outline oftheend user's work. It illustrates the

key

elementsoftheproblemthatthe

designteammust resolve. Theconsolidated work models

including

the_{affinity diagram}

represent_seeminglytrivialend user anecdotes as real system obstaclesthatrequire a

solution.

Theconsolidatedtasksequence model canbe donewiththeuse ofstoryboardsto

sketch outhow thesystem will worktoaccommodatethetask. Storyboards are_rapidly

created and usedto illustratewith minimal detailhowthework willbe done. This

techniqueprovidesthe teama visual aidforwhathastohappen inthedesign and whenit

hastohappen.

Workredesignis thenext appropriate _{step if it is}withinthescope oftheproject.

Workredesign provides efficiencies to thework practicethat_mayor_maynotincludethe

use oftechnology. _{This step}also takes advantage ofthestoryboardtechniquebecause it

visuallycommunicatestheworkflow.

Oncethework models are_{consolidated,} theuser environmentdesign

(UED)

model is created. CDuses aUEDmodeltoillustrate howeach part ofthesystem

supportstheend user's_work,whatfunctions are_available, andhow

they

are

interconnected. The UED isnotconcernedaboutthe UI

details,

but ratherthefunctions

that thesystem will provide andhowthesefunctionsrelatetoeach other. Thefunctions

arethen made availablethrough menus,toolbars, andkeyboardcommands thatcan be

consideredlater inthe designprocess. Ifstoryboards werecreated

they

can be leveraged

to buildtheUEDmodel.

However,

theUEDmodel can be builtwithoutstoryboardsifa

currentsystemis inplaceandtheprojectgoalis toreengineerthecurrentsystem. Inthis

situationthe UED isusedtorevealthecurrent system's problems in _meetingtheend

user's workflowrequirements. Similar_{to the storyboard, the} UED isusedtomanagethe

structureofthe system; thedifferenceis theUED adds alevelofdetail.

The UED canbeusedforseveral purposes

depending

onthegoal oftheproject.

release. This is becauseit illustrates thescope of

functionality

fortheend-to-end work

processes

being

analyzed. Whenthegoalistocreate a new softwareapplication,the

UEDprovidestheteamaconcrete and consistentunderstandingof whatdataneedsto be

available tocompleteeach _activitywithin a given process. The UED specificallyassists

the_{interaction designers in creating}an_{appropriately}layeredinteractiondesign because

"the UED works against proliferation of

dialog

boxes"

(Beyer 1997p.398). IftheUED

has allottedforafunctiontobe part ofthefocusarea, then thatfunction musthave

allocated spacein thedesign. The UEDcan alsobeusedtoleve