Getting around the task-artifact cycle - CiteSeerX

Getting Around the Task-Artifact Cycle: How to Make Claims and Design by Scenario JOHN M. CARROLL and MARY BETH ROSSON IBM Watson Research Center

We are developing better

integrate

leverages

an “action activities

development

toward

using

broad

we are

there,

and

designed

artifact

schemas

detailing

wherefores projects

Categories

the underlying our

of the

els

General;

Principles]:

about

and

where

by that

rationale.

we

concepts

go from artifact

These

paper,

(HCI),

at design.

to support

there.

back

called from

to

a shift

process,

We

and more

sch emas,

stand

seeking

The approach

we are in a design

we might

supported this

interaction dwected

methods

where

In

and

why

represent

finely

a

by causal

datms,

several

unpack empirical

practices.

D.2.

D.2.2

with

those

to reify

psychological

Descriptors:

with

HCI

scenarios

commitments

Subject

to human-computer

rationaIe

scenarios.

tools;

man

design

reasoning

tions—methodologies: and

of current

explicit

to guide

whys

clarify

and

practices and

approach

at understanding

as the set of user

and to

science”

directed

[Software

1

[Software

Engineering]:

Engineering]:

H. 1.2 [Models

and

Requirements/Specifics-

Tools

Principles]:

and Techniques: User/Machine

H. 1.0 [ModSystems—lcu

-

factors

General

Terms:

Additional

Design,

Key

Words

Documentation, and Phrases:

Human Design

Factors

rationale,

planning,

user

interfaces

1. INTRODUCTION Here

is a perplexing

self-consciously things raised

contrast.

explicit

In the world

as it possibly

of science,

everything

can be. In the world

of critical importance are never this to a principle of ineffability,

made explicit. claiming that

science,

lots of implicitly

detailed

design

work.

We wish

of design

so that

it can be used

more

deliberately,

as

many

Indeed, some have the most important human–computer detailed normal

worlk on things cannot be made explicit [34]. Design interaction (HCI) is a case in point: lots of scrupulously

understanding of the gap between science and practice to reify is to try to build science in the extant practice,

is made

of practice,

to develop

a proactive

in HCI. Our the practical

interrogated,

approach ontology improved,

and applied.

Authors’ 10598;

address: email:

Permission not made

IBM

Thomas

to copy without or distributed

Research

Center,

[email protected].

fee all or part

for direct

of the publication and its Association for Computing specific

J. Watson

[email protected],

of this

commercial

date appear, Machinery.

P.O. Box 704, Yorktown

Heights,

NY

the copies

are

corn.

material

is granted

advantage,

the ACM

provided copyright

and notice is given that copying To copy otherwise, or to republish,

that notice

and the title

is by permission of the requires a fee and/or

permission.

@ 1992 ACM

1046-8188/92/0400-0181 ACM

Transactions

$01.50 on Information

Systems,

Vol.

10, No.

2, Aprd

1992,

181-212

182

.

J. M. Carroll

1,1 Developing Our

project

M

B Rosson

an Action Science

has

two

scientific

domain

for

artifacts.

HCI

and

goals:

to contribute

and to contribute Our

to the

development

to the development

interest

is

to

make

of HCI

of design

progress

on

as a

methodology

these

two

goals

on our part. We propose viewing conjointly, that is, through the same activity action science, a science that produces HCI research as an “knowledge-in-implementation” [1, 71], and viewing HCI design practice as inquiry. In part, our commitment rests on critiques of the alternatives: the historically and

disappointing

tively,

we are

approach But

“normal

analytic-decomposition encouraged

by

to instructional

it must

be noted

that

have

impressive

recent

effect

was

good

our orienting

research

[ 14].

at creating

in an action

More

[8, 11]

construc-

an inquiry-based

science

commitments

they are at least implicit about HCI [21, 40, 41,

the

need

well

of learning

[9].

are not clearly

in an increasing propor74] and about computer

many

The

to have

However,

more

integration, of the physics

allowed

early

and

particularly

invention

177–182].

enough

as 1931.

better

science,

is the

[63, pp.

analogy to vacuum of the semiconductor

are

for

of action

example

and

understood as early

there

for HCI

design

success

grounded

though

examples

[52],

too closely the understanding tors,

created

A

pp. 317–319], transistor

HCI

broadly [25, 31]. basic science and technology development have generally impact [3, 39, 51]. The complexity of modern science

technology laboratories.

paradigm

for

modest

design

the standard view of HCI, tion of current discussion science more Historically, little mutual

science”

paradigm

work

the

one

in large

can

cite

industrial

transistor; of the

had and

see [35,

semiconductor

development

was hindered

of the

by pursuing

practical tubes and by an oversimplified effect. In “n” (or negative) semiconduc-

electrons

(negative-charge

carriers)

than

holes

(positive-charge carriers); whereas in “p” (positive) semiconductors, the nlajority carriers are holes, and the minority carriers are electrons. However, the practical understanding tended to see n semiconductors as simply negative and p semiconductors

as simply

positive.

In the late 1940s, Bell Labs significantly stepped up work on semiconductors, including the establishment of a small group directed at building a semiconductor dependencies ing various Discrepancies prototypes. carrier

amplifier:

a practical

goal,

but

one

with

significant

science

and opportunities. The work of this group consisted of embodyhypothesized mechanisms in prototype solid-state amplifiers. in predicted performance were grist for further hypotheses and The

current

project flow

is

culminated a

major

in

effect

(1)

in

the

recognition

semiconductor

devices

that

minorityand

(2)

the

discovery of the transistor effect (minority flow induced by one point contact back through another). It is moot, of course, whether a richer practical understanding of semiconductors, one that kept in view the dual nature of semiconductor current flow, might have allowed the development of the transistor in the early 1930s. But it is clear that technology development can be obstructed practical understandings. Our work seeks to promote balanced ACM

Transactions

on

Information

Sysi,ems,

Vol

10,

No,

2, Aprd

1992

by incomplete design analy-

.

183

flow)

are

Getting Around the Task-Artifact Cycle sis so that important not overlooked.

factors

(the

HCI

analogs

of minority-current

1.2 Status Our task-artifact researchers and

framework designers

ontology

of HCI.

Specifically,

artifacts scriptions

in a concrete as scientific

also as design

seeks to enrich the concepts-in-action explicit the work with by rendering we construct

explicit

descriptions

that HCI underlying of tasks

and

and psychology-laden vocabulary. We use these analyses, that is, for explanation and abstraction,

rationale—this

is the sense in which

we are building

debut

an action

science. use-scenarios: Our approach to task analysis enumerates critical and typical the things users characteristically want to do and need to do, as well as the momentous events of user interaction (breakthrough insights and errors). All task analysis schemes do this in some sense; however, ours seeks to identify a

“basic” task level [59]; we are concerned construe their work to themselves: the level

with tasks at the level people at which tasks become meaning-

ful to the people

Many

task

unit

task

much

lower

who engage

level

inventory

of basic

Moreover,

building

pragmatic.

in them.

than

this

tasks

is the best

such

(e.g.,

the

design

tasks

schemes

of [ 6]).

We

representation

a representation

A set of basic

analysis

has

a good

of an artifact

uniqulely

are obligatory

focus on a

believe

[ 15].

empowering

prerequisites

design

for constructing

task-oriented instruction and other user support (e.g., [9]) and usability evaluation instruments [18, 58]. Such a representation makes it more feasible to convey the design to users—both within the design process [21] and subsequently. In our approach, an inventory of basic tasks, also serves as the fundamental rubric for our approach to artifact analysis. Designed interpreted their

users

artifacts (hardware, software, applications, as theories and as embodying myriad specific and the circumstances

manual

can

be seen

learners

know,

what

of their

as embodying they

do, what

use. For example,

a range they

interfaces) propositions

a self-instruction

of assertions

experience,

about

can be about

about

what

the nature

the of the

learning tasks and the contexts within which these tasks are carried out, etc. This view often surfaces in “design memoirs” (e.g., [66]), which can play a proactive role in organizing on particular issues. However,

such

memoirs

subsequent casually

design

confound

efforts

by focusing

designer

intention

attention (which

may

or may not characterize the realized artifact) and design analysis (in which assertions are systematically grounded in general laws of psychology, specific user

data,

rationale

or

other

rationale).

In

of an artifact-in-use

claims) relating properties of quences, under the scope of a including open-ended exercises by-exploration for situations projects might be appropriate

ACM

our

approach,

is articulated

thle

in causal

psychological

schemas

design

(which

we call

the artifact with specific psychological consebasic task usage situation. Thus, for example, in an instruction manual supports learningin which the learner wonders what sorts of to work on.

Transactions

on Information

Sysl,ems,

Vol.

10, No.

2, April

1992.

184

.

J. M. Carroll

Such a “claim” intended

to

artifact

in

vis-a-vis

do

might it.

virtue

the

artifact

and

use

is

The

in

or proscribed)

claim and

use

is

can

be

(in

by building

relevance

and

sense

artifacts,

in turn

true

of the

of the

claim

accounts

of artifacts

designers in

(Figure

their

1) in

level

of basic

which

truth

of

that

embody

less

independent and

chance

they cycle

the

nor

investigated

the

schemas

the designer

because

more

descriptions

a task-artifact

requirements

neither

the

improve

causal

by a manual

is

constructing to

the

of HCI

to user

its

intended

manage

ontology

the

intention,

and

objective

respond

have been enabled

of this

Our

their

M. B. Rosson

However,

intention. deliberately

and

will

more

work. which

tasks

present

mere

designers

to be enabled

or deny

possibili-

ties to their users. On the one hand, we seek to support a more thorough and deliberate enumeration and assessment of the basic tasks (versus designing to an overly narrow or plainly mistaken set of use-scenarios) and on the other hand to support a more thorough and deliberate enumeration and assessment

of claim

undesirable

schemas

implicit

psychological

in the design

consequences

(versus

creating

unintended

and

for users).

Our approach is similar to contextualist [73], participatory design [21], situated action [67] approaches in that we conceive computer systems applications to be rich and dynamic contexts for user activity. However,

and and we

are more design.

for understanding

and

efficiency-oriented

ap-

concerned

Conversely, proaches different

developing

approach

is

analytic

similar

(e.g., [6]) in its concern in taking the broader-scope

ence. Our science

our

with

approach

differs

commitment,

to

models modern

with analytic perspective

somewhat

from

in integrating

the

models and methods, but on user activity and experi-

all these

approaches

development

of HCI

in its action as a domain

of

study with its development as a domain of design practice. We have had reasonable initial success at applying this framework to a variety of problems. A scenario-based claims analysis of the Displaywriter [17] was shown to reproduce the design arguments underlying Wheels Interface. The methodology guided the development Matcher applied

programming the methodology

environment

[60],

environments to the design

and an intelligent

models

as “second-order

models

as well

building

[18].

artifacts”

as to exemplars,

the Training of two View

for Smalltalk [16]. Subsequent [4], a software of a task browser tutoring

system

[12] can direct and thus

unify

[65].

Prescriptive

credit-blame design

work design design

attributions

evaluation

to

and model

1.3 Overview The balance

of this

paper

attempts

to operationalize

the task-artifact

frame-

work. It is both more and less than an instruction manual because we may not yet know how best to do what we seek to do, and as a result we may raise many methodological and conceptual issues (perhaps both wittingly and unwittingly). The initial discussion in Sections 2 and 3 draws on the Displaywriter and Smalltalk case studies mentioned above; in Section 4 we sketch a more complete example of the whole process, couched for the design of an instructional manual (which is a less technically demanding design domain ACM

TransactIons

on

Information

Systems,

VOI

10,

No.

2, April

1992

Getting

Around

the Task-Artifact

Cycle

.

185

requirements

tasks

artifacts

possibilities Fig.

than

Smalltalk

bounds

programming

The task-artifact

environments

cycle.

and

broadens

the

application

of the methodology).

2. GENERATING Whether we begin

SCENARIOS

analyzing an existent artifact or envisioning an artifact in design, by generating a set of basic-level task scenarios. Each scenario is a

description in while

1.

(in text, pursuing

representation

in a storyboard, a particular

etc.) of the activities

concern.

of the use to which

A set of these

the artifact

complex system, the scenario representation is an infinity of possible use-scenarios). Yet

will

a user might scenarios

be put.

engage

is a concrete

For any reasonably

is necessarily incomplete (there even though it may be heuristic

at best, the analyst and the designer need to have a scenario good coverage of the possible use-scenarios.

set that

provides

2.1 The Empirical Approach One obvious

method

is to collect

scenarios

empirically.

Of course,

observing

people or asking them what they do often confounds predictions made on purely analytic grounds. A learner we studied, who was following an exercise to type and edit a lease, made horrendous errors, but continued somehow on the grounds that, proper lease ought

not being a lawyer herself, she could not judge what a to look like [47]. We might have projected the scenario in

which she made the errors, but we could never have anticipated the creativity she brought to bear in seeing an obvious and ugly editing disaster as a lease. The problem with purely empirical approaches is two-fold, however. First, they are not merely rich; they are too rich. They generate unmanageably huge scenario sets with no internal structure, no principle for classifying or ACM Transactions on Information Systems,~01. 10, No. 2, April 1992

186

.

J. M. Carroll

grouping

scenario

project

for

scenarios used

problems

2,2 The Analytic An analytic kinds

have

design

of

an earlier

subsequent

versions

saving

slate.

and

levels.

of a complementary

are

empirical

redesign,

version

each

they

to collect

is really

system

effort;

Second,

a system

work

for

importance

and

or level

Nevertheless,

analytical

the

can

be

both

approach

to

Approach

approach

collected

already

fact

means a blank

sets.

of scenarios

cally

no with

Often,

the for

to the

scenario

must

system.

after guides

point

developing

provide starts

One

the

collected

as a priori

They

development

a posteriori.

use-scenarios

M. B. Rosson

tokens.

of scenario

necessarily

and

to generating

there

are.

scenarios,

scenarios

These

but

types

would

could

also to generate

start

with

be used

scenarios.

a theory

of the

to organize

Of course,

empiri-

a theory

of

scenarios might not classify all empirically obtained scenarios; it might fail to be useful both for predict even the majority of obtained scenarios, but still generating for

scenarios

providing We

have

design

and

built

typically

because

concern. type

For

and

number the many

is

of

musical the

we

word

designing

was

pervasive

user as they

user

if we

are

restrict

the

the

processing can

the

and

various

differences,

but

of

our

basic-level when

people

similar,

it

same

is

underlying

system

may

spawn

a staggering

to those

measured, to

Indeed,

pursuing

concern

and

several that

essentially

attention

akin

appreciate

concerns.

are

This

converging to recognize

being

of a word

a thoughtful,

musical

processor

pieces,

levels learners

learners they)

extant

to

at multiple

concern

by

step

approach

scenarios.

want

scenarios error-free

ways we

of

are

in

to

which

effort.

But

performing

overwhelmed

a by

[26].

similar

classified

can

first

empirical among

use-scenarios

document.

even

a purely

relations

themselves

new

differences

similarities

(think

the

to mount

these piece.

Also

for

able

the

activities

a simple

of scenarios,

user

to

in varying

example,

print

of The

around

activities

than

into

projects.

cluster their

efficiently

insight

a typology

analysis

use-scenarios construe

more

systematic

have

already

psychological

can

with

a word design

have

be seen

the

that

scenarios

type

and

as instantiating how

These

to

for

can

example,

(e.g., [17])

to new

be

can

print

an even

accomplish

abstractions

processor,

rationales

found

Thus,

determining

understand.

or analyzing

we

of abstraction.

be

concern

more

general

goals

that

very

useful.

one can closely cases; many

they

In link

aspects

of the type-and-print concern are invariant across word processors. More broadly still, one can link analyses and design argumentation generated for how-to-do-it scenarios even across application types (for example, between learning the Displaywriter and learning Smalltalk [ 16]). In Figure 2, we have listed and exemplified six of the most general user concerns from two of our design and analysis projects. The Displaywriter is a word processor with a hierarchical menu-based interface; we developed a training tended

wheels to attract

interface learner

overlay that blocked the advanced functions that errors [ 17]. Smalltalk is an object-oriented language

and environment—programming specialization of a rich library ACM

TransactIons

on

Information

Systems,

in Smalltalk of classes (object Vol.

10,

No,

2, Aprd

consists of the reuse and types). We developed a tool 1992

Getting Around the Task-Arllfact Cycle

orienting

to

zppropriatc

.

I)lsplaywrltcr,

e

,Smdlltdlli

187

.

goals

how

cm

wh

reuse

help

tt]is

([a rwr

me write

a Iettcr

can conlrit!we

to illorng

10 m.b>cola}- vzlxin,q

upplicu[i(m? intmxting .

with

Ilsplayw

I{cwsc ●

reuse

under

*

t)lsplaywritcr

.

Smd]k+lk iindmg

seeking

mnsidering

jkdmg

how -to-do-it

●

Smalltdk scttmg

of the Sh&r

jiv

,wgr

for a Ass

that

Imouse

cmIvcrsI{m

procdural typing

reuse

(u

class

rclatlvc

how-it-works

analng

alput,

method

prmtlng

a letter;

up J Sllder

formattmg

instance

a letter

to an application,

width

explanatory finding

[OJOU1 snnulatcf,

information

A

honking

a slldcr’s

I hspktywrit.r

●

m the (’rcate

rcuw

[k mrnu

looking

the Shder

llspl.lywritcr

scckiog

(Jl)l?[)rtunistically

an npt]on

a dcscriptiou

reuse,

●

*

choosing

menu

Smalltalk

searching

the cnviromnent

nter

infarmaticm

out

mfclrlng

the mlc

Smdltdk

reuse

tindIag

reuse

dmxdmg

~vhy noth,ng

of dcf:iult

settrags

out

why

has hccn

prmtd

yet;

in menus

the slider

shows

the wrong

SAC

posltlon

.

Smdkdk \vt]at

Fig.

2.

A typology

learning after

of user

the Displaywriter

developing

the spccd!mtlon

concerns.

The

and re-using

to whclass shoultl

Sllder,

Jctcrnunlng

pmvlJc

example

Smalltalk

concerns

classes;

come

from

the italicized

our

task

concerns

analyses

were

of

generated

the typology.

(the Reuse View Matcher) that presented multiple exemplary application using a target class, allowing concretely a typical usage situation The first user concern in Figure

[161. 2 is: orienting

coordinated a programmer

views of an to explore

to appropriate

goals.

The

new user of a word processor may know something about the functional capability of such systems, enough to have wanted to switch it on, but may still wonder how the device can help in pursuing document preparation goals, such the

as writing black-box

specific

classes

a letter. reuse

Analogously, paradigm

can

play

the

(e.g., a

Smalltalk

[20]),

role

in

programmer

but

still

the

must

understands determine

particular

project

what under

development. Users with do

the and

pursue

a variety

system

environment,

exploring

the

of

such

concerns.

wondering

consequences

what

They the

of various

interact objects

possible

opportunistically they

for things, text-processing functions they imagine might classes and behaviors they think they might need. They ACM

Transactions

on Information

Systems,

encounter

can

They search exist, Smalltalk wonder how to

actions.

Vol.

10, No.

2, April

1992.

188

.

J, M, Carroll

accomplish

procedural

slider

to

they

notice;

queue,

a color

whether

and

Even

such

after

how

ones

we

some

extent,

and

track

queue

an

not

consider

we

can

And

to streamline

or job

171. We

understand

why

in the

they

can

word

reflect

up

a

processor

on the

processing

find

use

concerns

generated

these

hook

relationships

design task

or

class.

user

raises

to

and

a word

typology italicized

how

events

Smalltalk

[16,

for code reuse

for

of a print

coarse-grained The

a letter,

works.

existing

candidates.

concern

format

how

to specialize

a simple

did

losing the

considering

of scenario

To

explanations

how

activity,

The “orienting”

to

seek

wonder

generator that

how

They

example,

may

own

M. B. Rosson

goals,

mixer.

for

they

of their

and

them

may

as a heuristic in Figure

from

have

a particularly

the

been

2 are

typology.

overlooked.

ill-defined

version

of the classic “aboutness” question; it is a critical concern, but it is not clear how to address it; and it is particularly unclear how to address it within an example-based analysis system like the Reuse View Matcher, Similarly, it is easy to imagine a word processor user with the “search” concern, but the Training Wheels design, may implicitly discourage cases it seems

that

which hinges on rendering a designer from attending

early

design

commitments

sis or to state blocking) can obscure user concerns. It is not surprising that a designer’s as the View

Matcher

functions nonexecutable, to that concern. In these

(e.g., to example-based

or preempt extant

or to an instructional

consideration

commitments,

approach

analy-

of plausible to a genre

such as training

such

wheels,

can create a sort of “scenario Payne). Clearly, any designer

bias” (a term used by Kevin Singley and Steve will have incomplete and skewed knowledge of

the usage

the design

of bias.

situations None

background recognized. routine

to which

of this

is a particular

work

is targeted;

problem

for

HCI

this

is also a source

design;

it

is in

the

of all design. However, such biases can operate without being A common example is the tendency to consider only scenarios of

and

expert

errorless

performance,

overlooking

the

pervasiveness

of

user scenarios incorporating slips, mistakes, and confusions [111. Such biases can be mitigated by enumerating paradigmatic types of cases to help ensure that a rich set of possibilities are generated for any particular situation—increasing the chance that typical, critical, and appropriate ones will be in that set. Figure

3 illustrates

a scenario

elaboration

of one of the

ated in the typology of Figure 2; we have built a story experience of changing an option in the Displaywriter’s

concerns describing Create

enumera user’s or Revise

menu. The learner responds to the “item” prompt opportunistically, trying out the functionality offered, setting and changing a menu option, and perhaps learning something through the interaction, before moving on. An important use of the typology is to pursue hypothetical “what could go wrong?” lines of reasoning. That is, in addition to detailing how the various user concerns of the typology can be instantiated or satisfied, we also detail how they can go awry. Thus, the Displaywriter can, under certain

opportunistic conditions,

interaction scenario become self-sustaining,

result in an option loop error ([9, pp. 29] and Figure 4). This use of the typology emphasizes generating error scenarios, ACM Transact,.ns on Information

Systems,

Vol.

10,

No.

2, Aprd

1992

for the and

complementary though it still

Getting Around the Task-Artifact Cycle The

learner

options) Fmtcr

IS on the Create

to be specfled.

or Revl,se menu

‘There

“; aad aa uuhighlighted

The

learner

item

and pressing

voices

aa mtcrest Enter.

which

is a highlighted prompt

“When

in scemg

what

A further

menu

oITers various

prompt

“Type

fmlshed “ltcms”

with

ID this

are hkc

is displayed,

“items”

(format

letter

to choose

]menu,

typing

listing

press

the

various

and

storage

Item;

Pnter,

ID

letter

“choices,”

with

189

.

press

” of a menu a prompt

“Type your chmce, press Enter “ The “choices” are parameter values for the items, for example wuiuus state

formats

presses

Fig,

3.

option

Enter

the

user

specifies

original

to proceed

Interacting choice

The

(I c,, with

with

a choice,

highhghted

to the Typing

the

and

aad Area

environment

the

menu

and

unhighhghted (the

next

prompt

prompts

system

revert

to the

mltml

The

learner

dnplayed)

state)

opportunistically,

as exemphfied

in

Displaywriter

scenario.

The leaner is on the Create or Revise options)

to be specdied.

Enter.”

The

displayed,

learner

hstmg

types

“choices”

are yaramctcr aud the menu ID

The

learner

them

back

out,

letter

specfles

Comment:

The fmtshed

for

Item; and

leaner

learner

the items, revert

for

various “Type

item

aad

example

“items”

(format

letter

to choose

ID presses

Type

to the mitxd

your

various

Entcn

item,

a further

choice,

press

formats,

state (i.e., w]th

aad storage

The

press

menu

Enter user

is

“ The specdies

the hlghh~ted

prompt,

Imter”).

choices

over

and

seem press

over,

fmstration

in hcr original

not

menu,

offers

prompt:

a prompt.

expresses

does

this

which

of a menu

with

press

she has failed

with

letter

prompt

ltcms

The

and feels that

“When

values

to choose

again,

ID

“choices,”

md

menu

is a higbl@ted

the

various

a choice “Type

There

to

goal

“see”

Enter,

changing

opt]oas

aad helplessness, of typing

the

emt

” (that

(on

Eater

the

then

chaaging

to

see a way

secm

ancl printing

prompt

is, press

and

can’t

a letter, screen

withou[

having

all the time), specified

an

item),

Fig. error

4.

Interacting

with

the

envmmment

(for

instance,

opportunistically,

as exemplified

in the

option

loop

scenario.

undergenerates

it might

not

generate

error

off-path such as the mutilated-lease scenario). We are not attempting to make scenario generation typology to develop scenarios always requires detailed

scenarios

automatic.

information

very

far

Using the andior

assumptions about the user’s prior knowledge and the contexts and situations in which the scenarios might arise. Indeed, the most important user concerns for a given design project might well be the ones that do not instantiate

any

heuristic

theory

understanding

2.3

of the of of the

Scenario-Based

At some point,

concerns

scenarios user’s

in

our

and

as

activity

one has to stop just

observed are ones that might set the threshold scenarios analytically, in whatever

and

We for

see the

typology

systematically

only

reifying

as a one’s

experience.

Design

with efforts, and do something scenarios empirically, one might

scenario

typology. a tool

generating

them. decide

scenarios,

or at least

diversify

To the extent that one is generating to stop when half of the use-scenarios

have been seen before (to be more conservative, one at three-quarters). To the extent one is generating the stopping rule might be that every category of typology ACM

or theory Transactions

is being

on Information

used

has

Systems,

Vol.

been

concretely

10, No.

2, April

1992.

190

J. M. Carroll

.

The

learner

options) Emter at the

Fig.

5.

option

and

is on the

Create

to be specified “ The

learner

bottom

or Revm

the

the

After

Enter

to the Typing

Interacting choice

with

ID

screen,

Ehsplajwriter”, to proceed

menu

which

‘1‘here N a lughhghted

types

of

M. B. Rosson

tg mg

the

letter

of a menu

‘Change sm cral

environment

next

and

Format

items,

(the

varmus “Type

Item

Aftcmatc

other

Area

offers

prompt

with

system

“items”

(format

letter

to choose

ID

presses

Enter,

is not

analogous

and

storage

item;

a message

available effects,

on the

the

press

appears Training

learner

presses

state)

opportunistically,

as exemplified

in Training

Wheels

scenario.

instantiated

(again,

to be more

conservative,

one might

generating three exemplars of each type). Each scenario should be detailed and developed

decide

to capture

to stop

after

and explore

the

finer structure of the operative psychology in the situations of use one has projected and\or observed. Thus, the scenarios in Figures 3 and 4 have been developed beyond merely This detailing captures qualities

of experience

enumerating more about that

inhere

the option choice concern of Figure 2. the knowledge, goals, reactions, and

in the

scenario.

The

scenario does not seem to appreciate the optionality is treated as a directive (i.e., you must or should of the

actions

that

are not relevant nonrelevant. Such detailed Displaywriter

interface

generated created.

before

have

even

of the

in

Figure

the

3 and 5 in

important the

in the

choice

in

Figure

designing

property

situation

as being use.

4 helped

us

the that

they

in

Training

they

describe

can

has

be

been

Thus, one might have created a narrative theory of the Displaywriter it was built, working with story boards, or story board software. If one

had had the scenario

typology

of Figare

2, one might

for the choosing-an-option-in-the-Create-or-Revise-menu one ing what could go wrong in such a scenario,

have

ios

4. option loop error scenario in Figure can be the We believe that use-scenarios

might

principal

generated

design

representation

artifact [15] and have used them in the design of various tools scenario talk programming (see also [16] and [60]). The example generated

6 was the

before

scenario

was

we

ever

a key

implemented

element

in

the

the design

scenar-

concern; by askhave generated the

an

[621;

error

concern

learner

of the artifact

theory

as Figure

before

option

are seen by the

a narratiue

such

Scenarios

developed

and

as those

scenarios

[9].

and

elaboration goal

constitute such

alternative

the

learner’s

scenarios scenarios

to envision Wheels

comprise

to the

learner

of the original prompt; it type an ID letter). Most

Reuse

View

specification

of

for Smallin Figure Matcher for

that

implementation.

3. CONSTRUCTING

CLAIMS

The set of scenarios that a designed artifact affords (and inflicts upon) its users entrains a set of specific empirical claims enabled by the artifact: claims that the user will attempt and can achieve a given scenario and claims about the psychological consequences of pursuing the scenario. We may ACM

TransactIons

on

Information

Systems,

Vol.

10,

No.

2, April

1992.

Getting Around the Task-Artifact Cycle

191

.

A rmwammer sws Shclcr in the class hierarchy, aad the name sounds Me it nnght be useful to the current pm]cct, a CO1O1 -mixing application l’he programmer opens a View hlatcher on it, and

6.

player

charactcnstic,

(from

design basic

this

letter.

sltu~tion

We

may

steps

use, The

supported

design

extent

has

do this

situations

provide The

We

earlier

scenarios

such

to type

sliders

as the

and

print

a

scenarios,

coordinate

for

events

characterizes

the

tasks

facilitates

and

design

one

in

the of and was

a represen-

to facilitate can

wodd

not

was

have

implicit

from

succeeded a particular

discovering

the

devices.

right The

psychology

systematically

design

generalize

to produce

of solid-state

the

more

scope

scenario

provide

that how

success

of making

that

wants

group

discovered

class

it

why

seen arios

abstractions,

merely

“In

this

of is

causal

scenario

Thus,

of the

ab-

analog

embodied

explicit

than

it

in is in

in

the

the

scenarios

“items”

the

events,

Where

to user’s

and

the

user’s

provide

that might

of Figure seqpence

inhere

this

3 and

(relative

to of

understanding

the

scenarios

what

prompt

contributing to

relationships

context,

4, we

the

the

in

the

events,

subsequent

recollection

a

account,

narrative

can

unhigh-

events

of

in

feature

the and claims

account. enumerated

analysis

chological

the

designl.

perspective,

artifact

broadly

events.

claims

of the and

in Figure

Displaywriter

consequence

highlighting,

The the

fine-g-rained

ask,

prompt) more

a causal five

HCI

how

artifact.

greatest

articulating

experience these

to

basic-level

altering

a broad

highlighting

and

of

in

manual

fails

show

transistor had

contribute?”

“exit”

user’s use

exemplified

of use-scenarios. by

the

scenario,

of the

recognizes

what-could-go-wrong

of

relevant

objective an

the

learner

science to

The

the

artifact

what

lighted

as

use-scenarios

and

Their

of use.

of the

the

by the

if they

of using

an enumeration

ask

demo

used to mmipul~tc

“1 he programmer

how-to-do-it

scenario

understanding

been

situations We

measures

to follow

inventory

action

amplifier. for

the

appeal

projects.

same

us

an

can

support

associated

of each

exploring

from

solid-state for

A short

alc being

opportunistically,

critical

supported for

that

straction

succcss

program

sliders

manual. and

i.e.,

or not

However,

prior

player

to

which

the

details

medium

to the

andysls

sccs that

needs of the color-nuxcr,

wishes the

in

in

typical

artifact’s

obstructs.

analysis

player

environment

to this

scenario

with

tation

the

several to the

a learner

add

Enumerating an

predict simdar

manual

which

the

system

tlmt

with

a football

and the pmgrammcr

IS very

instruction in

example,

example,

[ 16]).

an one

first

IS shown,

Interacting

scenario

the

progr~m

that

Fig.

sckzts

football

of a system

display

feature

interaction)

the answer

7 comprise [17]: under

Each (the

hypothesizes tw,o

the

offered

in

a specific

prompts,

their

scope

of the

path

for

our psy-

relative

option

choice

concern. The

menu

manner

that

But (in

these italics).

prompts is

causal The

explicitly

consistent

with

relations

also

third

claim

in

define other

an menus

incorporate Figure

action in

the

potential

7 addresses

ACM TransactIons on Informatlm

the

learner

Displaywriter tradeoffs,

consequences

in

a

interface. or

downsides

of highlight-

Systems, Vol. 10, No, 2, Apr,l 1992

192

.

J. M. Carroll

1

stwdarcl

Itcm”

(but

may

urrr

l{ [nd[ro[er

~

the Item (bul

5

ing

the

not failure

to

type

options

the

II hard-r uw

to

the but

the

all

aspects

experience

of

the

activity

with

[ 16].

cretely. the

Making and

a claims

behavior.

and

momentous

how

the

progress specific

ACM

for

Transactxms

we

the

is

salient

option

intended

to

football

any

users

of

was

the (each

in the

ask action,

other

keep

what

type

attention

the

can in

provide

the

is

with

conveyed

example-based

often

overly

could

have

learn-

of

meaningful

an

application

directly

learning

narrow.

and

Interacting

a powerful

context

interacting

example

evaluation,

concern.

examples

are

that

obstacle

which

planning,

discovery

examples

more

possibility

p semiconductors

similarly

of

is

[17]).

consequence.

can

user’s

with

(from

rendered

the

a key

is

object

and claim

A downside

trouble

isolating

con-

is that specific

the

slider’s

example.

is an analytical

of candidate

whereas suggests

users to

and

The

a claims

users

fails

and

set is merely do,

that

involves

generating

empirical

analysis

source

of user

an inventory analysis

they

to support

that chief

is observation

a scenario that

process

claims.

of scenarios,

supports

their

do

of the

seeks

to

something

efforts,

get one

and

how

for

reports typical at just way it

or

signals

error. the

option

wording

convey

m

scenario

options

n and

schema

of the

things it

and

Thus,

6,

choice

carriers,

scenario

case

But

how

of the minority

guided

analysis

artifact

another,

option

less

particular

a set

as in the

and

that

Claims

evaluating

claims,

of

c@~Icd)

transistor

psychological

to

m

changing

the

claim

associated

the

3.1 Generating

unwr

functionality

from

in

for

paradigmatic

scenario

functionality

all

the the

induced reuse

This

offering

A downside

concepts to

In

feedback

considering-reuse-of-the-Slider-class

by

a slider,

.Ipproprialcncss

10 PXIL)

lb adequate

Dlsplaywriter

properties

Figure

contributing

opportunistically

assume

o, unwrr)

continuing

of rendering

includes

of the

of

is

using

rcv[usrd

the

OK

me

of

cost that

the

also

scenario

do

possibility

carrier).

situation

t}wzi I( u alw

jor users

at the

application

ing

\uggcsts

RCVMC menu

in the

Recall

appreciate

on all

In

prompt

or

embodied

options.

focussed

(;rmtc

jicdbork

claims

user,

majority

itcm

to rrcognlzr the

nof bc cmugh

prompt:

the

the

may

]s successful

of semiconductor

are

[If

and

duT ~[[ua(wn)

we

attempt

changing

1/11s lcchnlquomrdting

conlmucd

4

and

and

of the

crucial on

change

meanings Information

scenarios,

prompts, to Systems,

the the Vol

the

deployment

immediate user, 10,

and No

effects together

2, April

199’2

of highlighting, of given these

can

user

the actions

conspire

to

Getting Around the Task-Artifact Cycle cause

the

scenarios

descriptions

of Figure

of what

3 and

can happen

Figure

4. The

to the user,

scenarios

193

.

are integrated

and as such they

are important

pieces of information for understanding the Display writer and, of course, for of the redesigning it. A claims analysis goes further; it offers an explanation scenarios,

an analysis

We use the claims

of why

schematic

analysis

the scenarios

structure

is an analysis

can occur.

exemplified

in Figure

7 to stress

that

a

of tradeoffs:

(artifact feature or technique) CAUSES (desirable psychological consequence) consequence ).1 BUT MAY ALSO CAUSE (undesirable psychological We want to transcend both the uncritical advocacy of design memoirs and the unsympathetic negativity often associated with human factors evaluations. Similar to Rittel [57], we assume that the key issues pertaining to a design will

involve

for

an

the

cation

positive

artifact

provides

arguments

both

juxtaposes

feature

a medium and

Error

with

for

usability

for

and

arguments

against.

or

its

associated

combining

the

Because

desirable

a claims

psychological

qualifications

traditional

or

strengths

analysis

consequences downsides,

of designer

it

justifi-

evaluation.

scenarios

such

as

Figure

4

seem

to

be

particularly

good

claim

in some misconception or unfortunate sequence of actions, one naturally asks “Why?” In the option choice scenario, one might say that the user was misled by the highlighting. But to stop there would misgauge the role of the highlighting (e.g., in generators.

When

conveying

sees

to the user

prominence

identify

the

of downside

and could lead unique causes; might

one

another

snarled

possibility

of altering

consequences

in error

to thrashing. if we make

a downside,

person

multiple

options).

scenarios

Thus,

can be a sort

In complex situations there frequently a directly remedial design change each

we will

often

have been less prominent

undermine

(at least,

desirable

perhaps,

until

the

of bias are not time we

consequences

that

we have ill advisedly

disturbed them). Of course, we should exploit the strikingness of error scenarios in helping to call attention to causal relations, but we also need to avoid focussing too narrowly on only certain causal relations in a complex situation. The claim schema, by balancing the desired and undesired entailments of an artifact feature,

supports

analysis

just

lNota

bene

that

presentations artifact the

this.

More

by generating

this

(e.g.,

features

schema [16]),

generally,

is to be interpreted

we have

and techniques,

which

environment

opportunistically,

demos

new users

offers

little

learn

situation

the

word

the focus

of a claims

but

the

scope

of a use-scenario.

descrl ption perhaps

clearer.

into

the

In some

identification

For a 1earner

of

exploring

we hypothesized: by doing

for the user to do)

(but the demos may not be paradigmatic ( but learners may have difficulty finding Striking

situation

is redundant

exploring (but

as under

incorporated

Smalltalk

helps

we can broaden

of claims.

lots

“exploring”

fits

the

claim

application nlodels ~ the corresponding code) schema

better

and

is less

redundant

vis-a-vis

the

of use. ACM

Transactions

on Information

Systems,

Vol. 10, No. 2, Aprd

1992.

194

.

J. M. Carroll

Figure

8 lists

scenarios.

and

M. B. Rosson

questions

We built

this

one list

can

ask

to generate

by considering

claims

Norman’s

stage

from

observed

theory

of action

[55]. For each stage, we imagined the general kinds of psychological consequences an artifact might have, translating those possible consequences into questions that one might ask about the artifact. The question list can be used similarly to the user concern typology in Figure 2; that is, for a given artifact, one can try to instantiate one or more claims from each question in the figure. For example, the first question under “Goals” in Figure 8 directs our attention

to how

claim

the artifact

4 of Figure

our attention can generate

suggests

7; the first

a possible

question

goal

under

to how the artifact conveys claim 5 in Figure 7.

Generating

claims

directly

from

of claims

our work, scenarios,

we frequently refer to earlier artifact features, even types

with particular of this method:

analyses,

completion

scenarios

literature

there

and in that

“Evaluation”

sense generates

in Figure of a task

is demanding.

is a supplementary

8 directs

and

thereby

However, method:

given

analogy.

a In

analyses for suggestions. Particular of applications tend to be associated

claims. One has to be careful we may be unusually narrow

about overestimating the utility designers (it seems that almost

everything we design involves example-based not be so atypical. At the least, the possibility

learning). But then this might of creating apt analogies from

one claims analysis

analysis

to another

can cumulate

A stopping the relation

heuristic of claims

indicates

that

this

kind

of description

and

and generalize. for claims

generation

to scenarios.

A claims

is suggested analysis

by Figure

has attained

8 and by reasonable

completeness when it provides some causal account for each critical and typical scenario. One can use Figure 8 to ask whether a given causal account covers every relevant stage of action in a scenario; in fact, one can do this by just posing each of the questions listed in Figure 8. This heuristic will typically

lead to a large

set of claims,

but the claims

by ranking scenarios with respect to criticality ranking individual claims within each scenario

might

be prioritized,

first

and frequency, and then according to the importance

by of

their user consequences to the given scenario (e.g., weighting consequences involving high-level goals more heavily than those involving low-level goals). 3.2

Justifying

Claims

In problem solving, generation is the hardest stage. However, once one generates a set of claims, the next step is to justify them. Because our concern is to develop an action science approach to HCI, we have focussed on justification by deductive linking to scientific principles. For the most part we have limited our consideration to psychology, though clearly other sciences are relevant for less than than

most,

(economics, sociology, real deduction; basic often

leaves

boundary

physics). Moreover, we must often settle science, and psychology perhaps more so conditions

inadequately

specified.

This

is

the conundrum of getting from the laboratory to the real world; the only general solution for it is a theory of the world. Our framework bounds the theory-of-the-world problem: we depend on basic science only for justification of claim consequences. In cases for which ACM

TransactIons

on

Information

Systems,

Vol.

10,

No,

2, April

1992

Getting

Around

the Task-Artifact

Cycle

.

195

goals ●

How

does the artifact

evoke

.

IIOW

does the artifact

encourage

goals

in the user? users to impoti

pre-existing

task

goalso

intention ●

HOW does sunple

.

What

speciticat .

●

suggest

that

a particular

basic

or advanced?

inappropriate

goals

are most

task

risky

hkely?

goal

1s appropriate

or inappropnate?

or safe?

most

costly?

ion

What

*

the artfact

or dficult?

distinctions

must

how

sre these

distinctions

What

plznning

mistakes

How

does the artifact

skills)

m pknmmg

bc understood

in order

conveyed

by the artifact?

are most encourage

hkelyy

to decompose

most

a task

goal

into

methods?

costly?

the use of background

knowledge

(concepts,

metaphors,

a task7

execution .

I Iow

●

Whatslips

●

EIOW does the srtfact

does the tiifact

make

are most

it easy m dtilcult

likely?

most

mdlcate

to perform

a taslk7

costly’J

progress

m task

performance?

perception .

What

are the

most

mhent

features

of the

atifact?

what

do these

features

communicate

to the user7 ●

What

features

●

What

features

communicate

are connnoxdy of

the

missed

artifact

and at what

change

as users

cost?

carry

out

a task?

what

do

these

changes

to the user?

interpretation .

How

does the artifact

●

What

incorrect

●

I Iow

guide

inferences

the user to make

are most

does the tiifact

encourage

likely?

correct

most

inferences?

costlyv

the use of background

knowledge

in making

inferences?

evaluation

Fig,

8.

.

How

does the artiact

convey

●

How

does the artifact

help

s

How

does the afiifact

encourage

Questions

to

ask

in

completion

of a task?

users to recognize,

generating

elaboration

claims,

diagnose

and recover

and retrieval

of tw,k

organized

by

from

goals

Norman’s

emurs? and methods?

seven

stages

of

action

[55].

there is no relevant tific, argumentation

science, our approach converges with deliberately we are approaches (e.g., [19]). In other words,

ascienworking

toward grounding claims in science, but if the science lets us down in the end, we still have the claims; and our design arguments still proceed (justified in this case only within the design context itself and by the utility of the design result). We also hope that by linking scientific justification to a design argument, we can improve the relevance of the science itself. Simon [64] suggests that psychology is a science of adaptation to artificial circumstances. Thus HCI is a good

venue

for

basic

psychology. ACM

TransactIons

The

justification

on Information

Systems,

we Vol.

build 10, No.

for 2, April

claim 1992.

196

.

J

M. Carroll

and

M. B. Rosson

even if we fail to import anything of value from official consequences, academic sources of psychology, is psychological analysis nonetheless. If it proves eventually to be both useful and abstract at all, it is psychological science. In other words, we can try to give some science Finally, whether or not we are in the position of linking

back to psychology. psychology to claim

consequences, we believe it is important not to give up linkage. If we do this, we are surely on the slippery slope with

little

common

to ground sense,

our

and,

descriptions

at length,

the

of a design

empirical

but

the possibility of of design memoir

our

bottom-line

intentions,

of a design

We might not be able to do better than this, but we ought to try. Much psychological theory can be adduced to back up the claims ure 7. For example, developed

in Esper’s

Thorndike’s persons

the advantages

[70]

[22]

work

work

of structural on artificial

on common

in low-power

roles

consistency languages

elements

to take

of Fig-

in learning

(see also

(see also [36]),

suggestions

our result.

as directions,

The

[7])

were and

in

tendency

of

the downside

of

the second claim in Figure 7, is also a fairly broad and basic finding [32, 49]. The tendency for the relative salience of one entity in a perceptual field to undermine the salience of others (claim 4) is developed in Gestalt theories of figare/Wound organization [38] and in more modern theories of attentional limits

[37].

ending

Finally,

the

of a sequence

Claims

parsing

(claim

are not justified

use situations

they

problems

5) are very in isolation,

describe.

associated

general either

Besides

linking

with

determining

the

[29]. from

one another

consequences

nomena, we seek to “interrogate” the claims themselves. we use is to deny the causal consequence and reason

or from

to abstract

One rule from this

the phe-

of thumb toward a

“contradiction.” This is a logically degenerate form of reductio ad absurdum. The highlighting claim in Figure 7, for example, can be denied as “highlighting the item prompt makes the possibility of changing options less salient.” This seems overwhelmingly implausible, and hence encourages some coni-3dence

that

based-learning consequent use do not truly

the

original claim

(undenied)

claim

would yield the new claim: support the analysis of its

paradigmatic

was

right.

of the what-do-sliders-do?

usage

obj ect’s functionality. As with any heuristic,

example

that

one must

Or,

scenario.

“paradigmatic functionality.” fails

about

the

Denying

examplethe causal

examples of an object’s It is difficult to find a

to convey

be careful

recall

something

using

this

about method

an too

mechanically. Its strength is that it takes a single claim and generates a set of variant claims not all of which are likely to be true. Thereby, it poses questions to the analyst that in our experience have often led to the rejection or tuning of a hypothesized claim. Another heuristic that can help the analyst confront candidate claims is to collect and group consequences that bear tradeoff relations. For example, claim 3 in Figure 7 addresses both desirable and undesirable salience consequences of the relative highlighting of prompts. Grouping these together into a claim schema helps the analyst confront both sides of the tradeoff and thereby the pertinence of the claim as a causal account of what could be salient to a user in an option change scenario. Indeed, a measure of how well ACM

Transactions

on

Information

Systems,

Vol.

10,

No

2, April

1992.

Getting Around the Tas}f-Artifact Cycle consequences

are grouped

are effective Note

that

schema

is the extent

in provoking nothing

on the

and undesirable;

and list them

encompassing relations.

Fronting

makes

the

But

it easier

desirable

to call

more

analysis,

The

attention

provides

collecting

schemas in a claim

a heuristic

related

to compare

consequences

to aspects

of consequences

merely

keep track of what has been accomplished regarded as true and desirable. Italicizing helps

claim

way

relation. An alternative to this causal relationships engendered

alphabetically.

schema

labeling

this

organizing claims that bear a tradeoff is to merely enumerate the implicit artifact

the resulting

inquiry.

deep hinges

as desirable

to which

197

.

of the

and

helps

claims

contrast

of

schema by an

into

a more

the bases

the designer

of

or analyst

in the design—claims currently the undesirable downside claims design

that

may

still

require

work,

has the

benefit

or redesign.

heuristic

of grouping

related

upsides

and

downsides

also of helping generate a more thorough psychological design rationale; if one has a claim without a downside or, perhaps, without an upside,

i.e., one

may

the

be moved

to more

aggressively

ask why

and to focus

more

on what

complete rationale could be.z There is no guarantee that there will be an answer to the question, but in our experience there often is an answer; and making that bit of rationale explicit helps get out the relevant issues: it is minority and majority current flow in semiconductors to make the mistake of thinking that only the matter—quite often it is just the reverse. Claims analysis is neither system modeling feel that had

separating

on design

these

and

two is responsible

design

analysis.

components causally linked. without causal commitments is of little

interest

for

3.3

analysis

modeling.

for the lack interest

is in

Indeed,

we

either

has

of impact keeping

design

or design

ana~ysis;

all

a user

capacities and experiences without features is also of little interest.

Using Claims In Scenario-Based

Claims

nor user

we do not want obvious claims

A system model that organizes artifact to specific psychological consequences

HCI

systematizes psychological ments to specific artifact

Our

again; most

can produce

the

key

features for users

model

causal

that

commit-

Design

situated

explanations

of predecessor

artifacts,

and these understandings can be used to envision and to craft new scenarios and new artifacts. The amount and fidelity of information that can enter into a claims analysis will be greatest for artifacts and situations that have been implemented complemented

and deployed; by empirical

when applied implementations

2 There

may

consequences

complex degree

to artifacts (though

be

several

derive

display.

documentation

in such cases, analytic work can be enriched observation. However, the method loses

different

from

In others, may

of example

and situations that are only designs and we may be less likely to discover shocking

sorts

variables

the

produce

paradigmicity

of

known

trading

in the

to

learner

Transactions

too

relationships.

covary,

relationship

contributes ACM

trading

a

richer

is more narrow

For clisplay

poorly

a concept,

to or mitigates on Information

this

example,

will

but

it

not yet causal

psychological

always

uncferstood.

and little

be a more

Example-based

is not

clear

how

the

tradeoff. Systems,

Vol

10, No.

2, Aprd

1992.

198

J. M. Carroll

.

relations

strictly

and

by analysis,

Rosson

just

as we may

be less

likely

to analytically

shocking scenarios such as the mutilated lease). Thus, claims can be strongly proactive in the sense that it can be used to develop

generate

analysis

and iteratively

refine

explanations

of use was illustrated Our use of claims evolution

from

consequences).

gambit while

This

of artifacts

that

do not yet exist.

This

in the development of the Reuse View Matcher analysis in scenario-based design is similar

an existing

design. Our basic ble consequences) First,

M. B

artifact

is easy

one does not alter

and

is to remove, maintaining to say but

claims

iteration

within

mitigate, or alter or strengthening more

directly.

difficult

Claims

an

artifact

downsides upsides

under

(undesira(desirable

to do for two

are causal

sort

[ 16]. across

relations

reasons. between

artifacts and users. We want to improve the consequences of the artifact for the user, but we can do this only by altering properties of the artifact. The claim schemas guide our attention to relevant artifact features and make explicit the underlying tradeoffs for the user that inhere in using the artifact. We can reason backwards, denying a downside, maintaining or strengthening its upside, and projecting a change in the artifact (for example, a change in Displaywriter highlighting) that could bring this about. But we can only alter what is of real interest to us (the user The second reason that claim-driven of nonunique claim, turn

wishing to the

causes.

Suppose

to improve causally

indirectly. consequence) design can be difficult

we focus

our

the consequence

relevant

artifact

design for users

feature,

attention

is the problem on a particular

in some specific

reason

about

its

way.

upsides

We and

downsides, and make a design change, which may lead to a new claim. How confident can we be now that the new claim is justified? The answer depends, at least in principle, on every other claim embodied This web of causality does not adhere in claims method;

it inheres

discussion). Claims analysis

in the

nature

provides

of design

a vocabulary

between persons and design classes of things the designer with those things the designer

[57]

in the use of the artifact. analysis or any class of

(see [ 10] and

for reasoning

about

[13]

for related

causal

directly options. This vocabulary can actually alter (namely, artifact really cares about but must alter

relations links the features) indirectly

(namely, the consequences for users and their basic tasks). Designers will try to do this anyway; they have no choice. However, when they do not have a detailed representation, such as a claims analysis, they will use whatever they

do have,

namely

the (inarticulate)

direct control. Thus we will revisit the illustrate how claim-based

artifact

Displaywriter reasoning

can

features

over which

and Smalltalk play a role

particular, how it can manage the two difficulties causes. To mitigate the downside of the highlighting

have

reuse claims and in design and, in

of indirection claim

they

and nonunique

in Figure

7, the

high-

lighting might be removed or the scenario redesigned so that the user’s attention is not so strongly drawn to the item prompt. More dramatically, we could consider scenarios in which the item prompt is not even presented; after ACM

all, for new users TransactIons

on

Information

of the Displaywriter, Systems,

Vol

10,

No

resetting 2, Apr,l

1992

options

is one of those

Getting

unrecommended quences standard

dialog

their relative consequences within

activities.

for the user.

the

without

example,

components

the Tasl(-Artifact

taking

this

the item

in the

scope of the without

prompt

option

choice

continued

interface;

conse-

prompt

hence,

are

altering

at all has global in

scenario,

consistency use-scenarios). Even

other there

for changing

highlighting

199

.

has other

and the exit

Displaywriter

the procedure

Cycle

approach

prompt

highlighting or their appearance (i.e., undesirable consequences

the item

presented;

However,

For

Around

are consequences; options

of the prompt

would

i.e.,

never

the continued

be

possi-

bility of changing options would not be clear, etc. In sum, these approaches mitigate a particular downside, but they do this by moving the tradeoff elsewhere, possibly worsening the net consequence for users. One can develop this line of argumentation to derive the redesign move that

was actually

Wheels

made

interface

[17].

in this This

case, namely,

solution

the development

involves

a global

mode

of the Training for the system

in

which requests to the item prompt are intercepted and trigger a special “blocking message” (for example, “Change Alternate Format is not available on the Training Displaywriter,” recall Figure 5). This solution is not without some cost; the learner who wants to change alternate format from within the Training Wheels interface will be frustrated. Nevertheless, the design argument

and

experimental

studies

indicated

that

this

design

move

is effective

and pleasant. In designing the Reuse View Matcher, it was salient to us that when programmers wondered what some class (say, Slider) could do in the context of an on-going project (an opportunistic interaction reuse the class typically involved instantiating perhaps

embedding

the new object

behavior and its possible a claim schema:

in a context

contribution

to their

an instantiated object supports discovery (but firlding or creating a representative (but trying work)

out indiu~dual

In our design argumentation, from an instantiated example, instantiation analogy to prefabricated,

and our

orchestrate

messages

may

scenario), their decision to it (e.g., in a workspace), of use, and then

project.

its

this

in

of its functionality instance ma-v be difficult) be tedious

or distracting

we tried to maintain the but mitigate the downsides an

exploring

We summarized

illuminating

View Matcher for learning that paradigmatic examples, examples

example,

to ongoing

upside of learning of having to do the We

we might cri~fted to

reasoned

offer the illuminate

by user the

typical use of the target object and animated to minimize the potential distractions to a user who, by assumption, was interested in using the target project. object in some oth w- on-going This line of design argument converged on the scenario in Figure 6 and ultimately in the Reuse View Matcher system [62]. New scenarios such as this,

and the eventual

artifact,

entrained

changes

in the claim:

paradigmatic scripted demos that use an object help programmers functionality (but the concept induced might be too narrow) (but users may have difficulty isolating the target functionality) ACM

Transactions

on Informatmn

Systems.

Vol.

analyze

10, No.

2, April

its

1992.

J. M. Carroll

200

.

The

original

and

downsides

M. B. Rosson

have

been

other downsides (see the earlier niques). That tradeoffs remain

mitigated,

though

they

are superseded

by

discussion of example-based learning techis unremarkable; the key point is that the

claims representation allowed us to keep track of where we were with respect to these upsides and downsides, to deliberately and selectively work on specific issues in the design, It is said that the objective does not have that

the

to think;

principles

and to assess our work. of building a principled

the thought

of the

methodology

easily get out of hand, as traditional human factors. approach, but one neither decision space conceptually

4. THE TASK-ARTIFACT In the and

foregoing

two

techniques

design

do some

FRAMEWORK:

sections,

In this

development;

methodology

is preempted work.

just This

is that

orientation

task

rubric

investigating

for

we have

presented

design

section, we

analysis

and

sketch

the

the

for

we exchange

of the domain). the

manual (artifact). Third, argumentation to produce

main

representations

constructing

the analytical

“information

Second,

psychological

psychological view

flow”

for a more

[10,

of our early

4.1 Generating

Scenarios

In

Figure

9 the

scenario

we use the task

design

75]

rationale

analysis

for

an

in

a

manual make a as a

existent

we use the claims analysis to drive the design a new manual design (that is, a set of redesigned

use-scenarios). Finally, we assess the design cal design rationale for the new manual. reconstruction

can

AN EXAMPLE

gedanken design project. We describe the design of an instructional for a word processor. First, we generate scenarios (that is, we basic-level

one

to the extent

in the notorious search for a figure of merit in One wants to get work out of an action science expects nor wishes to have a rich and complex bleached.

for scenario-based

rationales.

synthetic

required

project (This

work

on the Minimal

typology

of Figure

by developing example is

Manual

2 is used

psychologia pedagogic

[9].)

to generate

a list

of

candidate scenarios for a word processor’s instruction manual. As “orienting” concerns, the user may wonder about the kind of instructional situation this is and just how the manual will help in accessing and using the word processor’s

functionality.

The user may refer

opportunistically

to the manual,

wondering how to make the screen match a given figure on a given page, seeing a function referred to in a summary or review, and then deciding to practice or explore that function (out of sequence). The user may search for terms in the manual or for concepts without being sure of the correct term. In conventional manuals, may be unsure about

the user may wonder how to follow instructions and how to coordinate the manual with events in the

system. The user may not always immediately see how the manual works, for example, with respect to typographical conventions, and even so, the user may reflect on the rationale for the manual (perhaps wondering why certain activities ACM

and

TransactIons

not on

others

Information

were Systems,

selected Vol.

10,

as exercises). No

2, April

1992

Finally,

the

user

may

Getting

orien tin*

to appropriate

●

how

should

●

how

can this

interacting

with

.

using

.

skipping

scarcking

e

matchmg

●

finding

on his

Of

course

4.2

Given

how-it-works

.

infernng

.

understanding

.

conjecturing

on the thulg

as a goal chapter

text

why

upon

me’s

to practice

own

will

creating

a kasc

was repeated

work

text

manual

skill,

generated

about

be skipped,

typology

feedback

the index

indented

developing

screen for

pruccdurc

and highlighting to ignore

to a clipboard

sigmtles

“print”

and crafting

corresponds

information

It is useful the

in the book

z lctkx

the

indentation

why

figure that

and print

to check

explanatory

what

can really the

t{) Mom?

information

Scenarios for an instruction

or her

a letter

opportunistically in the bcmk

pmccdural

steps to type

Iearnmg

to wrtte

procedure

a prompt

how

and what

undergenerate,

from the typology.

tasks

can be simplified

is really

or

important.

preserving

an

incentive

to

scenario set with empirically attested scenarios—for example, lease mutilation scenario (see also chapters 2 and 3 of [9]).

Psychological a decent

explanations

information

how-to-do-it

.

how

state to some

following

what

augment the the infamous

print”

the screen

annotating

201

.

a description

for the

.

out

“rcfhrmatting”

following

Fig. 9.

enriched,

to the

.

reflecting

reflect

figure

.

seeking

Cycle

manualq

me tind

the cnvimnmcnt

under

Iookmg

seeking

help

an appcahng

.

the Task-Artifact

goals

1 use this

ahc~d

Around

Design Rationale for a Manual scenario

for why

set,

we

try

the scenarios

to-goals

and how-to-do-it

a letter.

(We

scenarios

are assuming

to

expose

can occur. in following

a self-instruction

and

codify

Consider

the manual manual

psychological

the central

orienting-

to type

and print

exemplifying

the

“sys-

tems approach” of [28]; again for more details see [9, chapters 2 and 3]). The learner seeking to create and print a letter is immediately confronted by supporting material that does not directly bear on the type-and-print concern: explanations about magnetic a description of the workstation hardware, storage devices, pointers, displays, and an orientation to the use of word processing equipment in office settings. The learner defers the type-and-print goal to read through (some of) this material. The learner confirms that all the system components are present. At length (about 25 pages later), the learner reaches the procedural part of the manual and is introduced to the use of menus

and

scrupulously

command follows

keys

through

each instruction, ACM

TransactIons

some

elementary

exercises.

The

learner

occasionally

feeling

some frustration

on Information

Systems,

Vol

10, No

2, Apr]l

at 1992.

202

.

not

making

J

M. Carroll

more

and

rapid

M. B. Rosson

and

tangible

progress

and

occasionally

wondering

what other things could be done with the screens and menus involved in the exercises, but basically confident that the manual “knows” what it is doing. After three chapters of this, the learner successfully prints out a first document. Figare 10 presents claims that generalize relations between features and techniques quences the

for a learner

downsides

described

in

above,

chapters

pursuing

Figure but

2 and

the type-and-print

10 are of these

in the that

claims

hypothesized causal artifact and conse-

concern.

exemplified

it is easy to imagine

3]). Each

and abstract of the manual

they

could

Perhaps

not all of

type-and-print might

have

be constructed

scenario been

(see [9,

by asking

the

questions of Figure 8. The first claim is suggested by the third question under “Specification,” asking how the artifact encourages the use of background knowledge in task planning. The second claim is suggested by the first question

under

“Specification,”

asking

about

the

distinctions

compose task goals and how these are conveyed. The third by the first question under “Interpretation,” asking how toward The

correct

inferences.

claims

can

example, models

with and

also

respect

advance

be justified to claim

organizers

by

the

1, many

laws

studies

in learning

and

needed

to de-

claim is suggested the user is guided

of basic

describe

psychology:

the

exercising

role

for

of mental

procedural

skills

(e.g., [21 and [301); some have characterized specific boundary conditions on the utility of mental models [33]. With respect to claim 2, separately practicing skill components can simplify the learning of a complex skill [28]. However, making errors during learning can also corrupt what is learned [69], and some skill decompositions do not prepare learners to apply what they

know

With

in performing

respect

to the third

a whole claim

skill

[42].

in Figure

10, the utility

of closely

coordinat-

ing feedback with learner actions to facilitate performance has been described [46]. But undermining the learner’s control of the situation can obstruct learning

[72].

Of course,

the

analysis

merely

sketched

here

would

be carried

out to greater detail in a real design process and would be carried out for several or many different scenarios (as in Figure 9). As we proceed, we confront hypothesized consequences of our claims to try to generate new perspectives about the hypothesized claim

and considerations. We reason counter factually consequences as a sanity check on the analysis

(e.g.,

instructions just what

do not

4.3

asking whether having help the learner know

Scenario-Based

and action in lock-step to do and when).

contiguity

Design of a Better Manual

The claim representation can be used to fathom the design space and to orient redesign work concretely and comprehensively (again pursuing the transistor analogy, we move on to the task of designing a solid-state amplifier with an explicit theory of semiconductors—including an explicit inscription about minority carriers). Our first heuristic is to focus on the downsides of the claims (in Figure 10), asking how we might redesign the type-and-print scenario to mitigate these downsides. ACM

TransactIons

on

Information

Systems,

Vol.

10,

No,

2, Aprd

1992,

Gethng

I

a structural dcwcc

of major

clcscr!ptlon

works

(\vhich

may

help

system

Around

the Task-Artifact

mnvcys

c(nnponcnts

ground

or rationalize

the

~ mental

Icarncr’s

Cycle

model

of how

umierstmdmg

203

.

the

of how,

to use it) ([Ju( [he cfrwfwal wi[h 2

decomposing

3

derc,zpt!m

[j,,mng and prmllng,

turn

allows

“typing

( [Ml

IWJVW r m~y

w4ut

rr karncd)

(k(

lILIT mxcmiza[[on

kmpmg to know

and

J mmplcx

directive

noI

!o/wa[r

may

what

lrczrnmf

Fig.

Thus

we ask

distraction,

mu,ll

10.

facih[a[c

rrlinqui,rh

the

be made

embodied

and hudt

m- may

10.WWLY roncwri

tminmg

cwh

u[~ from

parts

mzh

appllcw{on

c C?f17rr

m rcol

m Iock.step

(pmmotmg or ana~,~u

cont}{