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.

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

28 thoughts on “A Prototype is Worth a Thousand Lines of Code

  1. Pingback: Andrej Ruckij
  2. Pingback: Mike Cottmeyer
  3. Pingback: SolutionsIQ
  4. Pingback: XP Injection
  5. Pingback: UXfeeds
  6. Pingback: UX Feeder
  7. Pingback: markbick
  8. Pingback: kinaze
  9. Pingback: Andrei Berechet
  10. Pingback: Kees Dijk
  11. Pingback: Rymatech
  12. Pingback: 3kwa
  13. Pingback: Cliff Gerrish
  14. Pingback: Digory
  15. Pingback: Vijay Santhanam
  16. Pingback: Ram Vijapurapu
  17. Pingback: Griffith BA CoP
  18. Pingback: Mhd Zaher Ghaibeh
  19. Pingback: Alaeddin
  20. Pingback: Seilevel
  21. Pingback: Shailesh Gogate
  22. Pingback: André Simões
  23. Pingback: Qurie de Berk

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.