I mentioned in my last post that I wanted at some point to share more of my thoughts about using prototypes when developing highly complex software solutions.  While the ideas are fresh in my mind I wanted to write some about this now.

When I talk about prototypes I do not mean the first ‘beta’ version of a product that you want to get clients to start using.  Several steps before releasing anything to clients – while the product idea is being developed – prototypes are used to test out specific design and functionality choices before the actual coding work begins.  Prototypes can be very useful as part of the development process related to user interface and user experience design.  The use of prototypes is a common feature of Agile software development, and if you read many books or articles about the Agile approach you are likely to find strong support for the value of rapid prototyping.

Broadly speaking, I think there are two key benefits to using prototypes instead of relying simply on user stories and wire frames.  First of all, prototypes facilitate ‘failing quickly’ by getting potential approaches in front of real users with limited developer involvement.  Even high-fidelity prototypes are generally built by designers instead of coders, with the goal of getting users to interact with something that looks and functions like a piece of the end-state product without all of the underlying data structure and code base.  These prototypes allow validation of good ideas for both design and functionality – and the quick discovery of bad ideas before any investment in coding has been made.  This way product teams can get rapid responses about what potential users will value in the product and easily pivot to new approaches through a simple iterative process of demonstrating the prototype, reviewing the responses, adjusting the prototype, and then cycling through again.

Not only do prototypes allow for rapid validation and quick failure, they also form an important and useful bridge between even the best wire frames (sometimes called low-fidelity prototypes) and the actual product.  Rather than just providing developers with user stories and wire frames that describe the ways a feature will solve a market problem, high-fidelity prototypes give a real example of validated functionality that can be used to guide the development and testing process.  As such they can provide a great supplement to user stories as coders begin building the actual product.  You can see in the following link an example of the disastrous consequence of a simple disconnect between wire frames and the end product that could have been avoided by adding a prototype to the development process: http://www.youtube.com/watch?v=rTZXp0dSzTw.

While prototypes – and especially high-fidelity prototypes – offer some real advantages in the Agile development process, there are also some potential problems with utilizing them.  One common pitfall happens when designers, product managers, or developers fall in love with their prototypes and have a hard time letting go when these initial attempts do not receive strong market validation.  Doggedly clinging to one approach just because the prototype looks nice can prevent the kind of learning that the prototype process is designed to facilitate.  And such an unwillingness or inability to move on when it becomes better to do so can lead to problems like this one: http://www.youtube.com/watch?v=aqz_4OgMi7M.

A second short-coming I wrestle with in my current firm is that it can be incredibly hard to capture the nuances and complexity of the kinds of solutions we develop in a prototype.  Many of the feature sets we are building have inter-related components and complicated workflows, and so it can be tough to chunk out one area to design a prototype for.  Mostly I attribute this problem to myself as the product owner; I ought to be better at breaking down our user stories into manageable pieces (that’s what I’m supposed to be doing when we plan for our sprints anyway) and then trusting our designers to build prototypes that capture the core pieces we want to validate.  I ought to be better at this, but I find it is rarely that simple.

A final problem comes from thinking a prototype is ‘client ready’ when it is really more of a shell.  Over-eager sales and product management folks can put pressure on the development team to ‘release’ what was never supposed to be fully tested code.  This can be especially problematic when either the development team or the product manager is confused about the difference between live-data prototypes and user prototypes.  Live-data prototypes require some investment by coders to allow them to function with real client data, but they are still only one step in the process toward fully functioning and releasable code.  You can see this link for more thoughts from Marty Cagan on the value of each type of prototype: http://bit.ly/i1iR9n.

The problem of thinking prototypes are client ready can create real difficulties for product development teams – enough to cause some to steer away from anything beyond low-fidelity prototyping.  One possible approach to a solution is something more like ‘medium fidelity’ prototypes, which are a step beyond wire frames but are intentionally designed not to look production-ready.   Here’s a link to a great piece that describes this whole concept well: http://bit.ly/bC1gSB.

In spite of the problems that I have encountered trying to use prototypes, I remain convinced that they offer some real benefits both in the product discovery phase of figuring out what to build and in the product delivery phase of actually building it.  There are certainly more benefits and problems to using prototypes in software development than what I’ve mentioned above (here’s a classic story about Google and prototyping: http://bit.ly/5vNqB).  We continue to explore the best ways to employ prototypes in our product development strategy and, while we have a lot to learn I think we are already seeing some benefits.  There are lots of great ideas out there about how to use prototypes (here’s yet another link about a specific approach on top of the ones I shared above: http://bit.ly/11aIEzN).  In this as in all areas of Agile I hope to continue learning from my team and from others in the industry.  If you have any thoughts or want to suggest things for me to read please post them in the comments or tweet them to me @asbiv.  I think there is real power in using prototypes in development in spite of the potential pitfalls, but I know that in truth it’s not that simple.