HEC Lausanne > HCI > March 2005 Scenario-Based Design of Interactive Software Université de...

HEC Lausanne > HCI > March 2005

Scenario-Based Design of Interactive SoftwareScenario-Based Design of Interactive Software

Université de LausanneEcole des Hautes Etudes Commerciales (HEC)

Introduction

REQUIREMENTSANALYSIS• scenario-based design• requirements analysis• task modeling

DESIGN• activity design• information design• interaction design

USABILITYEVALUATION• prototyping• usability testing• documentation

Science of design

Table of content

home | agenda | fin

2

Université de Lausanne

© 2005 Pigneur

Usability Engineering

• Mary Rosson and John CarrollUsability EngineeringScenario-based development of human-computer interactionMorgan Kaufmann Publishers. 2002

1. Scenario-based usability engineering2. Analyzing requirements3. Activity design4. Information design5. Interaction design6. Prototyping7. Usability evaluation8. User documentation9. Emerging paradigms for user interaction10.Usability engineering in practice

home | agenda | fin

3


© 2005 Pigneur

http://ucs.ist.psu.edu

Usability case study

home | agenda | fin

4


© 2005 Pigneur

Software engineering

Tradeoff 1.1 [Rosson, 2002] p. 8

A software development “waterfall” helps to manage software development projects, BUT can deprive requirements analysts of critical information that becomes available only later in system development or use

[Rosson and Carroll, 2002]

home | agenda | fin

5


© 2005 Pigneur

Interactive software

Human-computer interfaceBEHAVIOUR

Processing rulesFUNCTION

DatabaseDATA

home | agenda | fin

6


© 2005 Pigneur

Requirement engineering (I) - Data

DatabaseDATA

EMPLOYE DOCUMENT1,N 0,1

access

object

relationship

home | agenda | fin

7


© 2005 Pigneur

Requirement engineering (II) - Function


DatabaseDATA

Check people

Check document

Check security

Record access

Check and record access

action

decompositionencapsulation

home | agenda | fin

8


© 2005 Pigneur

Requirement engineering (III) - Behaviour



DatabaseDATA

Check people

Check document

Check security Record accessAccess request

event

trigger

home | agenda | fin

9


© 2005 Pigneur

Requirement engineering (IV) - Intention


Check people is secure

Record secure access to document

goal decomposition

Check document is available

Check people has right to access document


home | agenda | fin

10


© 2005 Pigneur

Prototyping and iterative development


Prototyping encourgaes iteration in software development, BUT may leads to inefficiency or local optimization of software


home | agenda | fin

11


© 2005 Pigneur

Usability in software development

• Quality of system with respect to ease of learning, ease of use, and user satisfaction

Human performanceTime, and errors

Collaboration groupDynamics, and

Workplace context

Human cognition,Mental models of plans,

and actions

USABILITY


home | agenda | fin

12


© 2005 Pigneur

Usability and human-computer interaction

• From quality of finished systems– Usability testing lab

• To a comprehensive process– continual prototyping

– thinking-aloud evaluation

– regular user involvement in requirement analysis and design

• Addressing the social and organization context in which people learn and use computers

Human performanceHuman-computer interaction

Computer-supported cooperative work[Rosson and Carroll, 2002]

home | agenda | fin

13


© 2005 Pigneur

Usability engineering

• Concepts and techniques for planning, achieving, and verifying objectives for system usability

• Measurable usability goals must be defined early in software development, and then assessed repeatedly during development

• Ultimately, software development is driven by economics

• Impact of other constraints (non functional requirements) on usability:– Team membership– Project size– Legacy systems– Portability– Reliability– Maintainability– Software economics


home | agenda | fin

14


© 2005 Pigneur

Scenario-based usability engineering

• Assumption:the descriptions of people using technology are essential in discussing and analyzing how the technology is reshaping their activities

• SCENARIOA story about people and their activities– ACTOR: Who is the story about?

– GOAL: Why did the story happen?

• Highlights– goals suggested by the appearance and the behaviour of a system

– What people try to do with the system

– What procedure are (not) adopted, carried out (un-)successfully

– What interpretations people make of what happens to them

SCENARIO | ANALYSIS | DESIGN | EVALUATION | DESIGN SCIENCE

home | agenda | fin

15


© 2005 Pigneur

A problem scenario


home | agenda | fin

16


© 2005 Pigneur

A design scenario


home | agenda | fin

17


© 2005 Pigneur

Scenario elements

• Setting– Situational details that motivate or explain goals, actions, and reactions of the

actor(s)

• Actors– Humans interacting with the computer or other setting elements

• Task goals– Effects on the situation that motivate actions carried out by actors

• Plans– Mental activity directed at converting a goal into a behaviour

• Evaluation– Mental activity directed at interpreting features of the situation

• Actions– Observable behaviour

• Events– External actions or reactions produced by the computer or other features

(some of these may be hidden to the actors but important to scenario)[Rosson and Carroll, 2002]

home | agenda | fin

18


© 2005 Pigneur

Scenario and use case

• In software engineering (object-oriented development), such as UML.A use case– Enumerates the complete course of events that take place given some user input

– Specifies all possible interaction between the user and the system

• A scenario can be seen as one instance of a use case– An execution thread for a particular starting state and set of events

• A use case is a complete description of what the system will do• A scenario specifies functionality too, but in the context of use

– Focus on the design rationale and possible side effects of user-system interactions


home | agenda | fin

19


© 2005 Pigneur

Why scenarios?

• Design and engineering always involve the management of tradeoffs– Difficult to conciliate both goals: Performance Vs. satisfaction


Analyze use butlet it evolveMake decisions but

keep options open

Balance actionwith reflection

Be innovative but only if adding value

Be precise but include everyone on the team

Scenario-based design

1.3

1.4

1.5

1.6

1.7

home | agenda | fin

20


© 2005 Pigneur

Make decisions but keep options open

• Scenarios are concrete descriptions but are also flexible

• Sharing and developing scenarios helps to control the uncertainties of design work, while sharpening and strengthening design goals


Designers are motivated to make progress quickly, BUT premature decisions and commitment can lead to poor solutions


home | agenda | fin

21


© 2005 Pigneur

Analyze use but let it evolve

• Scenarios describe use in detail, but as a tentative, working representation

• Co-evolution– People’s activities

– technology


Analyzing users’ current tasks is essential in designing useful and usable systems BUT new designs change what people can do and how the choose to do it


home | agenda | fin

22


© 2005 Pigneur

Be innovative but only if adding value

• Scenarios focus on the usability consequences of specific design proposals

• Balance– Needs (user-pull)

– Innovation (technology push)


The rapidly evolving software market demands innovation and new features, BUT some functionality may actually undermines usability


home | agenda | fin

23


© 2005 Pigneur

Be precise but include everyone on the team

• Scenarios describe the problem situation using natural language understood by all stakeholders

• Participatory design– Collaboration between developers and the users


Technical design representations can increase the precision of communication, BUT may exclude participations by untrained team members


home | agenda | fin

24


© 2005 Pigneur

Balance action with reflection

• Scenario offer a vivid description of use that provokes questions and “what if” discussions

• Evocative nature of scenarios– Concrete story of user interaction

– Stimulates the imagination

– Encourages what if reasoning about alternatives


Software development provides concrete rewarding evidence of progress, BUT can direct attention away from reflection and analysis


home | agenda | fin

25


© 2005 Pigneur

Scenario-based Development Framework

[Rosson and Carroll, 2002] http://ucs.ist.psu.edu

PROTOTYPINGPROTOTYPING

home | agenda | fin

26


© 2005 Pigneur

Scenario-based design


Problem scenariosAnalysis of

stakeholders,field studies

AnalyzeClaims about

currentpractice

Usability specificationsSummativeevaluation

Formativeevaluation

Prototype and Evaluate

Metaphors,informationtechnologyHCI theoryguidelines

Iterativeanalysis ofUsability

claims andredesign

ActivityScenarios

Information scenarios

Interaction scenarios

Design

home | agenda | fin

27


© 2005 Pigneur SCENARIO | ANALYSIS | DESIGN | EVALUATION | DESIGN SCIENCE


REQUIREMENTS ANALYSIS

• Planning: Scope of the problem• Methods by which to study

– Interviews with stakeholders– Field studies– brainstorming

• Input are gathered and …• … analyzed

– Stakeholder analysis– Task analysis– Participatory analysis

• To formulate scenarios– Raise questions– Evoke reflection and discussion– Facilitate communication

• That convey important characteristics of the users– the typical and critical tasks they engage in, the tools they use, and their organizational

context (Synthesis).– Stimulated by claims

• Statements about the positive and negative impact effects in terms of usability impacts of a design on the user within a particular context of use (a scenario)

home | agenda | fin

28




DESIGN

• the project is movedfrom problem understandingto envisioned solutions

• Explore– HCI concepts, metaphors, technology

• Envisionment– prototypes, scenarios …

• Rationale– design claims and evaluation results

• From problem-scenariosto design-scenarios

home | agenda | fin

29


© 2005 Pigneur


Activity design

• Scenarios-narratives of typical services • that people will seek from the systems

– Focus on functionality

• Exploration of conceptual metaphors– Refraining from specifying details about

– what the system will look like

– Or how users will manipulate it

• Reasoning from problem claims• Participatory design

home | agenda | fin

30


© 2005 Pigneur


Information design

• Information scenarios• Details about information

– provided to the users by the systems

• Exploration of presentation metaphors• Reasoning from activity claims• Screen and icon design

home | agenda | fin

31


© 2005 Pigneur


Interaction design

• Interaction scenarios• Details of user action and feedback

– Users & tasks

– Information needed to carry out tasks

– Actions the users take to interact with the task information

– Response the system provides to user’s actions

• Exploration of presentation metaphors• Reasoning from activity and information claims• storyboards

home | agenda | fin

33


© 2005 Pigneur

PROTOTYPING

• Design ideas have to be evaluated in a continuing fashion

• A prototype implements or demonstrates one or more pieces of the solution proposed in the scenario

• Forms– Key screens

– Sketch

– Paper or software mock-up

– Computer animation

– Scenario machine

home | agenda | fin

34




USABILITY EVALUATION

• Formative evaluation– Carried out to guide re-design and

aimed at improving a design prototype

– What is working poorly?

– Why?

– What changes might fix the problem?

• Summative evaluation– Serves as a overall system verification function

– Have we actually built the systemthat was envisioned and specified?

– Did we meet or exceed the usability goalsquantified in the usability specifications?

home | agenda | fin

35


© 2005 Pigneur

Usability Return on Investment?

http://www.usabilityfirst.com/roi/index.txl

• Improving the usability of a website can increase sales, reduce customer service calls, and increase customer satisfaction and loyalty.

• For internally used software and websites, like intranets and timesheets systems, improving usability can increase productivity by reducing the time to complete a task, reducing the error rate, and increasing satisfaction.

• Most of these improvements can be quantified by measuring saved time, gained revenues, and increased productivity.

home | agenda | fin

36


© 2005 Pigneur

Claims Analysis ‘in the wild’: A case study on Digital Claims Analysis ‘in the wild’: A case study on Digital LibrariesLibraries

home | agenda | fin

37


© 2005 Pigneur

Motivation

• Goals– Bring user concerns into the design process for digital libraries

– Approach: apply Scenario-Based Design and Claim Analysis and evaluate its use

– Experiment on working with SBD and CA with DL developers

– Create a library of scenarios and claims that could be re-used by DL developers

home | agenda | fin

38


© 2005 Pigneur

Claim Analysis: an overview

• Claims– Statements about the positive and negative impact effects of a design on the user

within a particular context of use (a scenario)

– Task-artifact cycle• Existing user tasks may be used to define requirements on new artifacts to support those

tasks, but those new artifacts create new interaction possibilities that change users’ tasks

– Typical and critical/problem scenarios• Tasks people perform frequently• And those that are most likely to cause problems

– Scenario-based design vs. task-based design• scenarios effectively provide examples of how the system is intended to be used,• whereas tasks prescribe the what and how of implementation

home | agenda | fin

39


© 2005 Pigneur

Methodology

• Study located in the real world of system development• Exploratory and developmental

– Rather than a more traditional, investigative science research paradigm

• Qualitative Data Collection and Analysis– Based on interviews and observations

• Applied in three case studies– DL for a telecommunications company (BT)

– Greenstone

– DL for a Musem of Domestic Architecture

home | agenda | fin

40


© 2005 Pigneur

Discussion and Conclusions

• Goals could not be totally met.• Reasons

– Cultural gulf between development team and CA team• Function- and solution orientation vs. scenario- and user-focused orientation

– DL development is even more ill-structured than most other software development• Typically involving interoperating components developed by distributed teams who may

have no direct contact with each other

– Many novel functions with novel desgins that created new interaction possibilities • So tehre was neither relevant theory nor empirical data on which to base claims

• Although the use of personas , scenarios, and claims helped deliver important design insights, and to bridge the gulf between the conflicting perspectives– Using claims as a communication tool proved to be more effective than just writing

them down– The process of discussing scenarios and who the users are and what they are

trying to do generated the most productive dialogue between the developers and human factors specialists

HEC Lausanne > HCI > March 2005 Scenario-Based Design of Interactive Software Université de...

Documents

Transcript of HEC Lausanne > HCI > March 2005 Scenario-Based Design of Interactive Software Université de...