You may have heard many good things about prototyping. How much money it has saved, how much time it saved, how much effort it saved, etc. Those are absolutely true, nothing wrong with them.
But think a second, is everything is good about prototyping? Do we have any downside of it? Well may be. Lets look at that further and focus only on the throwaway prototypes here.
It Kills Thinking
What? Should the prototypes suppose to generate ideas? Yes it is true but;
Imagine that you have a busy customer. You discuss the requirements with him (may be in high-level) and step by step, you come up with the prototype. You will get the feedback on the Prototype. But when time passes (and if the customer gets busy) he tend to agree with what you come up without much thought from his end. The main reason for that is customer knows that you have got hold of the requirements and therefore he takes easy and pass the responsibility of requirements to you. Good to be a customer. 🙂
Secondly what about the development team? Isn’t it common that when you have a prototype, they tend to follow exactly as in the prototype rather than thinking what is correct? Need not to mention that Prototype can be wrong. One common excuse on this lack of thinking is that the prototype has being discussed many times and agree with the customer so that is the ultimate truth and why change it. This happens specially if the person who did the prototype is not a permanent member of the team.
Effort of Maintenance and Level of Confusion
Once you build the Prototype, you need to maintain it. If not, it can lead to many confusions.
There are two situations where a half baked prototype can lead to confusions.
- In the Middle of Requirement Elaboration – In this case, you start building the prototype to keep the requirement elaboration flowing. Then after each round of discussion, you keep on updating the prototype based on the feedback. After sometime, you get tired of updating and most importantly now you are familiar with the logic of the system. These two factors lead not to update the Prototype. Sometimes you tend to refer to the meeting notes. The consequence of this is that you are nowhere with the requirement documentation. The Prototype is not complete as well as there is no proper requirement document.
- During Development – Secondly even if you lucky to sign off a complete prototype at the end of the requirement elaboration, but there will be many further discussions during the product development. These updates to the requirements get rarely reflect in the Prototype. This can lead to problems when the acceptance testing is done. When the Prototype is used as a requirement document, then you will find it not updated and confusion happens on what is the correct requirement.
Therefore it will become mandatory to maintain the Prototype if you start building it and to maintain a Prototype throughout the Project Life Cycle itself is a project of its own.
Isn’t it good? May be in certain times, but not always.
The reliance of Prototype will eliminate or reduce the requirement documentation. This can lead to many different kind of issues. To list a few
- Difficulty in freezing the scope – Many customers would require a requirement sign-off. This is difficult when you have a Prototype.
- Inconclusive Requirements – Certain requirements may not be conclusive. For example, it is difficult to describe the different kind of data which will be listed in a grid, through a Prototype. Therefore the developer will not have an understand what sort of data and what characteristics of them to be expected (Domain of the data). To explain further, lets say you have a Grid and you are worried about the alinement, width of the column, etc. A comprehensive document can give inside into those unlike a Prototype.
- Typical Issues of Lack of Requirements Documents – For example, product not confirming to what customer wants, bugs, etc. etc.
What to do with Business Logic
It is true that a Picture is worth of 1000 words but there are things which Picture can not describe. For example, it is very difficult to describe a workflow using a Prototype. In general terms, the Prototype is a very good tool to explain the User Interface but it cannot describe the Business Rules of a system in the same effectiveness.
Loss of Focus
On a blog post in a different line of topic in Prototype, David Bernstein describes that users focus on what is missing rather than what is there in a prototype.
I am a strong advocate of prototype and in which I have seen many benefits (not to mentioned that sales team uses Prototypes win projects as well). I just wanted to list down few points where the Prototyper should be careful so that he can avoid those negatives and come up with great results.