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

2. 2 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. 4 Not a ”one shot affair” Throughout entire product lifecycle Tied to software engineering /development process ROPES, RUP, SPU or Agile Methods, XP Software engineering = discipline concerning software design process / life cycle

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

6. 6 Software Engineering Process Why care about development methods? Most engineering companies use development methods to construct their products All usability work must therefore be situated in these Badly employed method endangers product usability Beck and Wells: existing methods do not work Certainly there seems to be problems: Products and projects developed for years –> Only to arrive at the marked with unwanted features and bad user interfaces

7. 7 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 “The Waterfall Model” Requirements specification Architectural design Detailed design Coding and unit testing Integration and testing Operation and maintenance

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

9. 9 Iterative Rapid Development Proces Spiral model End target Start ROPES Iterations helps significantly on usability problems (Bohm 1988) But if not verified – then useless

10. 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 Main points presented, focus on promoting usability Its up to you if you wish to use this method

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

12. 12 XP Project model

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

14. 14 XP vs. Traditional Methods SPU/OOA-OOD There is a reason for making requirement specifications There is a reason for making legal contracts Lack of trust between engineering company & customer only one Need to control ”loose cannon” developers Silverbullet & gold plating Conflict between what the customer thinks he needs – and what he really needs (next time!) HCI concludes user involvement is good – but expensive Use XP and more trust instead of traditional methods

15. Iterative Design and Prototyping

16. 16 Iterative Design and Prototyping Iterative design overcomes inherent problems of incomplete requirements -> but only when used right Prototypes is one way most users have difficulties relating textual requirements to end products get feedback on design faster 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

17. 17 Techniques for prototyping Storyboards / Mock-ups prototypes with low fidelity (= precision) need not be computer-based – paper mock-ups Limited func simulations = scenarios One part of functionality provided by designers RAD tools may be used for these (Visual Studio) 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 Throw-away, incremental, evolutionary

18. Low-fidelity prototyping

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

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

21. 21 Nokia Uses Paper Prototyping Extensively

22. 22 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 are tied to final quality Almost all interaction can be faked

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

24. High-fidelity Prototypes & RAD Tools

25. 25 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 can not be simulated (dragging/highlight) Lack of interactive feedback (affordances) Solution: Build more advanced prototypes

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

27. 27 Director Cast Flash / Shockwave 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)

28. 28 Visual Studio – Pocket PC

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

30. 30 Widgets May not be available with embedded platform IDE’s

31. Design Rationale

32. 32 Design Rationale Design rationale: information explaining why a user interface is the way it is. AKA – Styleguide or Designguide 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”

33. Meta-methods

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

35. 35 Læringsmåls alignment Når kurset er færdigt forventes den studerende at kunne: Definere og beskrive forskellige typer af brugergrænseflader til apparater og computere Definere og beskrive gængse teorier, metoder og retningslinier indenfor menneske- maskin-interaktion og anvende disse til at lave en brugervenlig brugergrænseflade til et givet apparat Designe og konstruere brugergrænsefladesoftware til udvalgte typer af brugergrænseflader Vi har fået en Forståelse af Hvordan Usability passer ind I hele processen. Vi har fået Prototyping Værktøjer