Brugergrænseflader til apparater BRGA Presentation 6: The Usability Engineering Lifecycle

Ingeniørhøjskolen i Århus Slide 2 Outline When to apply? Choosing the Software Engineering Process User Involvement Iterative design and prototyping Design rationale Meta-methods

When to Apply Usability Engineering

Ingeniørhøjskolen i Århus Slide 4 When to Apply Usability Engineering Not a ”one shot affair” Takes place throughout the entire lifecycle of the product Tied to the software engineering or development process (e.g. ROPES, RUP, SPU or Agile Methods like XP) Software engineering is the discipline concerning the software design process, or life cycle

The Importance of the “right” Software Engineering Process

Ingeniørhøjskolen i Århus Slide 6 Software Engineering Process Why care about development methods? –Because most engineering companies use development methods to construct their products –All usability work must therefore be situated in these methods –A badly employed method might even spell disaster for the usability of the product –According to Kent Beck and Don Wells, existing methods do not work –Certainly there seems to be problems: Products and projects being developed for years – only to arrive at the marked with unwanted features and bad user interfaces

Ingeniørhøjskolen i Århus Slide 7 “The Waterfall Model” Requirements specification Architectural design Detailed design Coding and unit testing Integration and testing Operation and maintenance Origins: civil engineering Bridge building Need to secure delivery Specify everything! Does not always work well - In a software development perspective - Especially so in a usability perspective - Promotes building the product right – not the right product

Ingeniørhøjskolen i Århus Slide 8 Design Fallbacks - Design fallbacks are one solution - Problems with interactive systems - Very expensive with long fallbacks - Users do not understand Use Cases or Class Diagrams and similar lots of feedback! Requirements specification Architectural design Detailed design Coding and unit testing Integration and testing Operation and maintenance

Ingeniørhøjskolen i Århus Slide 9 Iterative Rapid Development Proces Spiral model End target Start ROPES Iterations helps significantly on usability problems

Ingeniørhøjskolen i Århus Slide 10 XP – an alternative “XP is successful because it emphasizes customer involvement and promotes team work.” - Don Wells XP: eXtreme Programming is primarily a software engineering method, but Agile Methods may be used everywhere XP is too big of a topic for one lecture –But I will present some main points with the focus being on promoting usability –Its up to you if you wish to use this method

Ingeniørhøjskolen i Århus Slide 11 The Rules and Practices of Extreme Programming Planning User stories are writtenUser stories Release planning creates the scheduleRelease planning Make frequent small releasessmall releases The Project Velocity is measuredProject Velocity The project is divided into iterations. Iteration planning starts each iterationiterations Iteration planning Move people around A stand-up meeting starts each day.stand-up meeting Fix XP when it breaksFix XP Designing Simplicity Choose a system metaphorsystem metaphor Use CRC cards for design sessions.CRC cards Create spike solutions to reduce risk.spike solution No functionality is added earlyadded early Refactor whenever and wherever possible.Refactor Coding The customer is always availablealways available Code must be written to agreed standardsstandards Code the unit test firstunit test first All production code is pair programmedpair programmed Only one pair integrates code at a timeintegrates code at a time Integrate often Use collective code ownershipcollective code ownership Leave optimization till lastoptimization No overtime.overtime Testing All code must have unit testsunit tests All code must pass all unit tests before it can be releasedunit tests When a bug is found tests are createda bug is found Acceptance tests are run oftenAcceptance tests Usability related issues have been highlighted

Ingeniørhøjskolen i Århus Slide 12 XP Project model

Ingeniørhøjskolen i Århus Slide 13 XP in relation to usability methods Cognitive Walkthrough Future workshops Video prototyping Field studies User tests Prototyping / mock-ups Heuristic Evaluation Keystroke Level Analysis Design Guidelines & Heuristics

Ingeniørhøjskolen i Århus Slide 14 XP vs. traditional methologies SPU/OOA-OOD There is a reason for making requirement specifications There is a reason for making legal contracts The lack of trust between engineering company and customer is only one Need to control ”loose cannon” developers –Silverbullet & gold plating Conflict between what the customer thinks he needs – and what he really needs HCI concludes user involvement is good – but expensive Use XP and more trust instead of traditional methods

User Involvement - an introduction

Ingeniørhøjskolen i Århus Slide 16 Until now we have looked at Cognitive HCI: –Theory & Methods –Mainly predictive methods GOMS/KLA/Fitts Law Designers: CW Heuristics & Guidelines –Distilled experiences –Avoid common design pitfalls by following design principles: guidelines & heuristics –Method: Heuristic Evaluation All In the Lab –no user contact

Ingeniørhøjskolen i Århus Slide 17 The problem with predictive methods & heuristics / guidelines Makes overall assumptions –May often be right (that’s why we use them) –May some times be inadequate Makes assumptions on behalf of the users –But we cannot really know if these hold to be true The problem: we cannot be sure that we are building the right product – even if we are building a good usable one The solution: consulting the users

Ingeniørhøjskolen i Århus Slide 18 Techniques for observing and listening to users Participatory Design – involving the user Field studies or lab testing Think aloud: talk while doing the job Talk right after : debriefing after the job Prototyping / Role playing / Wizard of Oz Cueing recall with videotape (Focus Shift Analysis) Focus groups & interviews Mailed surveys –More on these methods at a later lecture!

Iterative design and prototyping

Ingeniørhøjskolen i Århus Slide 20 Iterative design and prototyping Iterative design overcomes inherent problems of incomplete requirements Prototypes –most users have difficulties relating textual requirements to end products –get feedback on our design faster saves money –experiment with alternative designs / Nielsen: Parallel Design –fix problems before code is written –constructs the XP System Metaphor, developers & users –usage: simulate or animate some features of intended system Management issues –time –planning –non-functional features –contracts

Ingeniørhøjskolen i Århus Slide 21 Techniques for prototyping Storyboards / Mock-ups prototypes with low fidelity (= precision, like sound reproduction) need not be computer-based – paper mock-ups Limited functionality simulations (Nielsen: scenarios) some part of system functionality provided by designers RAD tools may be used for these (Visual Studio, HyperCard) most often mock-ups are ok Wizard of Oz technique Horisontal / Vertical advanced prototypes depending on what needs to be tested RAD tools are common for these (Visual Studio, HyperCard) Throw-away, incremental, evolutionary

Low-fidelity prototyping

Ingeniørhøjskolen i Århus Slide 23 Fidelity in Prototyping Fidelity refers to the level of detail High fidelity –prototypes look like the final product Low fidelity –artists renditions with many details missing

Ingeniørhøjskolen i Århus Slide 24 Why Use Low-fi Prototypes? Traditional methods take too long –sketches -> prototype -> evaluate -> iterate Can simulate the prototype –sketches -> evaluate -> iterate –sketches act as prototypes designer “plays computer” other design team members observe & record Kindergarten implementation skills –allows non-programmers to participate

Ingeniørhøjskolen i Århus Slide 25 The Basic Materials Large, heavy, white paper (11 x 17) 5x8 in. index cards Tape, stick glue, correction tape Pens & markers (many colors & sizes) Overhead transparencies Scissors, knives, etc.

Ingeniørhøjskolen i Århus Slide 26 Constructing the Model Set a deadline –don’t think too long - build it! Draw a window frame on large paper Put different screen regions on cards –anything that moves, changes, appears/disappears Ready response for any user action –e.g., have those pull-down menus already made Use photocopier to make many versions

Ingeniørhøjskolen i Århus Slide 27

Ingeniørhøjskolen i Århus Slide 28 Quickly Sketch this...

Ingeniørhøjskolen i Århus Slide 29 Add Behavior...

Ingeniørhøjskolen i Århus Slide 30 Evaluating Results Sort & prioritize observations –what was important? –lots of problems in the same area? Create a written report on findings –gives agenda for meeting on design changes Make changes & iterate

Ingeniørhøjskolen i Århus Slide 31 Advantages of Low-fi Prototyping Take only a few hours –no expensive equipment needed –May use users (later) – may use Heuristic Evaluation / Cognitive Walkthrough with designers Can test multiple alternatives –fast iterations number of iterations is tied to final quality Almost all interaction can be faked

Ingeniørhøjskolen i Århus Slide 32 Wizard of Oz Technique Faking the interaction –from the film “The Wizard of OZ” “the man behind the curtain” Long tradition in computer industry –prototypes made of other equipment½ Much more important for hard to implement features –Speech & handwriting recognition

High-fidelity prototypes & RAD tools

Ingeniørhøjskolen i Århus Slide 34 Problems with Low-fi Prototypes? Doesn’t map well to what will actual fit on the screen Realism low - cognitive load high (hard to draw) Couldn’t hold in your hand - different ergonomics from intended device (PDA, speech) Timing in real-time hard to do Some things could not simulate (dragging/highlight) Lack of interactive feedback (affordances) Solution: Build more advanced prototypes

Ingeniørhøjskolen i Århus Slide 35 RAD Development Use RAD tools for Rapid Application Development Prototyping –Powerpoint, Word, HyperCard, Director, HTML-tools –JBuilder, Visual Studio (widgets) (for evolutionary) Produces: Horizontal / Vertical High-fidelity prototypes Incremental & Evolutionary –Danger of ”it’s good enough” effect –User may sit next to the developer Dangerous

Ingeniørhøjskolen i Århus Slide 36 Director Cast Basic objects used in interface Mainly multimedia in nature –images, audio, video, etc. –synchronize with cue points Can take screenshots and provide both simpel and advanced navigational transitions (”change something” when button is clicked)

Ingeniørhøjskolen i Århus Slide 37 Director Score Overview of events in time

Ingeniørhøjskolen i Århus Slide 38 Connect events to actions Drag & drop Director Behavior Inspector

Ingeniørhøjskolen i Århus Slide 39 HyperCard Tool palettes Almost as easy using FrontPage or other HTML tool

Ingeniørhøjskolen i Århus Slide 40 Visual Studio – Pocket PC

Ingeniørhøjskolen i Århus Slide 41 Director or Visual Studio? Prototyping tools (Director, Hypercard, PowerPoint, Frontpage) –prototyping tools produce slow programs –May evolve to a certain degree – then throw away IDE tools with UI Builders (Visual Studio, Delphi) –Uses the standard Widgets available –May eventually evolve to full product (warning!) –May take a longer time to get started with –Better for developers – not good for designers

Ingeniørhøjskolen i Århus Slide 42 Widgets

Design Rationale

Ingeniørhøjskolen i Århus Slide 44 Design rationale Design rationale is information that explains why a user interface is the way it is. Benefits of design rationale –communication throughout lifecycle –reuse of design knowledge across products –enforces design discipline –presents arguments for design trade-offs –organizes potentially large design space –capturing contextual information –“one can always read the design rationale and understand why a certain path was chosen”

Meta-methods

Ingeniørhøjskolen i Århus Slide 46 Meta-methods Decide on which methods to employ for your project Make an illustrated plan of the usage (with some text) Write down how you would like to use the methods. How many users, which user, how often Get it reviewed