HEC Lausanne > HCI > March 2005 Scenario-Based Design of Interactive Software Université de Lausanne Ecole des Hautes Etudes Commerciales (HEC) Introduction REQUIREMENTS ANALYSIS scenario-based design requirements analysis task modeling DESIGN activity design information design interaction design USABILITY EVALUATION prototyping usability testing documentation Science of design Table of content

homehome | agenda | finUniversité de Lausanne 2 © 2005 Pigneur Usability Engineering Mary Rosson and John Carroll Usability Engineering Scenario-based development of human-computer interaction Morgan Kaufmann Publishers Scenario-based usability engineering 2.Analyzing requirements 3.Activity design 4.Information design 5.Interaction design 6.Prototyping 7.Usability evaluation 8.User documentation 9.Emerging paradigms for user interaction 10.Usability engineering in practice

homehome | agenda | finUniversité de Lausanne 3 © 2005 Pigneur Usability case study

homehome | agenda | finUniversité de Lausanne 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]

homehome | agenda | finUniversité de Lausanne 5 © 2005 Pigneur Interactive software Human-computer interface BEHAVIOUR Processing rules FUNCTION Database DATA

homehome | agenda | finUniversité de Lausanne 6 © 2005 Pigneur Requirement engineering (I) - Data Database DATA EMPLOYEDOCUMENT 1,N0,1 access object relationship

homehome | agenda | finUniversité de Lausanne 7 © 2005 Pigneur Requirement engineering (II) - Function Processing rules FUNCTION Database DATA Check people Check document Check security Record access Check and record access action decomposition encapsulation

homehome | agenda | finUniversité de Lausanne 8 © 2005 Pigneur Requirement engineering (III) - Behaviour Human-computer interface BEHAVIOUR Processing rules FUNCTION Database DATA Check people Check document Check securityRecord access Access request event trigger

homehome | agenda | finUniversité de Lausanne 9 © 2005 Pigneur Requirement engineering (IV) - Intention Processing rules FUNCTION Check people is secure Record secure access to document goal decomposition Check document is available Check people has right to access document Human-computer interface BEHAVIOUR

homehome | agenda | finUniversité de Lausanne 10 © 2005 Pigneur Prototyping and iterative development Tradeoff 1.2 [Rosson, 2002] p. 8 Prototyping encourgaes iteration in software development, BUT may leads to inefficiency or local optimization of software [Rosson and Carroll, 2002]

homehome | agenda | finUniversité de Lausanne 11 © 2005 Pigneur Usability in software development Quality of system with respect to ease of learning, ease of use, and user satisfaction Human performance Time, and errors Collaboration group Dynamics, and Workplace context Human cognition, Mental models of plans, and actions USABILITY [Rosson and Carroll, 2002]

homehome | agenda | finUniversité de Lausanne 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 performance Human-computer interaction Computer-supported cooperative work [Rosson and Carroll, 2002]

homehome | agenda | finUniversité de Lausanne 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 [Rosson and Carroll, 2002]

homehome | agenda | finUniversité de Lausanne 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 SCENARIO A 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

homehome | agenda | finUniversité de Lausanne 15 © 2005 Pigneur A problem scenario

homehome | agenda | finUniversité de Lausanne 16 © 2005 Pigneur A design scenario

homehome | agenda | finUniversité de Lausanne 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]

homehome | agenda | finUniversité de Lausanne 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 [Rosson and Carroll, 2002]

homehome | agenda | finUniversité de Lausanne 19 © 2005 Pigneur Why scenarios? Design and engineering always involve the management of tradeoffs –Difficult to conciliate both goals: Performance Vs. satisfaction [Rosson and Carroll, 2002] Analyze use but let it evolve Make decisions but keep options open Balance action with reflection Be innovative but only if adding value Be precise but include everyone on the team Scenario-based design

homehome | agenda | finUniversité de Lausanne 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 Tradeoff 1.3 [Rosson, 2002] p. 21 Designers are motivated to make progress quickly, BUT premature decisions and commitment can lead to poor solutions [Rosson and Carroll, 2002]

homehome | agenda | finUniversité de Lausanne 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 Tradeoff 1.4 [Rosson, 2002] p. 22 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 [Rosson and Carroll, 2002]

homehome | agenda | finUniversité de Lausanne 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) Tradeoff 1.5 [Rosson, 2002] p. 22 The rapidly evolving software market demands innovation and new features, BUT some functionality may actually undermines usability [Rosson and Carroll, 2002]

homehome | agenda | finUniversité de Lausanne 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 Tradeoff 1.6 [Rosson, 2002] p. 23 Technical design representations can increase the precision of communication, BUT may exclude participations by untrained team members [Rosson and Carroll, 2002]

homehome | agenda | finUniversité de Lausanne 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 Tradeoff 1.7 [Rosson, 2002] p. 24 Software development provides concrete rewarding evidence of progress, BUT can direct attention away from reflection and analysis [Rosson and Carroll, 2002]

homehome | agenda | finUniversité de Lausanne 25 © 2005 Pigneur Scenario-based Development Framework [Rosson and Carroll, 2002] PROTOTYPING

homehome | agenda | finUniversité de Lausanne 26 © 2005 Pigneur Scenario-based design [Rosson and Carroll, 2002] Problem scenarios Analysis of stakeholders, field studies Analyze Claims about current practice Usability specifications Summative evaluation Formative evaluation Prototype and Evaluate Metaphors, information technology HCI theory guidelines Iterative analysis of Usability claims and redesign Activity Scenarios Information scenarios Interaction scenarios Design

homehome | agenda | finUniversité de Lausanne 27 © 2005 Pigneur SCENARIO | ANALYSIS | DESIGN | EVALUATION | DESIGN SCIENCE [Rosson and Carroll, 2002] 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)

homehome | agenda | finUniversité de Lausanne 28 © 2005 Pigneur SCENARIO | ANALYSIS | DESIGN | EVALUATION | DESIGN SCIENCE [Rosson and Carroll, 2002] DESIGN the project is moved from problem understanding to envisioned solutions Explore –HCI concepts, metaphors, technology Envisionment –prototypes, scenarios … Rationale –design claims and evaluation results From problem-scenarios to design-scenarios

homehome | agenda | finUniversité de Lausanne 29 © 2005 Pigneur [Rosson and Carroll, 2002] 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

homehome | agenda | finUniversité de Lausanne 30 © 2005 Pigneur [Rosson and Carroll, 2002] 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

homehome | agenda | finUniversité de Lausanne 31 © 2005 Pigneur [Rosson and Carroll, 2002] 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

homehome | agenda | finUniversité de Lausanne 32 © 2005 Pigneur Documentation [Rosson and Carroll, 2002] Activity design Information design Interaction design

homehome | agenda | finUniversité de Lausanne 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

homehome | agenda | finUniversité de Lausanne 34 © 2005 Pigneur SCENARIO | ANALYSIS | DESIGN | EVALUATION | DESIGN SCIENCE [Rosson and Carroll, 2002] 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 system that was envisioned and specified? –Did we meet or exceed the usability goals quantified in the usability specifications?

homehome | agenda | finUniversité de Lausanne 35 © 2005 Pigneur Usability Return on Investment? 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.

homehome | agenda | finUniversité de Lausanne 36 © 2005 Pigneur Claims Analysis ‘in the wild’: A case study on Digital Libraries

homehome | agenda | finUniversité de Lausanne 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

homehome | agenda | finUniversité de Lausanne 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

homehome | agenda | finUniversité de Lausanne 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

homehome | agenda | finUniversité de Lausanne 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

homehome | agenda | finUniversité de Lausanne 41 © 2005 Pigneur