Building a product from scratch is a creative and exciting endeavour. This is not a custom software application designed for a single customer; but a product that hopefully millions will find useful and easy to use.

I've been around the development world long enough to see the Waterfall process in action. Spending months to years writing detailed specifications, then attempting to build software according to those specifications, even if they are dated or wrong. Then the stress of in scope of and out of scope change requests to make some attempt at getting the customer what they really want.

Then there is a section of the agile camp that says no specifications, build the application in code and get frequent feedback from the customer so that they get what they want. As the code-base gets bigger, even with lots of effective test coverage, it takes longer and longer to refactor the code when significant changes are required. The cycle for the customer (product manager for products) to see and test out ideas becomes days and weeks.

Both of these methods ignore user experience design. You need to make software useful AND easy to use. Building it out incrementally may make it useful, but it is not until after you have built out quite a bit of the application that you enough to start designing the user experience. For a product (versus custom software) this is critical.

White-boarding or sketching on paper helps for simple applications. But when you have twenty to over a hundred screen in a more complex business application, paper gets messy. It is also difficult to make changes quickly without redrawing everything. Worse, you really can't get user (customer) feedback on the design.

Prototyping in HTML could be useful, but even without code behind, HTML can take some time to make changes to. It also gives the impression to certain people that you are closer to a working product than you are; it should be a throw away. There is also a tendency to focus on details too early (fonts, formatting, etc.).

Remember that in product development you potentially have millions of customers to make happy at the same time and it is not generally feasible to require user training.

So in the spirit of do the simplest thing that works, we are now using a rapid prototyping tool to mock-up screens in wire frame mode and build in basic interactivity.

This is a very agile and iterative process. We can now mock-up 20-30 pages in a few hours, explore multiple design options and get more realistic customer feedback in a very short time frame. The only shortcoming we've seen, and it is minor, is that you have to have the prototyping software installed before you can demo the interactivity.

One key consideration is that all of the stakeholders are involved in the protyping activities; this includes development. This ensures that the design is practical to build and allows development to contribute their expertise.

This is not Waterfall. You are not documenting rigid specifications up front. What you are doing is rapidly designing the user experience in an iterative and interactive process so that you can avoid unnecessary thrashing.

In "Inspired: How to Create Products Customers Love", Marty Cagan suggests that the user experience designers (prototyping) stay one to two sprints ahead of the agile development teams. This avoids the situation where the designers are working inside a sprint and are feeling pressure to circumvent the customer feedback loop in order to give developers something they can start building.

It is also important that the designers don't get too far ahead. This isn't Waterfall either.

Remember that there will still be some rework during the development process. It is not possible to think of everything in prototyping; especially around the business logic. The designers need to also be involved in the sprints to deal with user experience changes and get those changes reflected back into future prototypes. Don't forget user feedback during actual development as well.

All in all, we are here to build the best possible software for our customers… great software. We also need to do it as fast as possible and make the software supportable long-term.

Avoiding expensive thrashing at the end of project, is key to shipping great software. Use all the tools at your disposal wisely. Agile is not about being rigid in your thinking.

P.S. It seems to be working well for us.