1 / 41

HEC Lausanne > HCI > March 2005

Université de Lausanne Ecole des Hautes Etudes Commerciales (HEC). Table of content. Introduction REQUIREMENTS ANALYSIS scenario-based design requirements analysis task modeling DESIGN activity design information design interaction design USABILITY EVALUATION prototyping

hannah-peck
Download Presentation

HEC Lausanne > HCI > March 2005

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Université de Lausanne Ecole des Hautes Etudes Commerciales (HEC) Table of content • 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 HEC Lausanne > HCI > March 2005 Scenario-Based Design of Interactive Software

  2. Usability Engineering • Mary Rosson and John CarrollUsability EngineeringScenario-based development of human-computer interactionMorgan Kaufmann Publishers. 2002 • Scenario-based usability engineering • Analyzing requirements • Activity design • Information design • Interaction design • Prototyping • Usability evaluation • User documentation • Emerging paradigms for user interaction • Usability engineering in practice

  3. Usability case study http://ucs.ist.psu.edu

  4. 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]

  5. Interactive software Human-computer interface BEHAVIOUR Processing rules FUNCTION Database DATA

  6. Requirement engineering (I) - Data object EMPLOYE DOCUMENT access 1,N 0,1 relationship Database DATA

  7. Requirement engineering (II) - Function Check and record access decomposition encapsulation Check people Check document Processing rules FUNCTION Database DATA Check security Record access action

  8. Requirement engineering (III) - Behaviour event Check people Access request Check security Record access trigger Check document Human-computer interface BEHAVIOUR Processing rules FUNCTION Database DATA

  9. Requirement engineering (IV) - Intention Record secure access to document goal decomposition Check people is secure Check document is available Check people has right to access document Human-computer interface BEHAVIOUR Processing rules FUNCTION

  10. 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]

  11. Usability in software development • Quality of system with respect to ease of learning, ease of use, and user satisfaction Human performance Time, and errors USABILITY Human cognition, Mental models of plans, and actions Collaboration group Dynamics, and Workplace context [Rosson and Carroll, 2002]

  12. 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]

  13. 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]

  14. SCENARIO | ANALYSIS | DESIGN | EVALUATION | DESIGN SCIENCE 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

  15. A problem scenario http://ucs.ist.psu.edu

  16. A design scenario http://ucs.ist.psu.edu

  17. 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]

  18. 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]

  19. Why scenarios? • Design and engineering always involve the management of tradeoffs • Difficult to conciliate both goals: Performance Vs. satisfaction 1.4 Analyze use butlet it evolve 1.3 Make decisions but keep options open Scenario-based design 1.7 1.5 Balance actionwith reflection Be innovative but only if adding value 1.6 Be precise but include everyone on the team [Rosson and Carroll, 2002]

  20. Make decisions but keep options open Tradeoff 1.3 [Rosson, 2002] p. 21 Designers are motivated to make progress quickly, BUT premature decisions and commitment can lead to poor solutions • 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 [Rosson and Carroll, 2002]

  21. Analyze use but let it evolve 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 • Scenarios describe use in detail, but as a tentative, working representation • Co-evolution • People’s activities • technology [Rosson and Carroll, 2002]

  22. Be innovative but only if adding value Tradeoff 1.5 [Rosson, 2002] p. 22 The rapidly evolving software market demands innovation and new features, BUT some functionality may actually undermines usability • Scenarios focus on the usability consequences of specific design proposals • Balance • Needs (user-pull) • Innovation (technology push) [Rosson and Carroll, 2002]

  23. Be precise but include everyone on the team Tradeoff 1.6 [Rosson, 2002] p. 23 Technical design representations can increase the precision of communication, BUT may exclude participations by untrained team members • Scenarios describe the problem situation using natural language understood by all stakeholders • Participatory design • Collaboration between developers and the users [Rosson and Carroll, 2002]

  24. Balance action with reflection Tradeoff 1.7 [Rosson, 2002] p. 24 Software development provides concrete rewarding evidence of progress, BUT can direct attention away from reflection and analysis • 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 [Rosson and Carroll, 2002]

  25. Scenario-based Development Framework PROTOTYPING [Rosson and Carroll, 2002] http://ucs.ist.psu.edu

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

  27. 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) [Rosson and Carroll, 2002] http://ucs.ist.psu.edu

  28. SCENARIO | ANALYSIS | DESIGN | EVALUATION | DESIGN SCIENCE 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 [Rosson and Carroll, 2002] http://ucs.ist.psu.edu

  29. 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 [Rosson and Carroll, 2002] http://ucs.ist.psu.edu

  30. 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 [Rosson and Carroll, 2002] http://ucs.ist.psu.edu

  31. 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 [Rosson and Carroll, 2002] http://ucs.ist.psu.edu

  32. Documentation Activity design Information design Interaction design [Rosson and Carroll, 2002] http://ucs.ist.psu.edu

  33. 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

  34. SCENARIO | ANALYSIS | DESIGN | EVALUATION | DESIGN SCIENCE 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? [Rosson and Carroll, 2002] http://ucs.ist.psu.edu

  35. 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. http://www.usabilityfirst.com/roi/index.txl

  36. Claims Analysis ‘in the wild’: A case study on Digital Libraries

  37. 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

  38. 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

  39. 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

  40. 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

More Related