Why Developers Should Prototype

Prototype, this is a term usually thrown around by designers and other professionals in the UI/UX space. It is such a shame that the practise is not nearly as popular in developer circles especially considering the great savings in time and cost it affords its practitioners.

A prototype is defined by Wikipedia as an early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from.

As I have said before waste is evil that includes waste of your own time. In this entry we will be discussing how prototyping is an essential tool in every developers toolbox.

A picture is worth a thousand words

Even for the most eloquent humans, expressing their ideas in words is usually a challenge. Now let us not kid ourselves, as a group we are not particularly eloquent. Prototypes provide a far clearer channel of communication.

By sharing your idea using even a low fidelity disposable image you will communicate a wealth of information.

Manage scope creep

No matter the tool we use there will always be a bit of ambiguity between what you and the client think needs to be built. Why not clear out the air by instead agreeing on a prototype?

I know of a friend of mine who keeps the initial sketches till the end of the project just in case the client gets creative on features but does not want to finance the creativity.

Run experiments

After spending months building a product that no one wanted, Eric Ries quickly discovered that the market does not care about effort. He then started the Lean Startup movement. I highly recommend you pick up a copy of his book The Lean Startup.

A key idea in the book is that you should not commit too much before you have validated your ideas. Prototypes are perfect for this type of work. They are easy to build, show and then discard.

Incremental development

If you estimate it will take you more than a few months to complete any feature, think if you could get some value by instead first building a prototype of the feature. If the feature works and is accepted then go right ahead and flesh it out to full on feature.

This may not be a very popular way of developing software but at least you will not be forced to discard hundreds of hours in effort if the end user rejects it. If the feature is a success then you already have production code ready and you just need to add a few more bells and whistles.

Tap into the most powerful process

In 1975 John Gall came across this pithy observation

    A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system

Evolution is a very powerful process and you want it on your side.

One way of doing this is by building prototypes and evolving them based on feedback from the stakeholders till a system that is useful emerges.

How do you use prototypes in your own practise? Tell us in the comment section below or tweet at me @jchex.