A Prototype is Worth a Thousand Lines of Code

A picture is worth a thousand words.  A prototype is worth a thousand lines of code.  Two key elements of product management – and of agile development are elicitation and feedback.  Low fidelity artifacts can significantly improve both.  Polished, codified prototypes can create problems that prevent you from getting the benefits of communication.

Prototyping Anti-Pattern

David Bernstein has three good quick-read articles about prototyping in the agile zone.  The first one depicts the primary anti-pattern of prototyping – mis-set expectations.

 

As I was walking him through the different screens I could see he was starting to get uneasy. As I talked I could see him becoming paler and tenser, as if he saw a ghost. After a while I asked him if he was ok. He finally said, “You mean to tell me that I just wrote you a check for over $100,000 for less than a week of work?”

Prototyping Caveat

The second article is quick reminder of one of the goals of a prototype.

The purpose of a prototype is to elicit feedback from others or verify a design approach will work. When doing this we generally only concern ourselves with the “happy path” through our code.

A Prototype is Not a Product

David’s third article explores a little more about the mis-setting of expectations, and provides a good parallel from the film industry.

Prototypes are rough sketches without the robustness of a final product and it is often confusing to users when we show them a half-baked version of their project for feedback, even though they know it is not yet finished.

Agile Prototyping on a Napkin

David’s advice is (good and) primarily about using low-fidelity prototypes to avoid disrupting the elicitation and feedback process.  Folks in the user experience community have known this for a long time, and adapted their processes accordingly.  Back in 2006, I wrote about prototype fidelity as part of exploring ways to use this insight in requirements gathering.  Prototyping, in particular, is a great way to elicit implicit requirements – those unspoken (“you should have asked!”) requirements that your customer or stakeholder assumed you knew, or didn’t think to tell you.

Multiple Levels of Interaction

David focused on the initial “will this approach work?” elements of getting feedback on a design – and by inference, some low-fidelity user acceptance testing that the proposed approach will meet your customer’s requirements.  Jan Miksovsky wrote an excellent article (also in 2006) that provides excellent guidance on how much fidelity to build into your prototype, depending on where you are in the design process.  This is important – the type of feedback you need at different stages of your design process varies.  Jan proposes that the first prototypes be rough sketches, just as David points out.  Jan goes on to show how and when to add additional fidelity to your prototypes (read Jan’s article to see his great visual examples).  Like I said, the user experience community has known about this for a long time.

Prototypes Are For Two-Way Communication

The key element, and the reason for creating prototypes, is to get two-way communication.  A prototype is not just a status update about your design.

A prototype is the start of a conversation.

photo of people collaborating [thanks uninen for the image]

Prototyping is not only useful for design conversations, it is critical to understanding your requirements.  Yes, a prototype will you get feedback about the design-execution of your proposed solution.  More importantly, a prototype can help you make sure you’re solving the right market problems.

Prototypes Are More Than Interface Mock-Ups

The first thing we think about, and everything you’ve read so far in this article, is about getting feedback on the user interface of the product.  Prototypes are also useful for gathering business rules*, understanding system complexity, and defining, clarifying, and validating requirements.

*In that article, I show prototypes as “not being useful” for gathering business rules.  At that time, I was thinking in terms of interface mock-ups only, not other prototypes.

Use interface mock-ups when you need feedback about user interaction.  Use other artifacts when you need feedback about other aspects of your product.  You can use prototypes as an active-listening technique when gathering market data too.  There are lots of ways to draw stuff to help with communication.

I’ve regularly used flow charts to prototype processes.  Within those flow-charts, which are initially prototypes of how the product will behave, are decision diamonds.  Those decision diamonds prototype the enforcement of business rules within the to-be-created product.  In the spirit of DRY (don’t repeat yourself), a quick polishing of your process diagram can serve as a persistent artifact of the requirements.  Just like a user interface mock-up.

In more complicated scenarios, I’ve also used UML statecharts and data flow diagrams to prototype behavior.

In the section on up-front planning in last week’s article on risk management and release cadence, I talked about the mental leap that people need to make to envision a product that doesn’t yet exist.  Prototypes are like big springboards that help people leap that chasm of imagination.

Important Safety Tip

Don’t use the wrong prototype (mock-up, flow chart, etc) for the wrong conversation or with the wrong stakeholder.  Showing when and where business rules are being enforced (in the process being designed) is great for getting feedback about your interpretation and potential embodiment of those rules.  It will be a disaster if you try and have this conversation with someone who is not the owner of those policies – like a representative user.  Sometimes, policies are “owned” by non-technical people who struggle to read diagrams.  You may have to walk them through how the diagram works.  They’re smart – they’ll get it.

Just remember – use the right prototype to emphasize the right ideas, and elicit the right feedback.

 

Post to Twitter Post to Facebook

This article was published on Monday, October 25th, 2010 at 9:09 am and is filed under Agile, Business Analysis, Business Rules, Interaction design, Interface Design, Product Management, Requirements, Requirements gathering, Software development, Uncategorized, UX.
You can leave a comment on this post

28 Trackbacks

  1. By Hugo Pickford-Wardle on October 25, 2010 at 3:28 pm

    RT @sehlhorst: A Prototype is Worth 1000 Lines of Code http://goo.gl/Kq7N Latest on Tyner Blain #agile #ux #prodmgmt #baot

  2. By Andrej Ruckij on October 25, 2010 at 3:33 pm

    RT @sehlhorst: A Prototype is Worth 1000 Lines of Code http://goo.gl/Kq7N Latest on Tyner Blain #agile #ux #prodmgmt #baot

  3. By Mike Cottmeyer on October 25, 2010 at 5:47 pm

    Interesting Post… A Prototype is Worth a Thousand Lines of Code http://dlvr.it/7Wv45

  4. By SolutionsIQ on October 25, 2010 at 6:18 pm

    A Prototype is Worth 1,000 Lines of Code http://ow.ly/2Z4Ys The right prototype emphasizes the right ideas, elicits the right feedback

  5. By XP Injection on October 25, 2010 at 7:06 pm

    RT @mcottmeyer: Interesting Post… A Prototype is Worth a Thousand Lines of Code http://dlvr.it/7Wv45

  6. By UXfeeds on October 25, 2010 at 7:41 pm

    A Prototype is Worth a Thousand Lines of Code | Tyner Blain: A picture is worth a thousand words. A prototype … http://bit.ly/aQboTh #ux

  7. By UX Feeder on October 25, 2010 at 7:51 pm

    Delicious: A Prototype is Worth a Thousand Lines of Code | Tyner Blain: A picture is worth a thousand words. … http://bit.ly/aQboTh [UX]

  8. By Gonçalo Borrêga on October 25, 2010 at 8:43 pm

    RT @mcottmeyer: A Prototype is Worth a Thousand Lines of Code http://dlvr.it/7Wv45 – 'use it also to check market acceptance', fail, learn

  9. By markbick on October 25, 2010 at 10:27 pm

    RT @mcottmeyer: Interesting Post… A Prototype is Worth a Thousand Lines of Code http://dlvr.it/7Wv45

  10. By kinaze on October 26, 2010 at 12:17 am

    A Prototype is Worth a Thousand Lines of Code:
    A picture is worth a thousand words. A prototype is worth a thousa… http://bit.ly/buXtGC

  11. By Andrei Berechet on October 26, 2010 at 2:40 am

    Good article about how light prototyping sparks interaction http://pulsene.ws/csVh # agile

  12. By Kees Dijk on October 26, 2010 at 6:37 am

    Good morning, reading "A Prototype is Worth a Thousand Lines of Code" http://tinyurl.com/37nz9kl

  13. By Rymatech on October 26, 2010 at 1:53 pm

    Very good articles on whther or not you should use prototypes http://bit.ly/bk6SU7 #prodmgmt

  14. By 3kwa on October 26, 2010 at 8:08 pm

    concures, a prototype is the start of an enriching two way conversation (http://bit.ly/aPORl6) alas sterile when in-bred!

  15. By Cliff Gerrish on October 26, 2010 at 8:55 pm

    A Prototype is Worth a Thousand Lines of Code http://ff.im/-sHqXs

  16. By Sébastien Douche on October 26, 2010 at 11:57 pm

    A Prototype is Worth a Thousand Lines of Code – http://bit.ly/aFPXFH

  17. By Digory on October 27, 2010 at 1:00 am

    A Prototype is Worth a Thousand Lines of Code – http://goo.gl/tNW3

  18. By Vijay Santhanam on October 27, 2010 at 1:21 am

    RT @digory: A Prototype is Worth a Thousand Lines of Code – http://goo.gl/tNW3

  19. By Ram Vijapurapu on October 29, 2010 at 12:42 am

    RT @sehlhorst: A Prototype is Worth a Thousand Lines of Code http://bit.ly/aMAQo4

  20. By Griffith BA CoP on October 29, 2010 at 6:52 am

    Interesting post … A prototype is worth a thousand lines of code … http://bit.ly/aLHqmW

  21. By Mhd Zaher Ghaibeh on October 29, 2010 at 7:02 am

    A Prototype is Worth a Thousand Lines of Code | Tyner Blain http://bit.ly/bv2H2p

  22. By Alaeddin on October 29, 2010 at 9:31 am

    RT @sehlhorst: A Prototype is Worth a Thousand Lines of Code http://bit.ly/aMAQo4

  23. By Seilevel on October 29, 2010 at 4:16 pm

    A Prototype is Worth a Thousand Lines of Code http://dld.bz/3XAy

  24. By Shailesh Gogate on November 2, 2010 at 8:33 am

    A prototype is worth a thousand lines of code (A picture is worth a thousand words). #ISVs SpadeWorx's prototype facto…http://lnkd.in/b-psQH

  25. By Seilevel Software Requirements Blog on November 12, 2010 at 9:39 am

    [...] was recently reading Scott Sehlhorst blog post on prototypes, which is a nice discussion on the value of prototypes, but also includes some of the challenges of [...]

  26. By QuickLinks for November | (Agile) Testing on November 30, 2010 at 6:07 pm

    [...] A Prototype is Worth a Thousand Lines of Code – use the right prototype to emphasize the right ideas, and elicit the right feedback. [...]

  27. By André Simões on March 29, 2011 at 10:59 am

    By @sehlhorst: A Prototype is Worth a Thousand Lines of Code http://bit.ly/aMAQo4

  28. By Qurie de Berk on October 12, 2011 at 11:19 am

    A Prototype is Worth a Thousand Lines of Code : http://t.co/c9apAsIn @sehlhorst

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>