About Scott Sehlhorst

Scott has been helping companies achieve Software Product Success since 1997, and started Tyner Blain in 2005. 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. Scott has managed teams from 5 to 50, and delivered millions of dollars in value to his customers.

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.

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.

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.

Newsletter

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.

Email address:

Join Us

With 1,043,221 monthly unique visitors and over 500 authors we are placed among the top Java related sites around. Constantly being on the lookout for partners; we encourage you to join us. So If you have a blog with unique and interesting content then you should check out our JCG partners program. You can also be a guest writer for Java Code Geeks and hone your writing skills!

Disclaimer

All trademarks and registered trademarks appearing on Examples 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. Examples Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.