I was reading an article about Lean UX, and it made some interesting claims about the role of a prototype.
The author claims that prototypes should not communicate everything, and that they can’t serve as the sole source of documentation and specifications.
As described in another article, a prototype can be a really good option for demonstrating page flow and how features interact with each other, and it can be really handy for measuring user engagement.
But I would hesitate to take it any further than as a sales tool. If it is supposed to cover every aspect of the final product, then it is no longer a prototype – it is the product. And it becomes very difficult to charge money to ‘finish off’ what appears to be a fully working solution.
Secondly, shortcuts taken during the prototype build can become crippling if they make their way into the official spec. For me, a prototype is going to contain a huge number of funcitonal stubs, canned database responses, fake personalistation… the list is long. If people start referencing what the prototype does, then you’ve got a problem – expectations have been set that have to be undone.
If you’re making a prototype, I would recommend explaining very carefully what it is intended to demonstrate. Find out what the key bits of functionality that people are interested in are, and build those in some detail, but leave out everything else. And make damn sure that people document the final desired functionality without referencing the prototype.