시나리오 베이스 디자인 방법론 (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

시나리오 베이스
디자인
Reference
Scenario-Based Design
Mary Beth Rosson and John M. Carroll
Department 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

• 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.BasicConcept
• 시나리오란?
• “시나리오란 사람들과 그들의 행동에 대한 이야기” [Carroll, 1999]
• 시나리오의 기본 구성 요소
• Setting
• 각각의 에피소드에 시작 상태
• 이는 서술된 상황과 관련이 있는 대상들에 대한 서술도 포함
• Actors (or Agents):
• 해당 시나리오와 관련된 사람들
• Agent’s Goals (or objectives):
• Agent(System)이 Setting의 환경에 변화를 주고자 하는 것
• Plot
• Actor와 시스템에 의해 벌어지는 일련의 이벤트와 행동의 결합으로 시나리오 내의
Setting에 변화나 영향을 줌
1.기본개념

1.BasicConcept
• 시나리오의 예시
1 0/1 9/07V incenzo.P allotta@ unifr.ch6
Scenario Example
Harry 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 first
sway, then ripple, and ultimately lurch apart.
He quickly replays the film, and then opens the associated course
module on harmonic motion.
He browses the material (without doing the exercises), saves the film
clip in his workbook with a speech annotation, and then enters a
natural language query to find pointers to other physical
manifestations 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.시나리오베이스디자인이좋은이유-SolutionFirstApproachalternatives, or to raise questions about the assumptions behind the scenarios. They can be
used to analyze software requirements, as a partial specification of functionality, and to
guide the design of user interface layouts and controls. They can be used to identify and
plan 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 they
enable rapid communication about usage possibilities and concerns among many different
stakeholders. It is easy to write simple scenarios such as those in Table 1, and takes only a
little more effort to enrich it with a rough sketch or storyboard. When designers are
working through ideas, they want to make progress quickly, so that they can obtain
feedback 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 tend
to evoke a problem-solving strategy termed solution-first (Cross, 2001). In the solution-first
strategy, designers generate and analyze a candidate solution as a means of clarifying the
problem state, the allowable moves, and the goal. They exploit the concreteness of their
own 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 approach
quickly, which may lead to premature commitment
to their first design ideas
Because they are concrete but rough, scenarios
support visible progress, but also relax commitment
to the ideas expressed in the scenarios
Designers attempt to quickly simplify the problem
space with external constraints, such as the reuse of
familiar solutions
Because they emphasize people and their
experiences, scenarios direct attention to the use-
appropriateness of design ideas
Designers are intent on elaborating their current
design proposal, resulting in inadequate analysis of
other ideas or alternatives
Because they are evocative and by nature are
incomplete, scenarios promote empathy and raise
usage questions at many levels
Table 2: Concerns stemming from the solution-first approach to design, and aspects of scenario-based

• “Representational Bias”
• 인지 심리학 개념으로 친숙한 대상과의 연관성/중요도을 극대화 해서 평가하는 경향(Kahneman
& Tversky 1972; Tversky & Kahneman, 1974).
• 시나리오 베이스 디자인을 통해 자신의 경험, 인상에 근거한 판단을 지양하고 새로운 생각과
발상을 유도할 수 있게 됨
• “We are all Storytellers”
• 스토리 텔링 : 다양한 사람들의 다양한 생각을 Context 속에 녹여 낼 수 있게 함
• 이미지의 환기
• 사람들의 상황에 감정이입 -> 질문던지기
• 사람들의 행동 / 목표 / 기술
• 사람들의 동기, 의도, 반응, 만족
3.시나리오베이스디자인이좋은이유-RepresentationalBias

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 of
iterative design. Design envisionment is inspired by metaphors and technology options,
Problem scenarios
summative
evaluation
Information scenarios
claims about
current
practice
analysis of
stakeholders,
field studies
Usability specifications
Activity
scenarios
Interaction scenarios
iterative
analysis 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 about
current
practice
analysis of
stakeholders,
field studies
Activity
scenarios
iterative
analysis of
usability
claims and
re-design
metaphors,
information
technology,
HCI theory,
guidelines
formative
evaluation
DESIGN
ANALYZE

4.1Analysize-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 guide
further 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
Functional
(Thoughts/Goal)
NONFunctional
(Context)
• Problem 시나리오
• 전통적인 의미의 'Requirement'는 아님 - 필요한 시스템 기능의 열거가 아님
• 개발 전 과정에 있어 가장 중요한 '기준'을 설정하는 단계
• 개발 시작 단계에서 Needs와 Opportunity와 관련된 요소들을 확인함
• 현재의 활동을 분석해내는 데 집중함
• 조사 방법 : Fieldwork, Activity Artifact (Stakeholder's value & activities)
• 정리 방법 : Afﬁnity Diagram / Stakeholder Relationship / Hierarchical Task Analysis ->
Key Theme 도출
• Problem Scenario의 구성
공통
기술낙관적 가정
개개인
환경 / 개인

4.1Analysize-Problem시나리오
Sharon is a busy third-year psychology student at Virginia Tech. Even though she has a biology exam tomorrow
morning, she has been looking forward to her science fiction club meeting for several days, so she decides to go
and stay up late to study when she gets back. She remembers that they were planning to talk about Asimov’s
Robots 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 from
dinner with her room-mate, so she misses her regular bus and arrives 15 minutes late. The meeting is already
underway; she notes that they have a relatively small group tonight, but is happy to see Bill and Sara, who are the
real experts on Asimov. She is even more delighted to see that these two are already having a heated discussion
about the Zeroth Law. But she is cannot immediately tell what points have been made, so she sits back a while to
catch the drift of the conversation. At a break, Bill greets her and asks her what she thinks about Faucian’s
insight. She replies that she isn’t sure about how central he is to the plot, but that she has a new theory about the
timeline. 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
Sharon is a busy third-year psychology student at Virginia Tech. Even though she has a biology exam
morning, she has been looking forward to her science fiction club meeting for several days, so she de
and stay up late to study when she gets back. She remembers that they were planning to talk about A
Robots 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 bac
dinner with her room-mate, so she misses her regular bus and arrives 15 minutes late. The meeting i
underway; she notes that they have a relatively small group tonight, but is happy to see Bill and Sara
real experts on Asimov. She is even more delighted to see that these two are already having a heated
about the Zeroth Law. But she is cannot immediately tell what points have been made, so she sits ba
catch the drift of the conversation. At a break, Bill greets her and asks her what she thinks about Fau
insight. She replies that she isn’t sure about how central he is to the plot, but that she has a new theo
timeline. 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
Problem
시나리오
Claim
분석
'각각의 시나리오에 나타난 특징
들에 의해 인과관계로 나타날 것
이라 예상되는 각각의 요소'
들을 긍정적 (+) / 부정적 (-)인
측면 으로 나누어 분석

4.1Analysize-Claim분석
Claim 분석은 다른 시나리오 / 단계에서도 모두 반복되는 과정
Actor들의 경험에따라 규정될 각각의 기능 / 특징 / 환경등을 확인하고 분석하는 과정
(평가자의 기대와 편견에 따라 좌우될 여지가 큰) 분석적인 접근
• Claim 분석이 필요한 이유
• "What if" - 사용자와 감정이입
• 서로 다른 시나리오의 측면들을 부분적으로 취할 수 있게 되어 (긍정적인 부분만) 다양한 대안 도출 가능
• 긍정적이면서 부정적인 부분 둘 다 고려하는 균형적인 시야를 가질 수 있도록 함
• 특히 Requirement 분석 과정에서 현재 상황의 부정적인 측면 (Breakdown, Contradiction)에만 치중하는 경
향이 있음
• 문제점 뿐만 아니라 새로운 '기회', '가능성'을 보기 위해서는 현재의 상황에서 이미 잘 이루어지고 있는 것에도 집중해
야 함
• 이는 현재의 환경에 어떤 변화가 있게 될 때 (시스템이 도입되었을 때)의 '부작용'을 미리 예상해 볼 수 있게 함
....
시나리오
Claim Analysis
Pros / Cons

4.2.Activity시나리오-DesignSpace
Stakeholder가 처한 상황과 그들의 요구를 충분히 이해하고, Speciﬁc한 디자인 제언을 준비를 시작 수
있게 되었을 때 (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 개발 측면에서
• 현재 사용가능한 기술과
• 그가 솔루션에 기여할 수 있는 바를 검토해 볼 수 있음

with the hope that users will recruit them in reasoning by analogy about what a system does
or how it works (Carroll & Thomas, 1982; Carroll, Mack, & Kellogg, 1988; Madsen,
1994). Here we emphasize the role of metaphors in helping designers “think outside the
box” (Erickson, 1990; VerPlank, 1988). Addressing real world activities and concerns is
crucial to effective system design, but it is often metaphoric thinking that promotes the
insights 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 the
metaphoric thinking. In a sense, the technology provides another set of metaphors for
thinking about the activities to be supported, but in this case the analogy is with classes of
Metaphor
Available
Technology

4.2.Activity시나리오
• Activity 시나리오 : 새로운 시스템의 도입으로 사람들의 Activity에 일으킬 변화와 기술의 활용에
대한 솔루션 Idea
• 수 많은 대안 중 어떤 것을 골라야 할까?
• (현실적인) 판단 기준 : 현재 사용되고 있는 서비스, 팀원들의 전문성, 개발 자원, 조직 목표
• 그래도 고르기 힘들다면?
• Participation Design Session (Co-Design)
• Claim 분석Rosson & Carroll: SBD 17
Before leaving, Sharon backs up to the homepage and browses the book categories to look for new books and
discussions. Right underneath her favorite category of “Artificial Intelligence” (where the Asimov series is
placed), she discovers an intriguing new entry, “Brain Evolution”. She doesn’t recognize any of the authors in
this 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 take
advantage of her free time between classes. In her hour between her morning classes, she stops by the computer
lab 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 emails
from club members proposing and responding to views on this book. But rather than read each email, she
follows the convenient link to the Club’s online room. She is taken to their regular discussion spot, the bar of a
local 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 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 the conversation to create a new discussion with her theory about the Zeroth Law. She
sees 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 he
has a new “Brain Evolution” grouping he is working on. She hasn’t heard of the titles he mentions, so she sends
herself 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 library
metaphors. It emphasizes social exchange and informal conversation, as well as responses
to an assortment of club-specific artifacts in the space. Sharon is able to see which of her
fellow members are around, and can follow the conversation but also carry out her own
exploration in parallel. She jumps in and out of the conversation as her interest in the topic
increases or decreases. The club members are engaged in activities that refer to artifacts on
display in their room—discussion topics and a bookshelf that displays book titles
categorized by theme.

4.2.Activity시나리오-Claim분석
design features are considered through “what if” discussions.
A sample claim analyzed from each scenario appears in Table 9. In this illustrative
example, the scenarios were intentionally written to be very similar in many respects; the
claims capture one of the basic design contrasts built into the alternative designs. The Web
site offers a convenient hierarchical listing of topics, whereas the online room holds a
number of different “objects” that people discuss in real time. The analysis helps the
designers to see the relative advantages and disadvantages of an organized asynchronous
interaction and a more ad hoc synchronous exchange. Such an analysis may or may not be
enough to mandate one alternative over the other. But at the least it begins to lay out usage
issues 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.
솔루션의 도입으로 본질적으로 강화 / 변화시키고자 하는 사람들의 행위 규정
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-speciﬁc 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 a
pervasive metaphor. Both also borrow from the other more specific metaphors described
above—for example there is a bookshelf that organizes reviews and discussions, there are
notices and other artifacts posted on the walls, the participants form groupings and are in
conversation. However, the technology supporting each scenario is quite different, in one
case, consisting of a traditional text-based MUD, and in the second, providing a graphical
rendition 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 to
experience the space. In the first case, all attention will be directed at a sometimes
complex 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 experience
under the control of the reader. In contrast, the graphical view offers a concrete rendition
of the space, and the attention of the participant is instead directed toward a specific
activity, 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
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 dot
indicating that they are new; a quick read of the senders confirms that they are from club members proposing and
responding to views on this book. She opens the first one, knowing that it will contain a convenient link to the
Club’s online room. She is taken to their regular discussion spot, and she skims the familiar description of the
bar. She grins to see a new seating option someone has added, a snailshell-toadstool combination, and seats
herself at this spot; she is told that she is “reclining in a luxurious curl” and ready to join in the activities. She
also notes a new exit leading to a “Fractal Immersion Room”, and makes a mental note to visit later. Finally, the
welcoming text stream concludes with its usual status report, informing her that Sara, Bill, and Jennifer are in the
pub, that Jennifer has just added a new review to the bookshelf, and that this review is currently in the possession
of Bill.
Text messages from her friends begin appearing, including a quick interleaved hello from Bill, before he
comments 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 Bill
is 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 the
conversation to create a new discussion with her theory about the Zeroth Law. After she issues the commands to
instantiate the discussion and then types in a provocative starting premise, the system reports to the group that a
new 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 dot
indicating that they are new; a quick read of the senders confirms that they are from club members proposing and
responding to views on this book. She opens the first one, knowing that it will contain a convenient link to the
Club’s online room. She is taken to their regular discussion spot, and she sees the familiar panoramic image of
Eastenders Pub, with the mirror and bar prints on the wall, the wooden brass-trimmed bar, and the red canvas bar
stools. Miniature images of her friends Bill, Sara, and Jennifer are also there, positioned in a close group at one
end 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 discussions
appear as indented lists. One review on a middle shelf is highlighted in yellow, telling her that this is new since
she last visited. She guesses that this review may be what the others are discussing in the chat area, so she opens
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: ﬂexible 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 the
bright yellow icon and clicks twice. A separate window entitled “Jennifer’s Review” opens to the side, covering
the other icons on the bookshelf. Sharon is automatically positioned at the same location as Sara in the review
text; she knows from experience that this means that Sara made the last comment in the chat area. This irritates
her for a minute, because she wanted to see what Bill was talking about, not Sara, but she quickly 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>
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 the
bright yellow icon and clicks the right button to bring up the menu. She recognizes the list of review-specific
action choices, and selects the second item (join) rather than the first one (browse). A separate window opens to
the side, covering the other icons on the bookshelf. Sharon is automatically positioned at the same location as
Sara in the review text; she knows from experience that this means that Sara made the last comment in the chat
area. This irritates her for a minute, because she wanted to see what Bill was talking about, not Sara, but she
quickly 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.
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
ex)
•move mouse
pointer
•click twice
•positioned
•made the text
input

4.5.UsabilityEvaluation
시나리오 베이스 디자인은 디자인 및 개발의 전 단계에 걸쳐 Evaluation이 이루어 짐 (Claim 분석을 통해)
Usability Evaluatio 단계에서는 비교적 formal한 Usability Testing이 이루어진다.
Interaction 시나리오를 통해 시스템과 사용자 간의 Interaction 방식이 정해지고, 주요 Activity를 수행할 수
있는 수준의 Working Prototype이 개발 된 이후
(Problem 시나리오 -> Activity 시나리오 -> Information 시나리오-> Interaction 시나리오-> )
• Operational 기능 뿐만 아니라, UI요소, Interaction 방식이 구현된 Prototype이 필요
• 평가를 위해 Usability Speciﬁcation이 정의 되어야 함
• 명료한 Usability Objectives 제공
• Usability Speciﬁcation의 구성 요소
• Task Context : 현실성 있는 환경, 상황 등을 조성
• Subtask : 각각의 User goal 및 그에 수반된 Activity, 주요 기능 단위
• Target Usability Outcomes/ Measure : Subtask가 의도한 대로 잘 기능하는지 판단할 수 있는
지표 및 평가 방식
• 사용자의 Percaption/Acceptance/Satisfaction 레벨이 일정 수준 이상이 되어야 함

4.5.UsabilityEvaluation
Problem scenarios
summative
evaluation
claims about
current
practice
analysis of
stakeholders,
field studies
Activity
scenarios
iterative
analysis of
usability
claims and
re-design
metaphors,
information
technology,
HCI theory,
guidelines
formative
evaluation
DESIGN
ANALYZE

4.5.UsabilityEvaluation-UsabilitySpecification
Task context: Sharon is a busy university student and a regular member of the science fiction club. During a
few free minutes she sees from her email that new discussions have begun at their online club room. She joins
them, 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 detailed
usability specifications guide empirical testing. In the example, a set of five simple
subtasks has been analyzed from the user interaction scenario. These tasks are directly
related to claims that have been developed for key design features (only some of these
claims have been documented here). Performance measures are established, based either
on the designers’ own (expert) experiences with the prototype, or on benchmark data
collected from comparable systems. Satisfaction measures are constructed to assess one or
more of the specific concerns raised in the claims. For example, a negative consequence of
menu-based interaction is that it may reduce feelings of directness. The usability
specification tracks this issue by requiring that users’ perception of this quality be at an
acceptably high level (as operationalized by a Likert-type rating scale with a range of 1-5).
• Satisfaction Target : 5점 척도 measure 평가 (편리성, presence, 조작성, 피드백 등등) 및 인터뷰
• Performance Target : 시간, Click 수, 에러, 관찰 등
Usability Evaluation을 통해 도출된 문제적인 Result -> Redesign 프로세스에 직접적인 영향을 미침

5.ScenariosthroughoutSystem LifeCycle
Figure 2: Scenarios have diverse uses throughout system development life cycle
Even if scenarios are not developed and transformed as described in the SBD
framework, they may be used at many points along the way. For instance, task-based us
usability specification
functional 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
prototype
mock-ups, scripts,
partial implementations
task scenario
requirements
customer/user
needs; design goals

5.ScenariosthroughoutSystem LifeCycle
Figure 2: Scenarios have diverse uses throughout system development life cycle
Even if scenarios are not developed and transformed as described in the SBD
framework, they may be used at many points along the way. For instance, task-based us
usability specification
functional 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
prototype
mock-ups, scripts,
partial implementations
task scenario
requirements
customer/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
!
?

시나리오 베이스 디자인 방법론 (Scenario Based Design)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 시나리오 베이스 디자인 방법론 (Scenario Based Design)

Semelhante a 시나리오 베이스 디자인 방법론 (Scenario Based Design) (20)

Mais de Hajin Lim

Mais de Hajin Lim (10)

Último

Último (20)

시나리오 베이스 디자인 방법론 (Scenario Based Design)