About Scott Sehlhorst

Scott is a strategy and product management consultant. He has also worked as a business analyst, technical consultant, software developer, project manager, program manager, and electro-mechanical design engineer.

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.

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.

Reference: A Prototype is Worth a Thousand Lines of Code from our JCG partner Scott Sehlhorst at the Business Analysis | Product Management | Software Requirements blog.

Related Whitepaper:

Applying Agile Principles To The Development of Smarter Products

Agile development has become a cornerstone of most software development organizations.

Marked by iterative processes that deliver incremental value over time, agile development has enabled organizations to manage software complexity more effectively and to improve quality and time to market compared with previous development processes.

Get it Now!  

Leave a Reply


5 + = nine



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books
Get tutored by the Geeks! JCG Academy is a fact... Join Now
Hello. Add your message here.