How to avoid prototyping pitfalls

[Rss Bot 1]

When you see or hear the word 'prototype', what comes to your mind? Perhaps a scale model made from low-cost material? Or maybe something that can be physically interacted with? 

• 10 top prototyping tools

Either way, in many industries, prototypes are not the finished article – nor are they expected to be. In the web industry, prototypes are a huge part of our lives. They are incredibly useful and informative, but I fear that they are often misused and misunderstood. And this leads to "the perils of prototyping". 

Consider each of the following scenarios...

Prototyping scenario one

A project team is asked to investigate the feasibility of an idea for a new digital product. The developer uses a framework (or many) without justification or research, they take little care when coding and there are no code reviews or best practices. 

It is all hosted on a computer that is in no way near a mirror of a production environment. The developers declare it "pretty much ready" and equally the project manager sees it as "done". 

Stakeholders are led to believe it is ready, and sign it off to be launched immediately. It either goes straight into production with a huge amount of technical debt or takes much longer to launch than expected.

Prototyping scenario two

A project team is asked to demonstrate some new functionality for an existing digital product. The designer throws something together in the modern prototyping software of their choice. This shows interactions, transitions, animations and so on. It doesn't account for any performance considerations or how much complexity is involved in coding it. 

The designer declares it "pretty much ready", the PM/client/stakeholders believe it to be done and sign it off for an immediate go-live. The prototyping software may potentially be able to generate code, but there is no awareness of the quality of it or indeed how easy it would be to integrate into a real working codebase – it may well need to be written from scratch. 

Failure

In both cases the projects are deemed a failure; the expectations of stakeholders, however, were completely disproportionate to the reality due to poor communication from all members in the project team.

Can you see a pattern here? The problem isn't with prototyping per se; it is with those who do not communicate fully to their colleagues/clients about the status of their work at the early prototype stage, and what is still required to make it viable for production (be it an MVP initially or a fully fledged product). They assume that just because the prototype looks finished, there is no further work to be done.

The solution to this problem comes down to taking responsibility. It is the designers' responsibility to understand and communicate that their prototype still needs to be coded (and with that, a whole raft of conversations and tasks need to take place). 

It is the developers' responsibility to communicate what is still needed technically, understanding that it may well require help from other teams. And it is the PM/clients' responsibility to not assume that the work has been finished at this very early stage and they can then start to work on a plan for resourcing the project appropriately.

Taking responsibility

In my opinion, it's a project managers' duty at this stage to clear the way for their team to have time and space to continue their investigations – because it is here that the prototype will really begin to take shape and help to drive the direction of an MVP and beyond. 

Ideas will be reworked, code will be rewritten, but a prototype should not be deemed finished until all pieces of the puzzle have been investigated. This should include infrastructure, security, performance, SEO, content strategy and everything in between. 

These are often forgotten during the product development process – sometimes until just before the go-live date – but why not start earlier? As long as we start to consider all aspects then the entire team (and client) will be given a much better indication of the feasibility of the product. This is what a prototype should really be about.

As web professionals we shouldn't be afraid to say that something hasn't been finished. If we can all communicate in a better way, there will be less failed projects and more joy in developing great digital products for our users. 

This article originally appeared in net magazine issue 296. Buy it here.

Related articles:

• 10 top prototyping tools
• How to choose the right prototyping tool
• How Netflix handles prototyping

View the full article