- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
When your best is too much
Opinions can be strong and diverse in the Information Architecture arena--for example, just try and find consensus on the ideal wireframing tool. Granted, this is an easy target because everything currently available is decidedly non-ideal in all situations. Other issues seem to attract less debate and may, in time, provide one or more proven strategies we formalize as “best practices.”
I've recently run across several articles on prototyping that convey a notably consistent viewpoint. The authors’ common thread—that we are too-often prone to invest time, effort and budget producing an over sophisticated prototype—is certainly self-evident, but this impulse nevertheless presents a real temptation for designers. We want to dazzle clients with our artifacts or simply exercise our creativity by “filling in” design elements to enable us to visualize the finished product before all the design work has been thought out.
Kathy Sierra, in her blog, Creating Passionate Users, advises Don’t make the demo look done, noting that the level of fidelity of a work-in-progress sets expectations that can ultimately backfire on the designer. Her bottom line: How “done” something looks should match how “done” something is.
Sierra’s second point goes beyond perceptions and addresses the actual point of demo-ing a prototype to team members and stakeholders: The more “done” something appears, the more narrow and incremental the feedback. A concept executed to a level of fidelity that makes it look almost completely done will elicit detailed tweaks to specific features, while a rough sketch (even if produced with an application) allows reviewers to question higher-level features and consider bigger changes. She argues that even more revolutionary, big-picture changes are enabled by eschewing screen representations entirely and instead presenting storyboards or use cases. Her advice? “If you want big picture, make it fuzzy!”
Henrik Olsen has two worthwhile articles on prototyping available on his website. The first, Balancing fidelity in prototyping, acknowledges the hesitancy of designers to show clients something that appears unfinished, but immediately notes that the “fact is that prototypes by definition are unfinished.” Excess visual detail in prototypes subverts the effectiveness of the iterative design process and usurps the role of the graphic designer.
Olsen’s most interesting concept regards the potential breadth and depth of the prototype. He defines breadth as “the scope of features covered by the prototype,” while depth is “how deep the prototype goes into each feature.” He advises that a successful prototype will not compromise on breadth, but should limit the amount of depth.
In Olsen’s more recent article, intriguingly titled The dark side of prototyping: How to steer clear of the pitfalls in prototyping, the author is quick to reassure readers that there aren’t really any downsides to prototyping, but there are some banana skins to steer clear of. He identifies these perils as (1) Not aligning the design with project constraints; (2) Going high-fidelity early in the design process and (3) Not involving colleagues.
Topics: Prototyping
Leave a comment
About Pathfinder
Recent
- Automated Deployments Rock
- Bandwidth profiling Flex projects and more with Charles
- iPhone SDK: UIViewController Testing & TDD
- Icons are evil; so are menus - unless you do them right
- The Truth About Designing For Security
- GWT, Gadgets and OpenSocial, Part 2
- Has Many has_many: A Refactoring Story
- The Hidden Power of Canvas
- Review of fixture_replacement2 plugin
- Chess Game Viewer in GWT
Archives
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006

