Today: ID Chapter 11 – Design, Prototyping, and Construction Also please read: “Prototyping for Tiny Fingers”, get it from the bibliography section of the web site.

Chapter 11 Design, prototyping, and construction Communicating a proposed design with textual specifications or a diagrammed model has several drawbacks: Features tend to be presented in isolation (e.g., bullet items), inhibiting the achievement of a global vision. Text and work models tend to be abstract, making them difficult for users to relate to their actual work experience. These approaches are not event-driven, which can prevent users from envisioning the planned dynamics of the proposed system. A preferred approach for communicating the design is prototyping, modeling a reasonably close facsimile of the final product.

The Advantages of Prototyping Prototyping provides a tool with which designers can validate the usability of their proposed system. Prototyping provides an effective means of communication between designers and users, ensuring a common understanding of what will and will not be accomplished with the proposed system. Prototyping affords opportunities to clarify misconceptions between designers and users before the investment in time and resources becomes too great.

Low-Fidelity Prototyping A low-fidelity prototype is sketchy and incomplete, and has some characteristics of the target product but is otherwise simple, usually in order to quickly produce the prototype and test broad concepts. Advantages Fast - no coding required Quickly identifies basic design flaws Refines GUI pre-implementation Allows multidisciplinary participation Encourages ideas from designers & users Disadvantages Produces no code Doesn’t find all GUI problems Incompatible with mere upgrades May seem unprofessional to users May be overwhelming for large systems

High-Fidelity Prototyping A high-fidelity prototype is quite close to the final product, with lots of detail and functionality. Advantages No delays for test users Superior control over what the user can see Resetting or undoing actions is possible & easy Particularly useful for upgrading existing software Disadvantages Curtails major changes Not conducive to large design teams Tends to make users feel that design is complete Requires all designers to have technical backgrounds

Paper Prototyping One low-fidelity prototyping technique is the use of paper prototypes, in which Post-It notes, poster board, glue sticks, etc., are used to produce a modifiable sketch of an interface. Pre-printed kits of standard interface components (dialog boxes, textboxes, buttons, etc.) can facilitate the paper prototyping process. When aligned and printed on labels, these components streamline dynamic design.

Running a Paper Prototyping Session Team Member Role: Facilitator The interviewer who leads the user through the walkthroughs, answering questions but not actually helping the user traverse the interface! 1.Start with an introduction, giving a general idea of what the user will be doing. Do not provide the user with an overall guide to the application. 2.Instruct the user to “think out loud”. Gently remind them of this during the session if necessary. 3.Begin with an easy task or two to put the user at ease. 4.If the user sees something unexpected, ask what the user did expect. 5.Do not help the user, unless the user gets completely lost! The point of the session is to determine if the user can make sense of the design. 6.Ask follow-up questions about encountered problems. 7.Solicit suggestions and recommendations. 8.Graciously keep things moving, adopting the attitude that the user can do nothing wrong or right.

The extremely well-prepared designer who updates the paper prototype interface in response to the user’s actions. 1.Be organized, always prepared to change the paper interface, even in unexpected ways. 2.Don’t panic! This is a relatively informal exercise that can be mastered with experience. 3.Remember that the time spent revising the “screen” while the user and facilitator wait usually seems longer to the HC than it does to them (but don’t forget - they are waiting!) Running a Paper Prototyping Session Team Member Role: “Human Computer” 4.Focus on the computer role, anticipating the user’s next action and preparing the appropriate response. Pay particular attention to the user’s eyes and hands. 5.Respond only when the user does something (i.e., don’t over-anticipate). 6.Before the session, organize by event rather than type of component (e.g., place one screen’s components together rather than placing the textbox components for all screens together). 7.Have plenty of appropriately sized blank post-it strips, post-it notes, and sheets available, in case the prepared components are damaged or the user does something unexpected. 8.Keep a brief reminder sheet handy for before and during the session.

Running a Paper Prototyping Session Team Member Role: Observer Take notes during the session, highlighting potential points of discussion that the team will need afterwards. Monitor the VCR and the camera, ensuring that all relevant information is being recorded for later reference. The note-taker & video recording monitor. After Each Prototyping Session... Hold a post-mortem meeting to discuss the areas where the user had problems or made suggestions. Review what happened in chronological order, objectively gathering observations, identifying the larger design issues and then prioritizing. After identifying and prioritizing the design issues, discuss possible changes, but use a rat-hole watcher to circumvent overdoing the debate.

Design Changes After The Session Use iterative refinement, making design changes or changes to the walkthrough scenarios prior to the next session. After later sessions, err on the side of making changes of smaller scope, since it may be impractical to pursue solutions to large problems at this stage. After early sessions, err on the side of making broad changes from which more can be learned. Your team can always revert to an earlier design.

Recap – comparing Hi-Fi to Lo-Fi prototyping

Why Prototype?  A tool to validate the user interface is usable and reveals the structure clearly  Provides a structure that fits the user’s work model  A tool for communication between the design team and the user  User’s vocabulary  User becomes a co-designer  Iterative refinement

Prototyping Medium  High Fidelity Prototypes  A.K.A. Hi-fi, Rapid Prototyping Tools  Examples  VB, Python, …  HTML, AJAX  Powerbuilder  Black Box Coding

Prototyping Medium  Low Fidelity Prototypes  A.K.A. Lo-fi, Paper Prototyping  Examples  Paper  Post-it’s  Tape  Glue  Play Computer

Lo-fi vs. Hi-fi  Time to Build  Lo-fi:  Quick to build  2 to 3 hours depending on number of screens and complexity  Hi-fi:  Screen quick, but black boxing can take a significant time commitment  2 to 3 weeks depending on complexity and team size Score Board

Lo-fi vs. Hi-fi Score Board  Quality of Feedback  Lo-fi:  Maintains focus on work structure and interface elements  Hi-fi:  Reviewers tend to focus on finishing touch issues  Fonts, alignment, colors

Lo-fi vs. Hi-fi Score Board  Changeability  Lo-fi:  Invites change  Because it is easy to change, changes can be made on the fly  Hi-fi:  Developers resistant to change  Too much time and effort invested – feeling of ownership

Lo-fi vs. Hi-fi Score Board  Feature Creep  Lo-fi:  Gives the impression that development is still in design  Hi-fi:  Gives the false impression of being done

Lo-fi vs. Hi-fi Score Board  Program bugs  Lo-fi:  No program bugs – no problem  Hi-fi:  Single bug can bring prototype session to a halt (or kill a project)  Users as Co-Designers  Lo-fi:  Invites the user to provide suggestions  Hi-fi:  Gives the impression of being done

Lo-fi vs. Hi-fi  Timing Studies  Lo-fi:  Cannot be done  Hi-fi:  Can be done  Animation  Lo-fi:  Cannot be done  Hi-fi:  Can be done, but sometimes complicated Score Board

And the Winner Is... Lo-fi! Final Score Score Board Lo-fi Hi-fi