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

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

3. When to Apply Usability Engineering

4. Ingeniørhøjskolen i Århus Slide 4 af 50 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 for understanding the software design process, or life cycle

5. The Importance of the “right” Software Engineering Process

6. Ingeniørhøjskolen i Århus Slide 6 af 50 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

7. Ingeniørhøjskolen i Århus Slide 7 af 50 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 work well - In a technical perspective - Especially so in a usability perspective

8. Ingeniørhøjskolen i Århus Slide 8 af 50 Verification and validation Verification designing the product right Validation designing the right product The formality gap validation will always rely to some extent on subjective means of proof Management and contractual issues design in commercial and legal contexts Real-world requirements and constraints The formality gap

9. Ingeniørhøjskolen i Århus Slide 9 af 50 Design Fallbacks Design fallbacks are one solution Problems with interactive systems Very expensive with long fallbacks lots of feedback! Requirements specification Architectural design Detailed design Coding and unit testing Integration and testing Operation and maintenance

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

11. Ingeniørhøjskolen i Århus Slide 11 af 50 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

12. Ingeniørhøjskolen i Århus Slide 12 af 50 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

13. Ingeniørhøjskolen i Århus Slide 13 af 50 XP Project model

14. Ingeniørhøjskolen i Århus Slide 14 af 50 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

15. Ingeniørhøjskolen i Århus Slide 15 af 50 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

16. User Involvement - an introduction

17. Ingeniørhøjskolen i Århus Slide 17 af 50 Until now we have looked at Cognitive HCI: –Theory & Methods –Mainly predictive methods GOMS/KLA/Fitts Law Designers: CW –But still not methods for analysis Lab user testing (Think out loud) Heuristics & Guidelines –Distilled experiences –Avoid common design pitfalls by following design principles: guidelines & heuristics –Method: Heuristic Evaluation

18. Ingeniørhøjskolen i Århus Slide 18 af 50 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 holds to be true The problem: we cannot be sure that we are building the right product The solution: consulting the users

19. Ingeniørhøjskolen i Århus Slide 19 af 50 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!

20. Iterative design and prototyping

21. Ingeniørhøjskolen i Århus Slide 21 af 50 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

22. Ingeniørhøjskolen i Århus Slide 22 af 50 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

23. Low-fidelity prototyping

24. Ingeniørhøjskolen i Århus Slide 24 af 50 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

25. Ingeniørhøjskolen i Århus Slide 25 af 50 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

26. Ingeniørhøjskolen i Århus Slide 26 af 50 The Baisc 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, X-acto knives, etc.

27. Ingeniørhøjskolen i Århus Slide 27 af 50 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

28. Ingeniørhøjskolen i Århus Slide 28 af 50

29. Ingeniørhøjskolen i Århus Slide 29 af 50 Quickly Sketch this...

30. Ingeniørhøjskolen i Århus Slide 30 af 50 Add Behavior...

31. Ingeniørhøjskolen i Århus Slide 31 af 50 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

32. Ingeniørhøjskolen i Århus Slide 32 af 50 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

33. Ingeniørhøjskolen i Århus Slide 33 af 50 Wizard of Oz Technique Faking the interaction –from the film “The Wizard of OZ” “the man behind the curtain” Long tradition in computer industry –prototype of a PC w/ a VAX behind the curtain Much more important for hard to implement features –Speech & handwriting recognition

34. High-fidelity prototypes & RAD tools

35. Ingeniørhøjskolen i Århus Slide 35 af 50 Problems with Low-fi Prototypes? Doesn’t map well to what will actual fit on the screen (realism) Couldn’t hold in your hand -- different ergonomics from intended device Timing in real-time hard to do (slooooow computer) Some things could not simulate (highlighting)

36. Ingeniørhøjskolen i Århus Slide 36 af 50 Problems with Low-fi Prototypes? Writing on paper not the same as writing on the intended device (realism) Appearance unrealistic Dynamic widgets hard to simulate (pop-ups) Some items had to be static! Dragging hard to simulate

37. Ingeniørhøjskolen i Århus Slide 37 af 50 Problems with Low-fi Prototypes? Couldn’t measure realistic I/O –mouse (can’t sketch the same way) –slow response Lack of interactive feedback –button highlights “Computer” has to keep track of a lot of paper

38. Ingeniørhøjskolen i Århus Slide 38 af 50 Problems with Low-fi Prototypes? Hard to draw well (cognitive load high) Users wouldn’t criticize UI Can’t get accurate time measurement Couldn’t give proper affordance that something wasn’t selectable Solution: Build more advanced prototypes

39. Ingeniørhøjskolen i Århus Slide 39 af 50 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

40. Ingeniørhøjskolen i Århus Slide 40 af 50 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)

41. Ingeniørhøjskolen i Århus Slide 41 af 50 Director Score Overview of events in time

42. Ingeniørhøjskolen i Århus Slide 42 af 50 Connect events to actions Drag & drop Director Behavior Inspector

43. Ingeniørhøjskolen i Århus Slide 43 af 50 HyperCard Tool palettes

44. Ingeniørhøjskolen i Århus Slide 44 af 50 What’s the Difference? Performance –prototyping tools produce slow programs –UI builders depend on underlying language Widgets –prototyping tools may not have complete set –UI builders have widget set common to platform Insides of application Final product?

45. Ingeniørhøjskolen i Århus Slide 45 af 50 Widgets Buttons (several types) Scroll bars and sliders Pulldown menus

46. Ingeniørhøjskolen i Århus Slide 46 af 50 Widgets (cont.) Palettes Dialog boxes Windows and many more...

47. Design Rationale

48. Ingeniørhøjskolen i Århus Slide 48 af 50 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”

49. Meta-methods

50. Ingeniørhøjskolen i Århus Slide 50 af 50 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 (not only if you deviate from the specification)