When to Prototype

  • When your product is multi-functional
  • When there’s a steep learning curve for newbies
  • When you need buy-in from diverse stakeholders
  • When you find it difficult to describe with words and arm-waving
  •  When you are not sure of the requirements

    Prototyping is most beneficial in systems that have lots of interactions with the users. Apps that require inputs, decisions, logins, and manipulations.

The more things that a person can do with your system, the more combinations there are, and the more ways there will be for them to forget, lose their place, make errors, miss the point, and get frustrated.

Those who design and build the software and interface get to be really really familiar with all the nooks and crannies of the interactions, so they become blinded to the “first time experience”. They know that once a new user has done something a couple of times, it gets really easy, and their focus groups have proven that all they need is 15 minutes to become a pro.

What you are going to be selling is always a first-time experience.

You need to build a prototype that reflects this – so you can test out your prospects’ first-time experience. If they take more than a few seconds to understand how to interact, then you’ve lost them for good.

Another scenario that demands prototyping is whenever you have a team of people from a mix of backgrounds/expertise all working together to launch a new product.

A prototype is essential to allow everyone to see what you’re talking about, to be able to compare notes on the same thing, using the same language.

You can use even the roughest paper mockup, to demonstrate and communicate – to the boss (or your business partners), to developers, graphic designers, investors, banks, sales and marketing.

Each one of these people might be able to point out valuable insights extraordinarily early in the product creation cycle, that will save countless hours, get you to market quicker, and reduce your risks.

Not sure of your software/hardware requirements?

A first-pass (alpha) prototype is a great tool to use for getting initial cost and time estimates from software coders and data architects. It allows them (and you) to get a better appreciation of what data will need to be stored and manipulated, and what the likely hardware needs are.

Your Rosetta Stone

In product development, the minimum viable product (MVP) is a method that exposes your idea to potential customers in a tangible form, so that they can grasp your vision, and give valuable feedback before committing resources. It’s a way to find a profitable product/market fit, or to exit gracefully. Minimum time and cost, minimum risk.

The prototypes that you build in the process also become nice little Rosetta Stones, which you can use to translate between client-speak, customer-talk, sales- marketing- and tech-nish.

Specifications usually grow from of a team of people with different backgrounds, different skills, different expectations, and vastly different ways of talking about abstract ideas and concepts.

Let’s use a simple web app as an example:

The developer takes the specs, and sees the words “landing screen”.
He knows what that is, and he builds a “landing screen”, a screen that welcomes people to the app, and has a bunch of buttons for all the possible actions that a user could want.

Oops, the marketing guy also knows what a “landing screen” is – that’s the place that prospects are directed to land on when they click on a Google AdWord.

Oops, the CEO also knows what the “landing screen” is – that’s where the company logo goes, and the corporate vision is explained.

Even a quick-and-dirty prototype has the power to immediately translate the phrase “landing screen” into something that everyone disagrees with. This is a good thing. Everyone’s now on the same wavelength. Everyone is speaking the same language.

People are very flexible with the labels they use for things, and maybe this team decides that in future they are going to call this the “dashboard”, or the “buzz box” or whatever …

One thing’s for sure, if they had handed over their beautifully worded specs as a “final design specification” and waited for a final product to be built, then they’d be in trouble.

The few extra hours spent on a prototype are worth it every time.