Tectonic's Head of Product Dan Parry looks at why prototyping is so important - and how to go about doing it.

As part of our support for grantees on Comic Relief and Paul Hamlyn Foundation's Tech for Good Build programme, customer research company Tectonic delivered a workshop on prototyping and testing potential solutions with end users. Here, Tectonic's Head of Product Dan Parry looks at why prototyping is so important - and how to go about it.

‍Before we started our customer research company four years ago, we had a music technology company. Our thesis was that musicians are like small businesses, and as such need to treat themselves that way. We did all the things startups are supposed to do. We raised money, we built a good product, we did all the marketing.

But it didn’t work out.

One of the many (many) reasons was because we didn’t understand our end-user well enough. 

We should have spent more time learning about our customers' actual needs and less time building and raising money. It turns out that early stage DJs were a pretty difficult customer type for the type of business we were trying to build – and we could have learned faster and in cost effective ways with prototypes.

‍What is prototyping?

Prototyping is the experimental process of building versions of your idea, product or service in different levels of fidelity to learn from your end-users. 

You can create paper prototypes:

Image showing paper prototyping

Digital prototypes using Invision, Sketch or Figma

Image showing low, mid and high fidelity prototyping on mobile screens

No-code prototypes using software like Glide, Adalo.com or Softr.io

Screengrab of the Glide site

You can not only use code to prototype ideas, but you can use it to prototype features or people’s willingness to pay.

Screengrab of the Buffer site

Above is a really great example from Buffer testing people’s willingness to pay for a product before it’s even ready.

You can also prototype in reality. If you wanted to start a vegan burger chain, rather than buying 100 vacant spaces across the UK and turning them into restaurants, you might want to start out slow.

You could make some delicious burgers and give them to friends and family, then try a food stall, then work your way up to a kitchen somewhere, and eventually get your nationwide chain.

In order for you to create successful prototypes, your experiments should be framed around what you want to learn.

“I want to learn if I’m solving a real problem”

“I want to learn if this is the right solution”

“I want to learn if I can acquire more end-users”

You can prototype different aspects of your project including your value proposition, features, marketing messaging, marketing channels, business model, etc…

One thing to remember is that you can mix and match your prototypes in order for you to learn what you need to at the right time.

Prototyping works best after conducting some of your initial user research interviews. By speaking to your customers you can validate or invalidate broad assumptions and build prototypes to test specific aspects of your project.

Think like a (mad) scientist

When asking people to think of famous scientists, Frankenstein is often amongst the first to come to mind (depending on your propensity for science fiction). He’s probably not the best example for a few reasons, though! So as prospective scientists in 2021 you need to keep structure and mindfulness in mind when running your experiment (while trying not to create monsters).

Give yourself a framework you can use to ensure your tests are set up in the best way for you to learn.

  • Outcome – What do you want to learn?
  • Timeframe – When do you want to learn it by?
  • Variables – What variables need to change?
  • Criteria – How will I know if this experiment is successful?

Try not to change too many variables when running your experiments as it’ll make it more difficult to understand and attribute weighting to what’s working and what’s not i.e. is my idea bad or am I showing it to the wrong end-users?

Example variables might be:

  • Users
  • Features
  • Product
  • Screens
  • User journey
  • Location
  • Etc...

And remember to be kind to yourself. If your experiment or prototype doesn’t get you the results you’re after, you didn’t fail – your experiment did. Separating yourself from the experiment is the best way to remain objective, and is far better for your mental health.

How can you prototype your idea?

There are multiple ways you can prototype your idea.

  • With pen and paper
  • With existing tools and services to learn how they are currently used
  • With digital mockups at various levels of fidelity
  • Low fidelity
  • Mid fidelity
  • High fidelity
Image showing low, mid and high fidelity prototyping on mobile screens
  • With physical mockups to test materials 
  • With no-code tools like www.glideapps.com, www.softr.com, www.adalo.com
  • With code e.g. if you want to test a new feature with an existing platform, you can add a button and see how many people press it.

Another thing to remember is that you can run multiple experiments to try and learn the same thing for example:

“I want to learn if people understand my offering”

You can:

  • Create multiple landing pages at different levels of fidelity
  • Watch people use your product and talk about their experience
  • Create different no-code prototypes 
  • Test marketing messaging and track conversions
  • Etc...

‍Finding success

In order to know whether or not you’re right, you need to know what success looks like. If all things go to plan, what is the outcome you’re aiming for or expect and why?

Writing these down will help you structure your experiment. It’s a bit like knowing the end of a story before you start writing. It’ll make everything easier to track.

And speaking of tracking, it’s important to track all of your assumptions and progress with your experiments.

Your assumptions are your best guesses, but they are guesses and as such may be biased by your lived experiences. Writing down your assumptions helps you become more aware of them and bring them to the forefront of your mind. And when they are there, it’s easier for you to set up the experiments to understand whether the assumptions have been validated, invalidated or most importantly, partially validated.

‍To be or not to be?

When you’re running your experiment you’re trying to understand quickly if your assumption is validated (true), or invalidated (false). These are very important to know. But it’s even more important to know quickly if something is partially validated as it has two states (both true and false).

Taking on a venture where your assumption is both true and false means that you could bake an error into your plans.

Let’s use a brick and mortar example:

Say you’ve been running a restaurant for a year or so. It’s pretty popular.

You have a new pizza that you think is delicious, so you decide to do a Hawaiian themed night where the only thing on the menu is a pineapple pizza.

There’s a queue at the door, but at the end of the night half were devoured, and the other half were left unfinished.

Your job would be to find out why this was the case as quickly as possible before you can fully decide what your next actions should be.

Who were the customers that ate all the pizzas?
What did they love about the pizzas and why?
Have they been to your restaurant before?
What did they expect?
Who were the customers who didn’t finish their pizzas?
What didn’t they like about the pizza and why?

Etc…

The faster you can determine these details the easier it’ll be to make a decision about what pizzas you should offer. (You should always have pineapple pizzas by the way. They are delicious.)

Summary

Prototypes are best to use when you want to learn something specific about your idea/product/service/venture (delete as appropriate). It’s best to treat your process as a scientist might so you can learn quickly whether or not you’re on the right track. The faster you learn, the faster you can add value to your end-users and change their lives for the better.

About Dan and Tectonic

Dan is the Head of Product at Tectonic – a hyper targeted customer research company. We help B2B companies and not for profits make evidence based decisions by finding their exact target end-user, conducting structured interviews, and analysing the data.