We have several ways for previewing a piece of software – demos, prototypes, pilots, iterations and even betas. Are all the same? What should I use? I am not sure if my notions about these are global, but I will present them anyway. The whole thought series was triggered by a couple of great posts – Don’t make the demo looked done and When your best is too much.
My thoughts drifted towards, as usual, why would I need to preview the piece of software, and that, I think, holds to key to how cooked the preview should be. Here are my thoughts.
- Demos are, as the word means, demonstrating the use of a software. I believe that the use of a software is tightly integrated with the ROI on it. The demo should highlight it and make it as obvious as possible. I consider that a demo can be done at many stages, even after it is released.
- I have been using a Prototype to get all the stakeholders on the same ground. A lot of times it is difficult to explain an idea, in fact frustrating for both the parties. Nothing better than a prototype to get the point across. I think the main aim is to let the other party see the idea.
- Pilots are proof of concepts for me. To check the assumptions, to ascertain something uncertain – whether it is from technology or business. I consider pilots to be more experimental in nature, fiddling around to see what will work and what will not. The user experience gets a lower importance, unless that is the subject itself.
- Iterations are an approach to evolve a piece of software rather than build it as a single block. There are various benefits – early feedback, more manageable release cycles, targeting the core requirements first. The iterations are essentially built over the earlier ones. The output of iterations is usually opened for testing by the user, so that the feedback is incorporate earlier in the cycle.
- Betas would have been limited to testers if it was not for the Web 2.0 trend. Betas are making the software available to a controlled or global audience and warn that it is unstable. Beta servers a dual purpose, of releasing it so that the word spreads around, and still indicate that it might be unstable. I think that betas can be effectively used for finding out the unknowns that affect the resources. As an example, a website in a beta mode can gather information about the traffic, profiles of users or even additional features and then build it into the website over the time.
One common thread across all these things is that it is for someone else, and to keep the eyes and ears open for the user. All these previews are capable of gathering data that can help you decide the roadmap of your software.
How much a demo or a prototype should be done, in my opinion, will depend on its purpose. If it is the demo of a finished product to display its capabilities, then it can be shown as done. It will help to show the impact on the ROI of the capabilities rather than a technical presentation. However, as Kathy says, sometimes polished demos can result into higher expectations or a narrow feedback. In fact, I find this to be a main reason behind why most of the softwares are built for trying, not using. The previews should neither be election promises nor undertoned, they should be just rightly cooked to remind that the real package is about to follow.