Presentation is loading. Please wait.

Presentation is loading. Please wait.

Prototyping Material Drawn from: James Landay, Berkeley Univ. John Kelleher, IT Sligo.

Similar presentations


Presentation on theme: "Prototyping Material Drawn from: James Landay, Berkeley Univ. John Kelleher, IT Sligo."— Presentation transcript:

1 Prototyping Material Drawn from: James Landay, Berkeley Univ. John Kelleher, IT Sligo

2 2 Hall of Fame or Shame? Password dialog in Eudora Pro for Mac

3 3 Hall of Fame! Password dialog in Eudora Pro for Mac Most passwords are mixed case caps lock often leads to failure to authenticate Good idea to inform user that Caps Lock is on Flashing and “!” unnecessary

4 4 Outline Low-fi prototyping Wizard of Oz technique Informal UI prototyping tools Hi-fi prototyping What prototyping tools lack

5 5 Why Do We Prototype? Experiment with alternative designs Get feedback on our design faster fix problems before code is written saves money Keep the design centered on the user must test & observe ideas with users

6 6 Types of Prototypes Vertical Cutting down on number of features. Results in a narrow system that does include depth of functionality, but only for a few selected features Can only test a limited part of the system However, that part will be tested in depth under realistic circumstances

7 7 Types of Prototypes Horizontal Reducing level of functionality Result is a surface layer that include the entire user interface to a full featured system However: no underlying functionality Low-level fidelity mockups best suited

8 8

9 9 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

10 10 Low-fi Sketches & Storyboards

11 11 Low-fi Sketches & Storyboards Where do storyboards come from? film & animation Give you a “script” of important events leave out the details concentrate on the important interactions

12 12 Ink Chat

13 13 Why Use Low-fi Prototypes? Traditional methods take too long sketches -> prototype -> evaluate -> iterate Can instead 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

14 14 Hi-fi Prototypes Warp Perceptions of the tester/reviewer representation communicates “finished” comments focus on color, fonts, & alignment Time encourage precision specifying details takes more time Creativity lose track of the big picture

15 15 The Basic Materials Large, heavy, white paper (11 x 17) 5x8 in. index cards Post-its Tape, stick glue, correction tape Pens & markers (many colors & sizes) Overhead transparencies Scissors, X-acto knives, etc.

16 16 from “Prototyping for Tiny Fingers” by Rettig

17 17 ESP

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

19 19 Preparing for a Test Select your users understand background of intended users use a questionnaire to get the people you need don’t use friends or family I think “customers” are OK (Rettig disagrees) Prepare scenarios that are typical of the product during actual use make prototype support these (small, yet broad) Practice to avoid “bugs”

20 20 Conducting a Test Four testers (minimum) greeter – puts users at ease & gets data facilitator – only team member who speaks gives instructions & encourages thoughts, opinions computer – knows application logic & controls it always simulates the response, w/o explanation observers – take notes & recommendations Typical session is 1 hour preparation, the test, debriefing

21 21 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

22 22 Advantages of Low-fi Prototyping Takes only a few hours no expensive equipment needed Can test multiple alternatives fast iterations number of iterations is tied to final quality Almost all interaction can be faked

23 23 Designing a content page Using low-fi techniques Combine low-fi paper prototyping and card sorting Start with a page with all the features you might want Cut it up into pieces Have people arrange the components One set of users sorts into groups, as in card sorting for categories Another set of users lays out the information in a way that would work well for them given certain tasks.

24 24

25 25

26 26 Wizard of Oz Technique Faking the interaction. Comes from? the film “The Wizard of OZ” “the man behind the curtain” Long tradition in computer industry e.g., prototype of a PC w/ a VAX behind the curtain Much more important for hard to implement features speech & handwriting recognition

27 27 Informal UI Prototyping Tools Support advantages of low-fi paper prototypes brainstorming consider different ideas rapidly do not require specification of details incomplete designs need not cover all cases, just illustrate important examples Add advantages of electronic tools evolve easily support for “design memory” transition to other electronic tools allow end-user interaction

28 28 Designers’ Outpost: A Tangible Interface for Designing Information Architectures Combines physical & virtual physical post-its, virtual feedback Supports existing practice affordances of paper collaboration large, persistent representation Adds advantages of e-media editing, reuse, distribution hand-off later to other tools

29 29 DENIM: Designing Web Sites by Sketching A research effort at UCB intended to combine the best of paper and computers Allows for free-hand sketching But also allows for undo, copies, etc. Has a storyboarding facility Can help design the interactions for the person playing computer Early-phase navigation & interaction design Integrates multiple views site map – storyboard – page sketch

30 30 Problems with Low-fi Prototypes “Computer” inherently buggy Slow compared to real app timings not accurate Hard to implement some functionality pulldowns, feedback, drag, viz … Won’t look like final product sometimes hard to recognize widgets End-users can’t use by themselves not in context of user’s work environment

31 31 Why Build Hi-fi Prototypes? Paper mock-ups don’t always go far enough how would you show a drag operation? not realistic of how interface will be used Building final app. now is a mistake changes in the UI can cause huge code changes need to convince programmer & hope they get it right takes too much time Drag & drop prototyping tool appropriate but only after we have iterated on design throws up interesting resultsresults

32 32 Why Use Tools (rather than code)? Faster Easier to incorporate testing changes Multiple UIs for same application Consistent user interfaces Easier to involve variety of specialists Separation of UI code from app. code easier to change and maintain More reliable bugs found in the tool are fixed for all applications

33 33 Prototyping Tools (historical) HyperCard for Macintosh – built by Bill Atkinson metaphor: card transitions on button clicks comes with widget set drawing & animation limited Director most commonly used by designers intended for multimedia -> until recently lacked interface widgets or controls good for non-widget UIs Both have “scripting” languages

34 34 HyperCard

35 35 Director

36 36 Authorware

37 37 Other tools Formula Graphics Multimedia http://www.formulagraphics.com Microsoft Powerpoint (msdn blog)blog Asymetrix Toolbook http://www.asymetrix.com/en/ toolbook/index.asp http://www.asymetrix.com/en/ toolbook/index.asp

38 38 UI Builders Visual Basic lots of widgets (AKA controls) simple language slower than other UI builders NeXT UIB, SpecTCL, PowerBuilder... widgets sets easily connect to code via “callbacks” “commercial” strength languages

39 39 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 UIBs do little, prototypers offer some support Final product generally use UI builders, though occasionally see things created in a prototyping tool (multimedia)

40 40 What is Missing? Support for the “insides” of applications

41 41 Summary Low-fi testing allows us to quickly iterate get feedback from users & change right away Informal prototyping tools bridge the gap between paper & high-fi tools High-fi UI tools good for testing more developed UI ideas generally ignore the “insides” of application

42 42 Further Reading Prototyping Articles “Prototyping for Tiny Fingers” by Marc Rettig, in Communications of the ACM, 1994 “Prototyping for Tiny Fingers” “Using Paper Prototypes to Manage Risk” by Carolyn Snyder, http://world.std.com/~uieweb/paper.htm “Using Paper Prototypes to Manage Risk” “The Perils of Prototyping” by Alan Cooper, “The Perils of Prototyping” http://www.chi-sa.org.za/Documents/articles/perils.htm Web Sites Group for User Interface Research, for DENIM & SUEDE downloads, http://guir.berkeley.edu Group for User Interface Researchhttp://guir.berkeley.edu InfoDesign Toolkit, http://www.infodesign.com.au InfoDesign Toolkithttp://www.infodesign.com.au


Download ppt "Prototyping Material Drawn from: James Landay, Berkeley Univ. John Kelleher, IT Sligo."

Similar presentations


Ads by Google