Design, prototyping and construction

1. Design, prototyping and construction Readings: ID-book, Chap. 11 (through 11.3) Also, Prototyping for Tiny Fingershttp://doi.acm.org/10.1145/175276.175288Also, Java.net article (from 2003), Six Signs That You Should Use Paper Prototyping

2. Four Old Slides • For review • Remember these ideas?

3. Identify needs/ establish requirements (Re)Design Evaluate Build an interactive version Final product A model for interaction design

4. What is User-Centered Design? • An approach to UI development and system development. • Focuses on understanding: • Users, and • Their goals and tasks, and • The environment (physical, organizational, social) • Pay attention to these throughout development

5. ISO on User-centered Design • ISO 13407 describes human-centered design processes for interactive systems • Principles of human-centered design: • Active involvement of users • Appropriate allocation of function between user and system • Iteration of design solutions • Multidisciplinary design teams

6. ISO on User-centered Design (2) • Essential activities in human-centered design: • Understand and specify the context of use • Specify the user and organizational requirements • Produce design solutions (prototypes) • Evaluate designs with users against requirements

8. What is a prototype? • What do you think of when you hear “prototype”? • What kinds of prototypes have you seen anywhere? • in other fields or disciplines? • on television? • What are they “for”?

9. What is a prototype? • In other design fields a prototype is a small-scalemodel: a miniature car a miniature building or town • Exists for some purpose • Show the “concept” to some stakeholders • Get feedback about some aspect • Test somehow • E.g. a wing in a wind-tunnel

10. Prototyping and Software • Do software companies do this? • Sometimes do it well • But sometimes the prototype is…Version 1.0! • Constantine and Lockwood: “Software is the only engineering field that throws together prototypes and then attempts to sell them as delivered goods.”

11. What is a prototype for us? • In HCI / interaction design it can be (among other things): • a series of screen sketchesa storyboard, i.e. a cartoon-like series of scenes a Powerpoint slide showa video simulating the use of a systema lump of wood (e.g. PalmPilot)a cardboard mock-upa piece of software with limited functionality written in the target language or in another language

12. Why prototype in general? • Evaluation and feedback are central to interaction design • Developers can test feasibility of ideas with team, users • Stakeholders can see, hold, interact with a prototype more easily than a document or a drawing • Team members and users can communicate effectively • To validate existing / other requirements • It encourages reflection: very important aspect of design • Prototypes answer questions, and support designers in choosing between alternatives

13. What to Prototype and Why • Prototyping reduces uncertainty • It can be a major tool for risk management • Apply on whatever you might be uncertain about! • Prototyping technical issues • E.g. run-time issues • Prototyping to establish requirements • Users “see” functionality • Prototyping for usability concerns • Our concern in this course

14. When and at What Level • For SW, you might prototype at various times in the lifecycle • Different goals, different techniques • Conceptual Design • Interaction Design • Screen Design

15. Benefits of Prototyping Early • Exploration and evaluation of different design options • Increase communication among users and developers • Rapid feedback on ideas and changes • Identify problems and issues before construction (expensive)

16. Prototyping: Conceptual Design • Early in development • Explore high-level issues • Different conceptual models • Interaction styles • User needs and characteristics • Usability goals • High-level representations • Far from final code or GUIs

17. Prototyping: Interaction Design • Later in development • Focus on user work-flows • Tasks and scenarios you’ve identified • Might focus at the screen (or page) level. Possibly like this: • identify screens, pages, activities • Organize these in groups • Define flows or transitions between them • Involve users in evaluation • Representations • Still probably not much like final code or GUIs

18. Prototyping: Screen Design • Before development • Define and refine screens (pages) • Blue-prints for final physical design • User evaluation • Both achieving tasks and navigation, andother usability criteria (as we’ve studied) • Representations • Low-fidelity or high-fidelity prototypes

19. Low-fidelity Prototyping • Uses a medium which is unlike the final medium, e.g. paper, cardboard • Is quick, cheap and easily changed • Examples: sketches of screens, task sequences, etc ‘Post-it’ notes storyboards

20. Storyboards • Often used with scenarios, bringing more detail, and a chance to role play • It is a series of sketches showing how a user might progress through a task using the device • Used early in design

21. Sketching • Sketching is important to low-fidelity prototyping • Don’t be inhibited about drawing ability. Practice simple symbols • Can use post-its, photo-copied widgets, etc.

22. Using Office Supplies • Index cards, post-its • Index cards (3 X 5 inches) • Each card represents one screen • Often used in website development

23. Using Office Supplies • Post-its, index cards • Can represent one screen, one page • Color coded • Draw on them • Group them • Put them on a wall or whiteboard, connect them with string or lines • Write-on tape, clear film • And so on… See Rettig’s article

24. Rettig’s “Prototyping for Tiny Fingers” • “To get a a good idea, get lots of ideas.” • Problems with hi-fi prototyping: • too easy to focus on “fit and finish” • developers resist changing software • SW prototype sets expectations • Bug in SW prototype kills an evaluation

25. Storyboards • Storyboards are: • a low fidelity visual representation where • steps or actions represented by panels, like a comic book • Goals are to • flesh out the scenarios in an interaction design • effectively communicate with users or stakeholders

26. Principles and Variations • (As usual in HCI) storyboards should be “real” and “representational” rather than “abstract” or “complete” • Used in different ways at different phases • Early: focus on user tasks, work-flow, context, etc. • Later: lo-fi drawing of screens, menus, etc. • Principles: • Describe a scenario -- focused on interaction • Contains explanations, notes, etc.

27. Example from UIDE book, p. 119 • Shows • workflow of mail merging • who’s involved, responsibilities, etc.

28. This shows high-level of view of users involved in other storyboards From: Usability Case Studies, http://ucs.ist.psu.edu

29. Lo-fi interface sketches • Annotated with scenario/execution info From: Usability Case Studies, http://ucs.ist.psu.edu

30. Storyboard for a website • for photographers • Sequence of pages • based on clicks • Explanations / annotations From book: Designing Interactive Systems, 2005

31. High-fidelity prototyping • Uses materials that you would expect to be in the final product. • Prototype looks more like the final system than a low-fidelity version. • For a high-fidelity software prototype common environments include Macromedia Director, Visual Basic, and Smalltalk. • Danger that users think they have a full system…….see compromises

32. High-fidelity Prototyping • Benefits • More realistic • Closer to final product • Good for developers and users • Can collect metrics • Limitations • More expensive, less rapid • Reluctance to change • See Rettig’s list

33. Compromises in prototyping • All prototypes involve compromises • For software-based prototyping maybe there is a slow response? sketchy icons? limited functionality? • Two common types of compromise • ‘horizontal’: provide a wide range of functions, but with little detail • ‘vertical’: provide a lot of detail for only a few functions • Compromises in prototypes mustn’t be ignored. Product needs engineering

34. Possible Problems with Prototyping • Pressure to enhance prototype to become delivered system • From client • From management • Both see code, see almost-working “system” • Why not use the prototype? • Prototype built for quick updates, so... • No design, so hard to maintain • Ugly code, no error checking • Wrong environment

35. And then… Construction • Taking the prototypes (or learning from them) and creating a final product • Quality must be attended to: usability (of course), reliability, robustness, maintainability, integrity, portability, efficiency, etc • Product must be engineered • Evolutionary prototyping • ‘Throw-away’ prototyping