Notes on the UIE podcast "Roughing it with Interactive Prototypes"

New UIE podcast "Roughing it with Interactive Prototypes" (30 min) speaks to how interactive prototypes are effective design tools for creating web apps (rather than being a design deliverable) allowing design teams to resolve complex design issues.

Listen here:
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?i=51189724&id=119728465

Take-aways:

• interactive prototypes are working design documents but they look and feel like a web site
• they are part of an ongoing evolutive process
• they allow for constant dialogue during the design process
• the objective is to reduce "tool time" to spend more "goal time" thinking about what goes into the design, thinking about the goals of the design
• "tool time" is the time it takes to use a tool to put things down "on paper" and communicate it
• prototype is driven by the need for what stuff warrants usability testing
• prioritize the stuff that is important and difficult versus important and easy
• the big time effort comes from putting thought into design... a page a day
• we don't move straight to interactive prototype, but start with sketches that allow us to prioritize
• clients feel that this goes beyond the "deliverable" process and represents tangible progress
• seeks to capture as much interaction as possible as quickly as possible
• it gets the design patterns and the crux of how the site works and functions
• helps capture richer interaction
• in agile projects, the choice of what to prototype comes from the Stories
• it takes time to do this... but it takes a surprising long time to create Visio/Omnigraffle wireframes as well
• use jQuery to fake javascript
• don't dive right into HTML as this will take up your time and take time away from thinking
• peer review at the end of the day is part of the process
• we make lots of design process mistakes to get to the point... to get to this work method
• one big mistake is treating this as a deliverable and spending too much time on stuff that's not important, even if it only takes 20 minutes to do an "About" page, this is 20 minutes you don't dedicate to user interaction issues.
• it doesn't need to be complete, but it does need to do its job.
• spend your time on the problems that need rendering, need solving, not the obvious. Start with the difficult interactivity issues.
• one purpose of this is to allow for doing usability testing early on in the project
• you can't test a function in isolation but as part of a proper process which does mean that you need to create prototype for those things that lead to those difficult parts