Prototyping vs Iterative Development

The problem with rich, custom web applications is that the client often doesn't know what they want until you build it. Even then they probably don't know what they want, although they usually know that is wasn't what you built them :-) . . .

If a client comes to us and has a unique set of requirements, at the very least well work with them in a discovery phase to document a set of essential user stories and well document click by click the default, alternate and error paths for each story. If we are not comfortable with the usability of the solution or if usability is critical, we'll used to build a prototype, but these days we'll usually just build the site to a basic spec and then tweak it if the default implementation doesn't meet the clients needs.

If you think about it, a prototype is really a form of insurance. It is allowing you to capture a higher percentage of potential issues with a design before building the app in return for the additional cost of building the prototype. A clickable prototype won't capture all of the issues, and you can capture some of the issues with whiteboarding, comps and wireframes. The decision as to whether to prototype a screen or a flow depends on the likelihood of there being issues that it would pick up, the additional cost of the prototype and the cost of making the changes to the app once it is done.

I generally see two broad approaches. One is to prototype as much as possible and then to send the project out to be built. The other (that you see in many agile shops and that I think is becoming more common these days) is just to build a sensible first cut based on a fairly lightweight description of the app and then just to refine the actual working application itself. At SystemsForge, mostly we'll just build an app for a fixed bid based on a straightforward spec and then we'll just modify the app as required on an hourly basis. As such our approach is more like the progressive refinement of the final app than the "prototype everything upfront" approach. I tend to like this as it has a number of benefits. Firstly, we never build anything the client isn't going to use, so the "waste" in production terms is low. Secondly, even the first cut works, so at any time the client can go live with a working application if they run out of time or money. We can then just add progressive enhancements over time. Thirdly, because we generate our apps, we have a default way we tend to build things anyway. If someone wants to add or remove functionality within our model (add properties or validations or relationships), we can add that very quickly, so the cost of change is very low. If the client wants us to make a screen or object work in a way that is outside how we usually do things, it's going to cost as much to do it now as later so we're just as well to give the client something that works the way we usually build things and then once they've clicked through the working app they can make an informed decision as to whether it's worth spending the extra few hundred dollars to customize the way that the screen works for their app. Of course, the reason we can do this is that our cost of changing the applications is very low and we're comfortable enough with the architecture of our apps that we don't mind making change after change after change and just refactoring to make sure the overall design stays clean.

What are your thoughts on prototyping vs. iterative development?