When end users get involved in the final stages of testing, light bulbs go on, and they often have an "aha" moment. Unfortunately, that is often too late.
Frank R. Parth
Prototyping is as an example of a fast-fail strategy in action. And such fast fail strategies increase R&D productivity by clearing the development pipeline of flawed or failing products.
When prototyping we don’t expect the prototype to work. It is not the finished product. But by prototyping, the developer gets rapid feedback on what will work and what won’t; those features that are useful and those which will never be used. We want to learn what works and what doesn't and move on.
Often the user is unable to externalize their needs, to verbalize or express their needs. However, the user knows what they like.
“I may not know much about art, but I know what I like.”
Prototyping allows the user to better express their needs. And the user provides valuable feedback to the developer allowing undreamt of features to be incorporated into the next release. It is a partnership endeavour. Companies must seek to engage a partner who can help us define our needs.
This approach does not always sit well with the old-school “customer-vendor” mentality. This more traditional approach begins with the user developing a detailed specification. This can be a lengthy process. The user is often ill-equipped to develop the specification. This specification is then offered to tender. When invited to tender, those with integrity will attempt to alert the customer to inadequacies or deficiencies in the specification. Sadly, this is not something the customer wishes to hear. And these companies are usually not awarded the contract. Instead, the preferred solution provider delivers exactly what the customer asked for - often within budget and on time. However, they make their money once the real users encounter the product for the first time and the inadequacy of the specification becomes apparent to all.
Special thanks to thingsdesigner.com for a variation on tree swing. Public Domain
The Art of Specification. The system as a) what the customer asked for, b) as agreed in the functional specification, c) as implemented by the team on the ground, and d) what the customer needed. Note that most of the "fixes" in c) were unbudgeted and doubled the cost of the project. Note also that the solution is unstable and requires constant support. Furthermore, note that solution d) is the design recommended by the firm who were not awarded the contract.