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.
