We’ve all heard the term Rapid Prototyping with regards to web projects, but what does it actually mean and why should you care? There are a few reasons especially to answer the latter, but first allow me to explain what it is.
The Rapid Prototyping methodology can be reduced to this single phrase: Release early, release often. Let’s analyze that closely.
‘Release early’ doesn’t mean you have to work faster and employ more resources to release your web project sooner, but rather it means you release the project sooner on a reduced feature set with the intention of revising and adding to it often.
What is the advantage in following this seemingly obtuse practice, I hear you cry? The best way to answer that question is to compare the rapid prototyping methodology to the traditional development practice.
How a traditional web project is carried out
At some stage in your career most of you would have been involved in a large scale web project that involved many man hours, lots of over time and way too many heated discussions about taking the project in a certain direction. The project plan usually goes something like this…
- Gather full requirements
- Plan
- Long build cycle to full specification
- Test
- Deploy
The goal is to release the final project into the wild in a completed state with everything that was originally required, and then try to get users to adopt the site in the state delivered to them. On the surface it doesn’t sound so bad, but there is a better alternative.
How rapid prototyping works
The main difference is, in this model we plan for a short build cycle by committing to a lesser feature set, which will allow us to launch earlier. This way the product is out in the wild establishing a user base and gathering feedback sooner. The feedback received from both the users and your client will help decide how to plan the next sprint (short build cycle).
- Gather full requirements
- Plan
- Short build cycle with minimal yet functional feature set
- Test
- Deploy
Here’s how these two look plotted against each other. Let’s pretend this is the same imaginary Project X in an imaginary time line, (though the differences illustrated are relevant):
The advantages of rapid prototyping speak for themselves, but here are a few things I couldn’t relay in my crude chart:
Rapid prototyping:
- Gets the project out into the wild sooner, albeit with a deliberately sparse feature set.
- With the project out there sooner, certain features or aspects of it can fail sooner, which gives you time to rectify.
- Lets you gather feedback from users and the clients sooner, which not only moulds the future of the site, but also provides a sense of partnership to users (they help decide the direction the site will take – things they do and don’t want to see) and a heightened sense of ownership from the client (they become more involved in the process of directing how the site will evolve).
- Affords the opportunity to include previous features that were originally left out, perhaps dump some of them altogether or just change them to suit the user needs.
Traditional project development:
- Has a longer build cycle.
- May miss the mark regarding what the users wanted, but developers won’t be able to make any changes until a lot later.
- May have included features that are totally rejected by users which wasted development time and resources, and again developers won’t be able to make any changes until a lot later.
- Clients have a lesser sense of ownership as they’ve had to sit back and watch the developers make most of the decisions.
- Opportunities for users and clients to feel more connected to the site are missed because the site has been built for them, instead of with them.
In summary
This article has been intended to show the advantages of rapid prototyping against traditional project development. That being said, this doesn’t mean rapid prototyping is always going to guarantee success. There may be no hope at all for a poorly executed plan regardless of which methodology you choose.
For me RP is a winner, and I’ve been lucky enough to have the opportunity to put it into practice on some large scale projects during my career. Presented side by side it seems like the better way to proceed, and I think it’s something every development team should consider.
