시나리오 베이스 디자인 방법론 (scenario based design)

Scenario-Based Design+Chapter 53. Human-Computer Interaction Handbook: Fundamentals, Evolving Technologies and Emerging Applications. Lawrence Erlbaum Associates, 2002

-Mary Beth Rosson and John M. Carroll

/임하진x 2013 summer

http://ux.snu.ac.kr

http://ux.snu.ac.kr

시나리오 베이스 디자인

Reference

Scenario-Based DesignMary Beth Rosson and John M. CarrollDepartment of Computer Science and Center for Human-Computer Interaction Virginia Tech, Blacksburg VA

Chapter 53 in J. Jacko & A. Sears (Eds.), The Human-Computer Interaction Handbook: Fundamentals,

Evolving Technologies and Emerging Applications. Lawrence Erlbaum Associates, 2002, pp. 1032-1050.

임하진2013년 8월 8일 랩미팅

• John M. "Jack" Carroll is Edward M. Frymoyer Professor of Information Sciences and Technology at Penn State.

• Carroll is awarded ACM SIGCHI Lifetime Achievement Award in 2003 for his contribution to the field of human-computer interaction (HCI or CHI).

• Carroll was a founder of the study of human-computer interaction, one of the nine core areas of Computer Science identified by the Association for Computing Machinery (ACM).

• Through the past two decades, Carroll has been involved in the development of the field of Human-Computer Interaction. In 1984 he founded the User Interface Institute at the IBM Thomas J. Watson Research Center. In 1994, he joined Virginia Tech as Department Head of Computer Science to establish an HCI focus in research and teaching at the university's Center for Human-Computer Interaction.

• He was a founding associate editor of the field's premier journal, ACM Transactions on Computer-Human Interaction, and a founding member of editorial boards ofTransactions on Information Systems, Behavior and Information Technology, and the International Journal of Human-Computer Interaction.

John M. Carroll

http://en.wikipedia.org/wiki/Penn_State

http://en.wikipedia.org/wiki/Penn_State

http://en.wikipedia.org/w/index.php?title=ACM_SIGCHI_Lifetime_Achievement_Award&action=edit&redlink=1

http://en.wikipedia.org/w/index.php?title=ACM_SIGCHI_Lifetime_Achievement_Award&action=edit&redlink=1

http://en.wikipedia.org/wiki/Human-computer_interaction

http://en.wikipedia.org/wiki/Human-computer_interaction

http://en.wikipedia.org/wiki/Computer_Science

http://en.wikipedia.org/wiki/Computer_Science

http://en.wikipedia.org/wiki/Association_for_Computing_Machinery

http://en.wikipedia.org/wiki/Association_for_Computing_Machinery

http://en.wikipedia.org/wiki/Thomas_J._Watson_Research_Center

http://en.wikipedia.org/wiki/Thomas_J._Watson_Research_Center

http://en.wikipedia.org/wiki/Virginia_Tech

http://en.wikipedia.org/wiki/Virginia_Tech

http://en.wikipedia.org/wiki/ACM_Transactions_on_Computer-Human_Interaction




http://en.wikipedia.org/w/index.php?title=Transactions_on_Information_Systems&action=edit&redlink=1




http://en.wikipedia.org/w/index.php?title=Behavior_and_Information_Technology&action=edit&redlink=1

http://en.wikipedia.org/w/index.php?title=Behavior_and_Information_Technology&action=edit&redlink=1

http://en.wikipedia.org/w/index.php?title=International_Journal_of_Human-Computer_Interaction&action=edit&redlink=1




• 1. The Basic Idea

• 2. A Simple Example

• 3. Why Scenario-Based Design?

• 4. A Framework for Scenario-Based Design

• 5. Scenarios Throughout the System Life Cycle

• 6. Current Challenges

책 순서

• 1. The Basic Idea

• 2. A Simple Example

• 3. Why Scenario-Based Design?

• 4. A Framework for Scenario-Based Design

• 5. Scenarios Throughout the System Life Cycle

• 6. Current Challenges

발표 순서

시나리오베이스디자인이란?

• 시나리오 베이스 디자인 (Scenario-based design)은 미래 시스템을 개발하는 데 사용되는 테크닉, 개발 초기 단계에서 주로 사용 된다.

• 다양한 Usage Story로 구성된 서술들은 개발의 전 단계에 적용될 수 있다

• 다른 Human Centered Design 접근 방법론 들과 같이 사람들이 시스템을 어떻게 사용하는 지에 관심이 있다.

• Formal Analysis나 Well-specified task를 통해 사람들의 행동과 경험을 설명해내는 방식보다는 상대적으로 가볍지만, 시스템 개발과 미래의 Usage Possibility를 그려내는 데 부족함이 없다.

1. 기본개념

1. Basic Concept

• 시나리오란?

• “시나리오란 사람들과 그들의 행동에 대한 이야기” [Carroll, 1999]

• 시나리오의 기본 구성 요소 • Setting

• 각각의 에피소드에 시작 상태

• 이는 서술된 상황과 관련이 있는 대상들에 대한 서술도 포함

• Actors (or Agents):

• 해당 시나리오와 관련된 사람들

• Agent’s Goals (or objectives):

• Agent(System)이 Setting의 환경에 변화를 주고자 하는 것

• Plot

• Actor와 시스템에 의해 벌어지는 일련의 이벤트와 행동의 결합으로 시나리오 내의 Setting에 변화나 영향을 줌

1. 기본개념

1. Basic Concept

• 시나리오의 예시

1 0 /1 9 /07V incenzo.P allotta@ un ifr.ch6

Scenario ExampleHarry is interested in bridge failures; as a child, he saw a small bridge

collapse when its footings were undermined after a heavy rainfall.He opens the case study of the Tacoma Narrows Bridge and requests to

see the film of its collapse. He is stunned to see the bridge firstsway, then ripple, and ultimately lurch apart.

He quickly replays the film, and then opens the associated coursemodule on harmonic motion.

He browses the material (without doing the exercises), saves the filmclip in his workbook with a speech annotation, and then enters anatural language query to find pointers to other physicalmanifestations of harmonic motion.

He moves on to a case study involving flutes and piccolos.

S ource: J. C arroll, 1 999G oals A ctivities O bjects

1. 기본개념

• 실무적인 장점

• 비교적 쉽고 빠르게 작성 가능

• 팀원 간 그룹 커뮤니케이션이 용이해 짐 (=Persona)

• 본질적인 장점• 시나리오는 매우 명료하면서도 유연하다.

• 시나리오는 기본적으로 사람과 그의 Needs에 집중할 수 있도록 도와준다.

• 시나리오는 다양한 관점에서 유용한 질문거리를 만들어 줌으로써 고려해야할 요소들에 대해 빠짐없이 검토할 수 있게 한다.

3. 시나리오 베이스 디자인이 좋은 이유

• Solution First Approach

• Problem Analysis 단계에서 가능한 솔루션 후보군들을 빠르게 제시하고 분석 함으로써 최종 목적을 빠르고 효율적으로 이루고자 하는 접근방식

• 예시 ) Rapid Prototyping / Extreme Programming

• Solution First Approach의 문제점

• 현재의 상황을 정확하게 파악하고 다양한 가능성을 검토하기 전에 솔루션을 제시

• 이미 존재하거나, 친숙하고 접근 가능한 솔루션을 '재활용'할 여지 존재

• 매우 제한된 종류의 대안만을 제시할 가능성 높음

• 시나리오 베이스 디자인을 통해 Solution First Approach의 문제점을 개선할 수 있음

3. 시나리오 베이스 디자인이 좋은 이유 - Solution First Approach

Rosson & Carroll: SBD 3

alternatives, or to raise questions about the assumptions behind the scenarios. They can beused to analyze software requirements, as a partial specification of functionality, and toguide the design of user interface layouts and controls. They can be used to identify andplan evaluation tasks that will be performed by usability test participants.

3. Why Scenario-Based Design?

One reason that scenarios have become so popular in interactive system design is that theyenable rapid communication about usage possibilities and concerns among many differentstakeholders. It is easy to write simple scenarios such as those in Table 1, and takes only alittle more effort to enrich it with a rough sketch or storyboard. When designers areworking through ideas, they want to make progress quickly, so that they can obtainfeedback and continue to refine their ideas. Scenarios are one way to do this.

The design of an interactive system is an ill-defined problem. Such problems tendto evoke a problem-solving strategy termed solution-first (Cross, 2001). In the solution-firststrategy, designers generate and analyze a candidate solution as a means of clarifying theproblem state, the allowable moves, and the goal. They exploit the concreteness of theirown solution proposals to evoke further requirements for analysis.

Hazards of the solution-first approach How scenario-based design can help

Designers want to select a solution approachquickly, which may lead to premature commitmentto their first design ideas

Because they are concrete but rough, scenariossupport visible progress, but also relax commitmentto the ideas expressed in the scenarios

Designers attempt to quickly simplify the problemspace with external constraints, such as the reuse offamiliar solutions

Because they emphasize people and theirexperiences, scenarios direct attention to the use-appropriateness of design ideas

Designers are intent on elaborating their currentdesign proposal, resulting in inadequate analysis ofother ideas or alternatives

Because they are evocative and by nature areincomplete, scenarios promote empathy and raiseusage questions at many levels

Table 2: Concerns stemming from the solution-first approach to design, and aspects of scenario-based

design that address each concern.

A solution-first approach to design is energizing, effective, and efficient; itexplains the popularity of contemporary system development approaches like rapidprototyping (Wasserman & Shewmake, 1982) and extreme programming (Beck, 1999). Butthis general strategy also entrains well-known hazards (Cross, 2001): Designers tend togenerate solutions too quickly, before they analyze what is already known about theproblem and possible moves. Once an approach is envisioned, they may have troubleabandoning it when it is no longer appropriate. Designers may too readily reuse pieces of asolution they have used earlier, one that is familiar and accessible, but perhaps notappropriate. They may not analyze their own solutions very well, or they may consider toofew alternatives when exploring the problem space. In the next three sections we considerhow scenario-based design may help to minimize these hazards of solution-first problemsolving (see Table 2).

• “Representational Bias” • 인지 심리학 개념으로 친숙한 대상과의 연관성/중요도을 극대화 해서 평가하는 경향(Kahneman

& Tversky 1972; Tversky & Kahneman, 1974).

• 시나리오 베이스 디자인을 통해 자신의 경험, 인상에 근거한 판단을 지양하고 새로운 생각과 발상을 유도할 수 있게 됨

• “We are all Storytellers” • 스토리 텔링 : 다양한 사람들의 다양한 생각을 Context 속에 녹여 낼 수 있게 함

• 이미지의 환기

• 사람들의 상황에 감정이입 -> 질문던지기

• 사람들의 행동 / 목표 / 기술

• 사람들의 동기, 의도, 반응, 만족

3. 시나리오 베이스 디자인이 좋은 이유 - Representational Bias

4. 시나리오 베이스 디자인의 프레임 워크


Figure 1: An overview of the scenario-based design (SBD) framework. Scenarios serve as a central

representation throughout the development cycle, first describing the goals and concerns of current

use, and then being successively transformed and refined through an iterative design and evaluation

process (from Rosson & Carroll, 2001b).

The problem scenarios are transformed and elaborated through several phases ofiterative design. Design envisionment is inspired by metaphors and technology options,but at the same time is constrained by the designers’ knowledge of interactive systemdesign. Each set of scenarios is complemented by claims that analyze the possible positiveand negative consequences of key design features. Claims analysis leads designers toreflect on the usage implications of their design ideas while the ideas are being developed.

Scenario-based design is guided by usability evaluation throughout development.Each narrative serves as a test case for analytic evaluation; each claim hypothesizesusability outcomes for one or more test cases. Design scenarios are also evaluated moredirectly through empirical usability studies. In these the claims analysis structures amediated evaluation process, wherein the hypothesized usage impacts are operationalizedand tested explicitly (Scriven, 1967). The empirical findings are interpreted with respect tothe ongoing claims analysis, refining or redirecting the design efforts. We turn now to abrief example illustrating the key elements of the framework.

4.1 Requirements Analysis

A challenge for any software development project is identifying the complete and correctset of requirements (Brooks, 1995). Many system requirements are functional, addressedby the actual services and information provided by the final system. Other requirementsare nonfunctional, for example the measured quality of the software implementation or user

Problem scenarios

summative

evaluation

Information scenarios

claims aboutcurrent

practice

analysis ofstakeholders,

field studies

Usability specifications

Activity

scenarios

Interaction scenarios

iterativeanalysis of

usability claims and

re-design

metaphors,information

technology,HCI theory,

guidelines

formative

evaluation

DESIGN

ANALYZE

PROTOTYPE & EVALUATE

4. 시나리오 베이스 디자인의 FrameWork

Analyze Design Prototype -Evaluation

4. 시나리오 베이스 디자인의 프레임 워크 4. 시나리오 베이스 디자인의 FrameWork

Analyze Design Prototype -Evaluation

Problem시나리오

Activity시나리오

Information시나리오

Interaction시나리오

....시나리오

Claim Analysis+ / -

4. 시나리오 베이스 디자인의 프레임 워크 4. 시나리오 베이스 디자인의 FrameWork










Problem scenarios

summative

evaluation


claims aboutcurrent

practice


field studies


Activity

scenarios




re-design



guidelines

formative

evaluation

DESIGN

ANALYZE


4.1 Analysize - Problem 시나리오


interactions, or pragmatic features of the system development process like schedule, cost,or delivery platform (Rosson & Carroll, 2000; Sommerville, 1992; Sutcliffe & Minocha;1998). In SBD we express an initial analysis of requirements as a root concept (Table 4).The root concept enumerates key aspects of the team’s starting vision; it is used to guidefurther analysis and elaboration of system requirements.

Component Contributions to the root concept

High-level vision Club members interact anytime, anywhere; develop shared resources

Basic rationale Network-based interaction overcomes barriers of place and time

Digital media are convenient to archive, organize, and retrieve over time

Stakeholder group:

Club officer

Club member

Prospective member

Convenient scheduling and posting of shared events and information

Ongoing access to club activities, persistent recognition of contributions

Self-paced exploration of club vision, history, and membership

Starting assumptions Open-ended participatory design process

Members have pervasive access to personal computers and network connections

Community computing development accomplished via volunteer efforts

Table 4: A root concept for developing online activities for a Science Fiction Club

Table 4 contains a root concept for the science fiction club example that we use toillustrate the framework. The starting vision and rationale in this case are quitestraightforward: there are obvious advantages to meeting with associates in person, but theconstraint of same-time, same-place limits frequency and/or length of such meetings.Moving some of the club’s activities online increases interaction opportunity andflexibility. At the same time, a side-effect is that digital interactions can be stored and forother purposes.

The root concept also documents the team’s shared beliefs about the project’s majorstakeholders. A stakeholder is any person or organization who will be affected (eitherpositively or negatively) by the system (Checkland, 1981; Muller, 1991). It is important totake a broad view of stakeholders, particularly early in requirements analysis, so thatappropriate individuals and groups will be represented in analysis activities. In theexample, we consider several different types of club members because they will havedistinct goals with respect to system use—an officer who might find an online systemconvenient for scheduling and posting information; a “regular” club member who will nowhave more options for participating, and a prospective member who can learn about theclub and its activities in a customized, self-directed fashion.

Although the emphasis of SBD is on analyzing and developing usable functionality,there may be a range of nonfunctional concerns that will constrain development. These aredocumented as starting assumptions in the root concept. For our example project, weassume that the design of the online club software will involve considerable participationby stakeholders, that club members already have the computing resources needed to accessthe system, and that use and maintenance of the final system will take place throughmembers’ volunteer efforts.

Functional(Thoughts/Goal)

NONFunctional(Context)

• Problem 시나리오

• 전통적인 의미의 'Requirement'는 아님 - 필요한 시스템 기능의 열거가 아님

• 개발 전 과정에 있어 가장 중요한 '기준'을 설정하는 단계

• 개발 시작 단계에서 Needs와 Opportunity와 관련된 요소들을 확인함

• 현재의 활동을 분석해내는 데 집중함

• 조사 방법 : Fieldwork, Activity Artifact (Stakeholder's value & activities)

• 정리 방법 : Affinity Diagram / Stakeholder Relationship / Hierarchical Task Analysis -> Key Theme 도출

• Problem Scenario의 구성

공통

기술낙관적 가정

개개인

환경 / 개인

4.1 Analysize - Problem 시나리오


Sharon is a busy third-year psychology student at Virginia Tech. Even though she has a biology exam tomorrowmorning, she has been looking forward to her science fiction club meeting for several days, so she decides to goand stay up late to study when she gets back. She remembers that they were planning to talk about Asimov’sRobots and Empire, and she has a new theory about the timeline for first detection of the Zeroth Law.

The meeting is scheduled for 7pm at their usual room in the town library. But she is late getting back fromdinner with her room-mate, so she misses her regular bus and arrives 15 minutes late. The meeting is alreadyunderway; she notes that they have a relatively small group tonight, but is happy to see Bill and Sara, who are thereal experts on Asimov. She is even more delighted to see that these two are already having a heated discussionabout the Zeroth Law. But she is cannot immediately tell what points have been made, so she sits back a while tocatch the drift of the conversation. At a break, Bill greets her and asks her what she thinks about Faucian’sinsight. She replies that she isn’t sure about how central he is to the plot, but that she has a new theory about thetimeline. They promise to hear her proposal in a few minutes, then resume the argument.

Table 5: A problem scenario describing Sharon’s visit to the science fiction club meeting.

Face-to-face interaction with club members at a meeting

+ ensures that both nonverbal and verbal communication contribute to the interaction

+ leverages many years of experience with communication protocols and conventions

− but may introduce distracting or irrelevant personal information about partners

− but inhibits parallel communication activities (i.e., among multiple parties at once)

A regular physical space used for club meetings

+ promotes a feeling of familiarity and intimacy among established members

+ simplifies the planning and execution process for arriving at meetings

− but requires members to travel to the site for interaction

− but physical locations are valuable resources that must be shared among organizations

Table 6: Two claims analyzed from the club meeting problem scenario. The feature of interest appears

in the shaded area; hypothesized positive consequences are prefaced with a plus sign and negative

consequences with a minus sign.

The themes and relationships implicit in a scenario can be made more explicit andopen for discussion by analyzing them in claims (Table 6). Problem claims are analyzedby identifying features of the scenario that have notable consequences for the actors’experience. This is an instance of analytic evaluation and as such is clearly guided by theexpectations and biases of the evaluator. A more systematic evaluation can be obtained byasking questions of the scenario that are guided by cognitive or motivational theories ofhuman behavior (Carroll & Rosson, 1992; Polson et al., 1992). The first claim captures akey aspect of Sharon’s experience in the scenario—meeting in-person with other clubmembers creates a rich communication bandwidth; both verbal and non-verbal content canbe shared, which helps Sharon know when to jump in with her new topic.


Sharon is a busy third-year psychology student at Virginia Tech. Even though she has a biology exam tomorrowmorning, she has been looking forward to her science fiction club meeting for several days, so she decides to goand stay up late to study when she gets back. She remembers that they were planning to talk about Asimov’sRobots and Empire, and she has a new theory about the timeline for first detection of the Zeroth Law.

The meeting is scheduled for 7pm at their usual room in the town library. But she is late getting back fromdinner with her room-mate, so she misses her regular bus and arrives 15 minutes late. The meeting is alreadyunderway; she notes that they have a relatively small group tonight, but is happy to see Bill and Sara, who are thereal experts on Asimov. She is even more delighted to see that these two are already having a heated discussionabout the Zeroth Law. But she is cannot immediately tell what points have been made, so she sits back a while tocatch the drift of the conversation. At a break, Bill greets her and asks her what she thinks about Faucian’sinsight. She replies that she isn’t sure about how central he is to the plot, but that she has a new theory about thetimeline. They promise to hear her proposal in a few minutes, then resume the argument.

Table 5: A problem scenario describing Sharon’s visit to the science fiction club meeting.

Face-to-face interaction with club members at a meeting

+ ensures that both nonverbal and verbal communication contribute to the interaction

+ leverages many years of experience with communication protocols and conventions

− but may introduce distracting or irrelevant personal information about partners

− but inhibits parallel communication activities (i.e., among multiple parties at once)

A regular physical space used for club meetings

+ promotes a feeling of familiarity and intimacy among established members

+ simplifies the planning and execution process for arriving at meetings

− but requires members to travel to the site for interaction

− but physical locations are valuable resources that must be shared among organizations

Table 6: Two claims analyzed from the club meeting problem scenario. The feature of interest appears

in the shaded area; hypothesized positive consequences are prefaced with a plus sign and negative

consequences with a minus sign.

The themes and relationships implicit in a scenario can be made more explicit andopen for discussion by analyzing them in claims (Table 6). Problem claims are analyzedby identifying features of the scenario that have notable consequences for the actors’experience. This is an instance of analytic evaluation and as such is clearly guided by theexpectations and biases of the evaluator. A more systematic evaluation can be obtained byasking questions of the scenario that are guided by cognitive or motivational theories ofhuman behavior (Carroll & Rosson, 1992; Polson et al., 1992). The first claim captures akey aspect of Sharon’s experience in the scenario—meeting in-person with other clubmembers creates a rich communication bandwidth; both verbal and non-verbal content canbe shared, which helps Sharon know when to jump in with her new topic.

Problem시나리오

Claim분석

'각각의 시나리오에 나타난 특징들에 의해 인과관계로 나타날 것이라 예상되는 각각의 요소'

들을 긍정적 (+) / 부정적 (-)인 측면 으로 나누어 분석

4.1 Analysize -Claim 분석

Claim 분석은 다른 시나리오 / 단계에서도 모두 반복되는 과정

Actor들의 경험에따라 규정될 각각의 기능 / 특징 / 환경등을 확인하고 분석하는 과정

(평가자의 기대와 편견에 따라 좌우될 여지가 큰) 분석적인 접근

• Claim 분석이 필요한 이유 • "What if" - 사용자와 감정이입

• 서로 다른 시나리오의 측면들을 부분적으로 취할 수 있게 되어 (긍정적인 부분만) 다양한 대안 도출 가능

• 긍정적이면서 부정적인 부분 둘 다 고려하는 균형적인 시야를 가질 수 있도록 함

• 특히 Requirement 분석 과정에서 현재 상황의 부정적인 측면 (Breakdown, Contradiction)에만 치중하는 경향이 있음

• 문제점 뿐만 아니라 새로운 '기회', '가능성'을 보기 위해서는 현재의 상황에서 이미 잘 이루어지고 있는 것에도 집중해야 함

• 이는 현재의 환경에 어떤 변화가 있게 될 때 (시스템이 도입되었을 때)의 '부작용'을 미리 예상해 볼 수 있게 함

....시나리오

Claim AnalysisPros / Cons

4.2. Activity 시나리오 -Design Space

Stakeholder가 처한 상황과 그들의 요구를 충분히 이해하고, Specific한 디자인 제언을 준비를 시작 수 있게 되었을 때 (Problem 시나리오->)

• Activity 시나리오

• "현재의 Acitivity가 어떠한 방식으로 개선되고, 가용한 기술을 통해 변화될 수 있는지" 충분히 숙고하여 근본적인 Solution Idea를 도출하는 과정

• 주의해야할 지점

• 현재 시점의 사람들의 행동과 환경, 기대에 지나치게 의존하는 경향

• 새로운 Option과 Insight를 탐구하는 데 방해가 됨

• (Activity 시나리오를 작성하기 앞서) Design Space • Problem 시나리오에 적용할 수 있는 Concept들과 기술들을 열거하는 작업

• Metaphor / Technology


• Design Space의 구성 • Metaphor

• 개념적인 매타포의 차용 -> 다양한 방식의 Activities를 촉발

• 실제 존재하는 시스템이나 그의 작동 방식을 차용하는 것 (유사성에 근거하여 UI 디자인에 주로 사용됨 )

• Think outside the box

• 실제로 존재하는 것을 기반으로 하지만 상당히 Creative한 디자인을 도출해 낼 수 있게 됨

• Technology

• 현재 시점에서 가용한 기술 및 이미 존재하는 서비스 검토

• 실질적인 Software 개발 측면에서

• 현재 사용가능한 기술과

• 그가 솔루션에 기여할 수 있는 바를 검토해 볼 수 있음



domain, along with some analysis of what these options might bring to the design solution(MacLean, Young, & Moran, 1989; Moran & Carroll, 1996).

Table 7 exemplifies two techniques useful in exploring design alternatives. Theupper part of the table shows how different conceptual metaphors evoke contrasting viewsof stakeholder activities. Metaphors are often used deliberately in user interface design,with the hope that users will recruit them in reasoning by analogy about what a system doesor how it works (Carroll & Thomas, 1982; Carroll, Mack, & Kellogg, 1988; Madsen,1994). Here we emphasize the role of metaphors in helping designers “think outside thebox” (Erickson, 1990; VerPlank, 1988). Addressing real world activities and concerns iscrucial to effective system design, but it is often metaphoric thinking that promotes theinsights of truly creative design.

Activity design features suggested by metaphors for an online meeting

Reading at the library

Hearing a lecture

Visiting a museum

Going to a cocktail party

Self-paced, individual access to structured information

Large audience; prepared materials; one-way communication

Array of artifacts, small groups or individuals examine, discuss

Friends forming subgroups; social exchange and mingling

Activity design features suggested by information technology for an online meeting

A hierarchy of Web pages

An email distribution list (listserv)

A shared whiteboard

Meeting groupware

Mix of text and graphics, category names and links

One-way “push” communication, possibly large audience

Informal sketches

Explicit agenda, support for floor control, meeting records

Table 7: Using metaphors and available information technology to reason about activities

An analysis of available information technology provides a complement to themetaphoric thinking. In a sense, the technology provides another set of metaphors forthinking about the activities to be supported, but in this case the analogy is with classes ofsoftware and devices that already exist (e.g., Web information systems, email or databasepackages). At the same time, a technology-oriented analysis such as this directs the designback to many of the pragmatic concerns of software development, by enumerating possibletechnology and how it might contribute to the solution. This analysis may also be veryinfluenced by the projects starting assumptions (Table 3), for instance if the developmentorganization already has developed a shared whiteboard or has considerable experiencewith Web information systems.

The exploration of metaphors and technology does not generate a new activitydesign. Rather it provides a set of lenses for discussion. The team might consider what itwould be like if the online science fiction club was designed to be like a cocktail partyversus a lecture; they can argue about the relative advantages of using a structured

Metaphor

AvailableTechnology

4.2. Activity 시나리오

• Activity 시나리오 : 새로운 시스템의 도입으로 사람들의 Activity에 일으킬 변화와 기술의 활용에 대한 솔루션 Idea

• 수 많은 대안 중 어떤 것을 골라야 할까?

• (현실적인) 판단 기준 : 현재 사용되고 있는 서비스, 팀원들의 전문성, 개발 자원, 조직 목표

• 그래도 고르기 힘들다면?

• Participation Design Session (Co-Design)

• Claim 분석 Rosson & Carroll: SBD 17

Sharon is a third-year psychology student at Virginia Tech, and after three years she has learned to takeadvantage of her free time between classes. In her hour between her morning classes, she stops by the computerlab to visit the science fiction club, because she heard from a friend that they are discussing her favorite book,Asimov’s Robots and Empire, and she wants to share her new theory about the timeline for the Zeroth Law.

When she logs onto a computer, she first checks her email, and sees that as she hoped there are several emailsfrom club members proposing and responding to views on this book. But rather than read each email, shefollows the convenient link to the Club’s Web site, which takes her right to the ongoing discussion. As always,the reviews are first, then the discussion topics, where she finds the new discussion thread started by Sara andBill. She reads the new thread before adding her theory about the Zeroth Law, and notes that Bill is alsofascinated by this piece of the story. She summarizes her theory, and because she wants the group to focus onthis issue she makes it a first-level topic but links it to Bill’s post to acknowledge the relation. When she submitsit she is reminded that an email has been sent to the club listserv with her contribution.

Before leaving, Sharon backs up to the homepage and browses the book categories to look for new books anddiscussions. Right underneath her favorite category of “Artificial Intelligence” (where the Asimov series isplaced), she discovers an intriguing new entry, “Brain Evolution”. She doesn’t recognize any of the authors inthis category, so sends herself a reminder to track down a couple of books from the category later that day.

B. Sharon goes to the Science Fiction Club’s online room

Sharon is a busy third-year psychology student at Virginia Tech. But after three years she has learned to takeadvantage of her free time between classes. In her hour between her morning classes, she stops by the computerlab to visit the science fiction club because she heard from her friend that they are discussing her favorite book,Asimov’s Robots and Empire, and she wants to share her new theory about the timeline for the Zeroth Law.

When she logs onto a computer, she first checks her email, and sees that as she hoped there are several emailsfrom club members proposing and responding to views on this book. But rather than read each email, shefollows the convenient link to the Club’s online room. She is taken to their regular discussion spot, the bar of alocal pub. As she arrives, she sees that Sara, Bill, and Jennifer are already there. She reviews their conversation,and notes that they are discussing Jennifer’s new review of Asimov’s Robots and Empire. Before she joins in,she quickly opens and browses Jennifer’s review. She agrees with Jennifer, so she eagerly jumps in to take herside against Bill and Sara. In a few minutes, the chat moves on to plan a group outing that night. She has tostudy, so she drops out of the conversation to create a new discussion with her theory about the Zeroth Law. Shesees that an announcement is sent to all the club members when she has finished creating the object.

Sara keeps an eye on the others’ conversation, and when there is a break, she invites them to visit her new topic.They discuss the Zeroth Law for a while, but leave it open for others to visit. On her way out, Bill tells her hehas a new “Brain Evolution” grouping he is working on. She hasn’t heard of the titles he mentions, so she sendsherself a reminder to track down a couple of books from the category later that day.

Table 8: Two alternative activity designs for the online club meeting

The second scenario shows an influence of the cocktail party, museum, and librarymetaphors. It emphasizes social exchange and informal conversation, as well as responsesto an assortment of club-specific artifacts in the space. Sharon is able to see which of herfellow members are around, and can follow the conversation but also carry out her ownexploration in parallel. She jumps in and out of the conversation as her interest in the topicincreases or decreases. The club members are engaged in activities that refer to artifacts ondisplay in their room—discussion topics and a bookshelf that displays book titlescategorized by theme.

4.2. Activity 시나리오 - Claim 분석


Both of these scenarios have attractive consequences for Sharon and her friends.Both are possible solution approaches, so how do the designers choose? Again, manypragmatic factors contribute to this decision—the kinds of software currently in use, theteam’s design expertise, development resources, organizational priorities, and so on. Butassuming that both solutions are genuine possibilities, the designers must also evaluatethem with respect to their usage implications. One way to do this is with participatorydesign sessions (Carroll et al., 2000; Chin, Rosson, & Carroll, 1997; Muller, 1992; Kyng,1995) that focus on how well the alternatives suit stakeholders’ needs. In SBD we alsoevaluate scenarios through claims analysis, where the positive and negative implications ofdesign features are considered through “what if” discussions.

A sample claim analyzed from each scenario appears in Table 9. In this illustrativeexample, the scenarios were intentionally written to be very similar in many respects; theclaims capture one of the basic design contrasts built into the alternative designs. The Website offers a convenient hierarchical listing of topics, whereas the online room holds anumber of different “objects” that people discuss in real time. The analysis helps thedesigners to see the relative advantages and disadvantages of an organized asynchronousinteraction and a more ad hoc synchronous exchange. Such an analysis may or may not beenough to mandate one alternative over the other. But at the least it begins to lay out usageissues that will be the topic of continuing design.

Discussion archives organized by topic and content submitters

+ leverages people’s familiarity with categorical hierarchies

+ emphasizes the central and permanent recognition of individuals’ contributions to the archive

− but browsing extensive stored archives may be tedious or complex

− but people may be disinclined to contribute more transient and informal content to an organized archive

Real-time conversation organized by the people present in a space

+ leverages people’s familiarity with real world conversational strategies

+ encourages a combination of topic-specific and ad hoc informal exchange

− but requires that conversation participants be present at the same time

− but newcomers may find it hard to interrupt an ongoing conversation

Table 9: Activity claims that help to contrast the implications of competing scenarios.

It is important to note how much progress can be made even at this very early levelof envisioning activities. The narratives in Table 8 are quite concrete and evocative;designers or their clients can readily understand what is being proposed and begin toconsider the relative pros and cons of the design ideas. Yet the scenarios are “just talk”;indeed if they are shared and discussed over an interactive medium, they can easily beextended or revised as part of a real time design review and discussion.

솔루션의 도입으로 본질적으로 강화 / 변화시키고자 하는 사람들의 행위 규정

Face to Face Club Meeting

Acitivity1

Acitivity2

4.3. Information 시나리오

Activity 시나리오를 통해 임시적으로 몇 가지의 솔루션의 방향 이 정해지고 나서

(Problem 시나리오 -> Activity 시나리오 -> )

• Information 시나리오• 사용자가 시스템을 어떻게 바라보고 이해하게 될 것인지에 집중

• 사용자가 이루고자 하는 과업/Acitivity를 시스템 수준으로 Render하는 과정

• 정보 구조 및 흐름이 디자인 됨

• Activity가 어떤 information과 Interaction (UI)를 통해 구현될 것인지 전반적인 UI 요소 선택 및 구성 방식에 대해 논의

• Ex) WIMP paradigm: windows, icons, menus.....

• 정보 구조에 Metaphor의 차용 • library: documents look like pages in books with title-bearing covers; objects are arranged in alphabetical or category order on shelves; there are desks

and chairs for browsing and note-taking

• museum: the space is broken into relatively small topic-specific rooms; objects of interest are mounted on the walls; there is space around each object enabling a group of interested parties to form; descriptive titles and text are attached to each display object

• cocktail party: there are a number of attractive “seating areas”, perhaps including a table and chairs; visitors are organized into groups and emit a “buzz” of conversation; new arrivals are greeted with waves or smiles

• 특히 'Inexperienced User'에 집중

• Visual Cue, Graphical UI (ex, toolbox, Menu bar....) + Documentation 이 고려됨 (Help text, 가이드- 온라인 튜토리얼, Animated Demonstration)

4.3. Information 시나리오


information model that is spatial, applying the concepts of rooms, furniture, and so on as apervasive metaphor. Both also borrow from the other more specific metaphors describedabove—for example there is a bookshelf that organizes reviews and discussions, there arenotices and other artifacts posted on the walls, the participants form groupings and are inconversation. However, the technology supporting each scenario is quite different, in onecase, consisting of a traditional text-based MUD, and in the second, providing a graphicalrendition of the underlying spatial model.

Either of the information designs could be used to represent an online club space,but the two proposals have rather different implications for how club members are likely toexperience the space. In the first case, all attention will be directed at a sometimescomplex stream of descriptive text. The experience is rather like reading a book or a play,with different people and objects providing the content, but much of the mental experienceunder the control of the reader. In contrast, the graphical view offers a concrete renditionof the space, and the attention of the participant is instead directed toward a specificactivity, in this case a shared discussion of a new review.

Textual descriptions of people and objects present in an online space

+ focus participants’ attention on a single source of information about the situation and events

+ leverages club members’ experience and enjoyment with fantasy-producing textual imagery

− but the interleaving many sorts of descriptions and communications may become quite complex

− but it may be impossible to integrate individual text-based fantasies into a coherent mental model

Two-dimensional visual depictions of people and objects present in an online space

+ leverages club members’ familiarity and habits with real world places and objects

+ enables parallel processing of spatially-distributed information

+ allows participants to use spatial cues in organizing activities (e.g., position in review, location of chat area)

− but club members may feel restricted by the constraints of a two-dimensional space

− but objects or people distributed in the space may distract from the activity in focus

Table 11: Claims contrasting usage implications of the alternative information designs

These general implications are captured in the claims presented in Table 11. As forthe earlier design claims, these arguments do not mandate one choice over another, ratherthey provoke discussion of each alternative’s pros and cons. In this illustrative example weelect to pursue the graphical view rather than the text-based view, largely because itsimplifies the comprehension and participation process. However, we note an importantnegative consequence, that the “real world” view of the pub architecture and contents maydampen the creativity or fantasy of members’ contributions. This may become an issue asdesign continues, for example we may search for ways to suggest a hybrid approach,inviting both real world and fantasy content (Cherny, 1995).

Information design comprises all aspects of how the task information is organizedand rendered during users’ activities. In most design projects, this will include payingspecial attention to the needs of new or inexperienced users. For instance, suppose that thiswas Sharon’s first visit to the online club. How would she know that the bookshelf held


A. Sharon goes to the Science Fiction Club’s room in the community MOO

<Sharon’s background and goal to share her Zeroth Law theory>

When she logs onto a computer, she first checks her email in-box, and sees several emails marked with a dotindicating that they are new; a quick read of the senders confirms that they are from club members proposing andresponding to views on this book. She opens the first one, knowing that it will contain a convenient link to theClub’s online room. She is taken to their regular discussion spot, and she skims the familiar description of thebar. She grins to see a new seating option someone has added, a snailshell-toadstool combination, and seatsherself at this spot; she is told that she is “reclining in a luxurious curl” and ready to join in the activities. Shealso notes a new exit leading to a “Fractal Immersion Room”, and makes a mental note to visit later. Finally, thewelcoming text stream concludes with its usual status report, informing her that Sara, Bill, and Jennifer are in thepub, that Jennifer has just added a new review to the bookshelf, and that this review is currently in the possessionof Bill.

Text messages from her friends begin appearing, including a quick interleaved hello from Bill, before hecomments on a point Jennifer made in her review. Sharon thinks Bill might be mistaken, but before joining in,she asks Bill if she can pick up the review so that she too can read Jennifer’s comments. She finds the issue Billis debating and sees that she agrees with Jennifer, so she eagerly jumps in to take her side against Bill and Sara.In a few minutes, the chat moves on to plan a group outing that night. She has to study, so she drops out of theconversation to create a new discussion with her theory about the Zeroth Law. After she issues the commands toinstantiate the discussion and then types in a provocative starting premise, the system reports to the group that anew discussion has been added, and that an email announcement has been sent to the club mailing list.

<The discussion of Sharon’s proposed new topic, her resolution to read the “Brain Evolution” titles>

B. Sharon goes to the Science Fiction Club’s room in the collaborative environment


When she logs onto a computer, she first checks her email in-box, and sees several emails marked with a dotindicating that they are new; a quick read of the senders confirms that they are from club members proposing andresponding to views on this book. She opens the first one, knowing that it will contain a convenient link to theClub’s online room. She is taken to their regular discussion spot, and she sees the familiar panoramic image ofEastenders Pub, with the mirror and bar prints on the wall, the wooden brass-trimmed bar, and the red canvas barstools. Miniature images of her friends Bill, Sara, and Jennifer are also there, positioned in a close group at oneend of the bar. On the club’s special bookshelf, she sees all of the reviews and discussions contributed recently,organized as usual by name of author. As usual, the reviews appear as simple text documents, while discussionsappear as indented lists. One review on a middle shelf is highlighted in yellow, telling her that this is new sinceshe last visited. She guesses that this review may be what the others are discussing in the chat area, so she opensit to see what all the excitement is about. When she does, she can see that the other three also have the reviewopen, in fact she can see from their named pointers exactly the passage that they are discussing. She finds thatshe agrees with Jennifer in this case, and eagerly jumps in to take her side in the argument.

In a few minutes, the chat moves on to plan a group outing that night. She has to study, so she drops out of theconversation to create a new discussion with her theory about the Zeroth Law. She uses the room toolbox tocreate a new discussion object, indicates that this concerns Asimov’s Robots and Empire, and adds a provocativeopening premise about the Zeroth Law. When finished, the discussion object is positioned automatically on thetop shelf and given a bright yellow color. She is also provided feedback indicating that an announcement hasbeen sent to the club mailing list.


Table 10: Alternative information designs for the online club meeting scenario

Two alternative information designs are presented in Table 10. For simplicity justthe central actions making up the discussion have been elaborated. Both scenarios offer aview into a virtual room that contains club members and documents. Both assume an

ex)•room•welcoming text stream•spot•link•chat system

4.4. Interaction 시나리오

Information 시나리오를 통해 시스템에 들어갈 UI 구성 요소와 구조가 정해지고 난 후

(Problem 시나리오 -> Activity 시나리오 -> Information 시나리오-> )

• Interaction 시나리오

• 각각의 시스템 요소들과 사용자가 어떤 조작 방식을 통해 Interaction하게 될 것인지 고려하는 단계

• 예시 ) direct manipulation (double-click to open) VS a less direct command-oriented manipulation (select and apply a menu command)

• 주요 Activity와 관련된 Interaction은 수 없이 반복될 것이기 때문에 특히 주의를 기울어야 함

• 다양한 조작/Interaction 방식의 대안을 발굴하고 분석함으로써 사용의 용이성, Learnability, User control, 정확도 등을 향상시킴

• 어떤 Interaction 방식 이든 Trade-off가 존재함

• 예시) 직관성 VS User 자유도

• Direct manipulation techniques : simple, familiar, and pervasive, but can limit functionality

• Menu system: flexible and extensible, but Unfamiliar and hard to learn

4.4. Interaction 시나리오


A. Sharon goes to the Science Fiction Club’s room in the collaborative environment


<Sharon arrives in the bar, sees that her friends are talking about a new review>

Sharon wants to open the review to see what all the excitement is about. She moves her mouse pointer to thebright yellow icon and clicks twice. A separate window entitled “Jennifer’s Review” opens to the side, coveringthe other icons on the bookshelf. Sharon is automatically positioned at the same location as Sara in the reviewtext; she knows from experience that this means that Sara made the last comment in the chat area. This irritatesher for a minute, because she wanted to see what Bill was talking about, not Sara, but she quickly finds out whereBill is positioned via his colored rectangle in the scroll bar, and moves to share his view.

<Sharon participates in the argument, then creates her new discussion object>


B. Sharon goes to the Science Fiction Club’s room in the collaborative environment


<Sharon arrives in the bar, sees that her friends are talking about a new review>

Sharon wants to open the review to see what all the excitement is about. She moves her mouse pointer to thebright yellow icon and clicks the right button to bring up the menu. She recognizes the list of review-specificaction choices, and selects the second item (join) rather than the first one (browse). A separate window opens tothe side, covering the other icons on the bookshelf. Sharon is automatically positioned at the same location asSara in the review text; she knows from experience that this means that Sara made the last comment in the chatarea. This irritates her for a minute, because she wanted to see what Bill was talking about, not Sara, but shequickly finds out where Bill is positioned via his colored rectangle in the scroll bar, and moves to share his view.

<Sharon participates in the argument, then creates her new discussion object>


Table 12: Alternative interaction designs for opening the review as part of the online club meeting

scenario.

The two scenarios convey some of the tradeoffs in deciding whether to providemenu-based interaction with task objects. The support of direct manipulation builds on thepervasive use of such interaction techniques in modern interactive software. But the what-if reasoning applied to this scenario pointed to some usage situations that are not well-supported by this simple technique. What if Sharon did not know the others and did notwant to join in on the discussion? What if she wanted to get a quick (private) sense of theissues were before joining the group? A command-based interaction (i.e., through acustomizable menu system) offers more possibilities for user control, but at the cost ofadding more steps to the detailed interaction (see Table 13). Developing and analyzingthese alternatives helped us as designers to think through the relative benefits of ease ofexecution versus user control and flexibility.


Double-clicking to open the object represented by a visual icon

+ leverages users’ general experience with graphical user interfaces

+ promotes a feeling of direct interaction with the object represented by the icon

− but the semantics of the double-click may be hidden, and vary as a function of the object that is opened

Selecting and then requesting a menu to open the object represented by a visual icon

+ makes explicit the command that is being addressed to the object represented by the icon

+ creates an opportunity to choose among multiple object-appropriate actions

− but the selection-then-choice operation may seem tedious for frequent actions

− but the menu list of options must be perceived and interpreted and slow down the interaction

− but selecting and addressing a command creates a level of indirection (thus distance) in goal mapping

Table 13: Claims that capture some of the tradeoffs associated with alternate interaction techniques

Note that this concrete and specific interaction design detail has broad implicationsfor what users are able to do with this system. Direct manipulation techniques are simple,familiar, and pervasive, but can limit functionality: different science club documents mayimplement different meanings of “open”, but they will not offer any other options forinteraction. In contrast, a menu system is flexible and extensible, even to the extent ofadmitting new kinds of function for club artifacts not yet invented. We recognized theseissues by exploring this scenario and its variants—during claims analysis we consideredscenario variants in which other object-specific functions could be useful, ultimatelyleading us to choose the more complex menu-based interaction technique. This exampledemonstrates how even small details can have important consequences for the activitiesbeing envisioned and supported; in SBD, the scenario context ensures a continuous focuson activities, even during detailed interaction design.

In the science fiction club example, we have considered and incorporated standarduser interaction technology—the familiar WIMP paradigm of windows, icons, menus, andpointing. However, SBD can also be used to envision and analyze the implications of morenovel user interaction paradigms and devices. For example, we might consider a role forintelligent agents as part of a new user scenario, and contrast this to a scenario involvingcommunity-generated FAQ (frequently asked questions) repository. Or we could explorethe implications of gesture or speech recognition in lieu of (or as a complement to)conventional keyboard and mouse input devices. A key advantage of exploring these ideaswithin a scenario context is that designers are less likely to be caught up in the newtechnologies for their own sake; the method leads them to try out their new ideas in usagesituations that at the least are believable, and that are analyzed explicitly with respect tousability consequences. More detailed examples of SBD activities focused on emerginginteraction paradigms are discussed in Rosson & Carroll (2001b).

4.5 Usability Evaluation

In SBD, we assume that usability evaluation takes place early and throughout the designand development process. Any representation of a design can be evaluated. Figure 1emphasizes a phase of evaluation that takes place after detailed user interaction scenarios

ex)•move mouse pointer•click twice •positioned •made the text input

4.5. Usability Evaluation시나리오 베이스 디자인은 디자인 및 개발의 전 단계에 걸쳐 Evaluation이 이루어 짐 (Claim 분석을 통해)

Usability Evaluatio 단계에서는 비교적 formal한 Usability Testing이 이루어진다.

Interaction 시나리오를 통해 시스템과 사용자 간의 Interaction 방식이 정해지고, 주요 Activity를 수행할 수 있는 수준의 Working Prototype이 개발 된 이후

(Problem 시나리오 -> Activity 시나리오 -> Information 시나리오-> Interaction 시나리오-> )

• Operational 기능 뿐만 아니라, UI요소, Interaction 방식이 구현된 Prototype이 필요

• 평가를 위해 Usability Specification이 정의 되어야 함

• 명료한 Usability Objectives 제공

• Usability Specification의 구성 요소

• Task Context : 현실성 있는 환경, 상황 등을 조성

• Subtask : 각각의 User goal 및 그에 수반된 Activity, 주요 기능 단위

• Target Usability Outcomes/ Measure : Subtask가 의도한 대로 잘 기능하는지 판단할 수 있는 지표 및 평가 방식

• 사용자의 Percaption/Acceptance/Satisfaction 레벨이 일정 수준 이상이 되어야 함

4.5. Usability Evaluation










Problem scenarios

summative

evaluation


claims aboutcurrent

practice


field studies


Activity

scenarios




re-design



guidelines

formative

evaluation

DESIGN

ANALYZE


4.5. Usability Evaluation-Usability Specification


Task context: Sharon is a busy university student and a regular member of the science fiction club. During afew free minutes she sees from her email that new discussions have begun at their online club room. She joinsthem, planning to share her new idea about her favorite Asimov novel when there is a break in the conversation .

Overall scenario outcome:

Average rating of at least 4.0 (of 5) on ease of use and satisfaction

Subtask 1: Navigate to the online club room

Subtask 2: Identify present club members

Subtask 3: Identify and open Jennifer’s review

Subtask 4: Locate and join Bill in review

Subtask 5: Create new discussion object

Performance Targets

20 seconds, 0 errors

5 seconds, 1 error

10 seconds, 0 errors

15 seconds, 1 error

60 seconds, 1 error

Satisfaction Targets

4 on convenience

4.5 on presence

4 on directness

0.5 on confusion

4.5 on feedback

Table 14: Usability specification developed from the science fiction club scenario

When the prototype is robust enough to measure subtask times, more detailedusability specifications guide empirical testing. In the example, a set of five simplesubtasks has been analyzed from the user interaction scenario. These tasks are directlyrelated to claims that have been developed for key design features (only some of theseclaims have been documented here). Performance measures are established, based eitheron the designers’ own (expert) experiences with the prototype, or on benchmark datacollected from comparable systems. Satisfaction measures are constructed to assess one ormore of the specific concerns raised in the claims. For example, a negative consequence ofmenu-based interaction is that it may reduce feelings of directness. The usabilityspecification tracks this issue by requiring that users’ perception of this quality be at anacceptably high level (as operationalized by a Likert-type rating scale with a range of 1-5).The satisfaction qualities specified for the other subtasks were similarly derived fromadvantages or disadvantages hypothesized by claims.

Usability specifications developed in this way have two important roles inevaluation. First, they provide concrete usability objectives that can be serve as amanagement tool in system development—if a product team accepts these targets, then theteam’s usability engineers are able to insist that redesign and improvement continue untilthey are met (Carroll & Rosson, 1985; Good et al., 1986).

Second, the specifications tie the results of empirical evaluation directly to theusability issues raised during design. For instance, our interaction design scenariospecified that Sara determines Bill’s position from his colored rectangle in the scroll bar(see Table 12). A positive consequence is that awareness of others’ and their activities isenhanced; a negative consequence is that the display becomes more crowded. The time ittakes to locate Bill is specified as one measure of the feature’s impact, but this performancetarget is complemented by users’ subjective reactions to the feature. For example usersmight indicate level of agreement to a statement such as: “The scroll bar with rectanglesindicating others’ positions was confusing”. Problematic results with respect to either ofthese usability targets raise specific issues for redesign.

• Satisfaction Target : 5점 척도 measure 평가 (편리성, presence, 조작성, 피드백 등등) 및 인터뷰

• Performance Target : 시간, Click 수, 에러, 관찰 등

Usability Evaluation을 통해 도출된 문제적인 Result -> Redesign 프로세스에 직접적인 영향을 미침

5. Scenarios throughout System Life Cycle


Figure 2: Scenarios have diverse uses throughout system development life cycle

Even if scenarios are not developed and transformed as described in the SBDframework, they may be used at many points along the way. For instance, task-based userdocumentation is often structured by scenarios. Minimalist help and training provide manyexamples of this, such as a “training wheels” system that blocks functions that are notrelevant to a paradigmatic novice-use scenario (Carroll & Carrithers, 1983), or a “viewmatcher” that guides new programmers through a predefined scenario of debugging andmodification (Carroll, Singer, Bellamy, & Alpert, 1990; Carroll & Rosson, 1991; Rosson &Carroll, 1996).

Usage scenarios have also come to play a central role in object-oriented softwareengineering (Jacobson, 1995; Jacobson, Booch, & Rumbaugh, 1998; Rubin & Goldberg,1992; Wirfs-Brock et al, 1990). A use case is a scenario written from a functional point ofview, enumerating all of the possible user actions and system reactions that are required tomeet a proposed system function (Jacobson, et al. 1992). Use cases can then be analyzedwith respect to their requirements for system objects and interrelationships. Wirfs-Brock(1995) describes a variant of use case analysis in which she develops a “user-systemconversation”: using a two-column format, a scenario is decomposed into a linearsequence of inputs from the user and the corresponding processing and/or output generatedby the system. Kaindl (2000) extends this analysis by annotating how scenario stepsimplement required user goals or system functions.

Scenarios are promising as a mediating representation for analyzing interactionsbetween human-centered and software-centered object-oriented design issues (Rosson &Carroll, 1993; 1995). As we have seen, scenarios can be decomposed with respect to thesoftware objects needed to support the narrated user interactions. These software objects

usability specificationfunctional specification

UI metaphor

design rationale

object model

system vision

formative evaluation

summative evaluation

documentation,

training & help

design objects,

responsibilities, and

collaborators

system functions

required to realize

scenario actions

appearance and

behavior of data and

controls

specific goals for

user performance,

satisfaction, etc.

consequences for

stakeholders;

underlying issues

and models

root concepts

and motivation

assess with

respect to final

goals and state of

the art task-oriented

information and

support artifacts

assess project progress

toward design goals; alter

project direction and/or

goals

prototypemock-ups, scripts,

partial implementations

task scenario

requirementscustomer/user

needs; design goals

5. Scenarios throughout System Life Cycle


Figure 2: Scenarios have diverse uses throughout system development life cycle

Even if scenarios are not developed and transformed as described in the SBDframework, they may be used at many points along the way. For instance, task-based userdocumentation is often structured by scenarios. Minimalist help and training provide manyexamples of this, such as a “training wheels” system that blocks functions that are notrelevant to a paradigmatic novice-use scenario (Carroll & Carrithers, 1983), or a “viewmatcher” that guides new programmers through a predefined scenario of debugging andmodification (Carroll, Singer, Bellamy, & Alpert, 1990; Carroll & Rosson, 1991; Rosson &Carroll, 1996).

Usage scenarios have also come to play a central role in object-oriented softwareengineering (Jacobson, 1995; Jacobson, Booch, & Rumbaugh, 1998; Rubin & Goldberg,1992; Wirfs-Brock et al, 1990). A use case is a scenario written from a functional point ofview, enumerating all of the possible user actions and system reactions that are required tomeet a proposed system function (Jacobson, et al. 1992). Use cases can then be analyzedwith respect to their requirements for system objects and interrelationships. Wirfs-Brock(1995) describes a variant of use case analysis in which she develops a “user-systemconversation”: using a two-column format, a scenario is decomposed into a linearsequence of inputs from the user and the corresponding processing and/or output generatedby the system. Kaindl (2000) extends this analysis by annotating how scenario stepsimplement required user goals or system functions.

Scenarios are promising as a mediating representation for analyzing interactionsbetween human-centered and software-centered object-oriented design issues (Rosson &Carroll, 1993; 1995). As we have seen, scenarios can be decomposed with respect to thesoftware objects needed to support the narrated user interactions. These software objects

usability specificationfunctional specification

UI metaphor

design rationale

object model

system vision

formative evaluation

summative evaluation

documentation,

training & help

design objects,

responsibilities, and

collaborators

system functions

required to realize

scenario actions

appearance and

behavior of data and

controls

specific goals for

user performance,

satisfaction, etc.

consequences for

stakeholders;

underlying issues

and models

root concepts

and motivation

assess with

respect to final

goals and state of

the art task-oriented

information and

support artifacts

assess project progress

toward design goals; alter

project direction and/or

goals

prototypemock-ups, scripts,

partial implementations

task scenario

requirementscustomer/user

needs; design goals

튜토리얼 개발

마케팅Object-Oriented

개발

사용자 모델링

6. Conclusion

• 시나리오 : 의미있는 usage episodes의 서술

• 시나리오베이스디자인은

• to understand and to create "computer systems and applications "

• as artifacts of human activity,

• as things to learn from,

• as tools to use in one’s work,

• as media for interacting with other people.

6. Conclusion && Discussion

• 경험적 데이터와 연구자 / 디자이너의 직관을 의미있는 데이터 및 시스템으로 Translate하는 과정

• 사람들은 기본적으로 Story를 좋아해

• 팀 커뮤니케이션 + Progress 점검

• 각 단계별 구분의 모호함....

• 메타포 개념

• 메타포의 메타포화/재매개

• ex. UI 디자인 패턴, WIMP -> Touch Interface

!

?

감사합니다 :)