This clumsy term is my way of referring to different types of prototypes which do not require code (or at least very little). You may have also heard the term vapourware, however I dislike this phrase as it infers little to no substance in the prototype.

In fact, when well-formed, these simple prototypes are an incredible learning tool.

Sometimes the only way to test your ideas is by building something. Many times it’s not, however.

What can you do today?

I often speak to entrepreneurs and startups. I like to listen to new ideas being trialled, problems they’ve overcome, new thoughts, new concepts. These people are catalysts for innovation, and I learn so much from listening in. Although very often I find myself asking the same question, even to seasoned entrepreneurs.

What can you do today to test your ideas?

When you’re in the mode of innovating, and the excitement of it all is accelerating you towards success, it’s hard to be unambitious. Reaching for anything less than a moon-shot feels like failing. But it’s depends how you frame it.

The road to success is not straight, smooth and empty. In some places, there is no road. The fastest way to get to the finish line, or at least a checkpoint, is by not coming off the road.

Success is not a drag race, it’s a scrambling marathon across the desert.

Following the analogy, we’re constantly checking our compass, looking at the terrain we’re about to pass, keeping an eye on our fuel - you get the picture. So we should test our way through our environment in a way which gives us fast feedback, continually. We may be headed toward something audacious, huge, ambitious, but the steps to getting there can almost always be broken down into much smaller leaps.

So what can you do today, to test your ideas? Or in other words, what are your biggest assumptions? What’s the fastest way to turn an assumption into hard evidence?

One way is simple prototypes, as we'll discuss here.

Be irreverant

If you're new to building products, these prototypes which are not 'built' are perhaps the fastest, most impactful way to present and test your product ideas with others. You don't need to be technical; you need to understand your users' problems and be methodical in testing potential solutions.

We should constantly strive to test our ideas in the most reliable, productive, cheapest and fastest way possible. Whether you're 5 years into your product's lifespan, or at its conception, we'll always have presumptions we need to measure against the rigours of reality.

I may differ from some, in that I see a fully-fledged product as an experiment, as much as a simple landing page with a call to action. The difference is simply what is being tested.

A product which is growing quickly and being paid for, is testing whether it can grow quickly and is worth paying for. A landing page with a call to action, is testing whether the call to action is worth clicking. See them both on a continuum, not as a goal vs an experiment.

Seeing every iteration of your product as an experiment helps maintain the irreverence you should show established products, and appreciate that experimentation should be practised daily.

The difference is that established products are built on more experiments, standing on the shoulders of giants so to speak, whilst an early release is comprised of fewer experiments.

If we’re to experiment continuously, we therefore to make sure we’re doing so reliably, productively, cheaply and quickly.

That's why I start with paper and sticky-tape prototypes.

Paper prototypes

A well-known concept in product, paper prototypes are simply a prototype which you’ve drawn on paper (or digital paper). They are a non-functioning mockup of a solution; they don’t ‘work’, at least not scaleably, and are used to elicit feedback from users. They’re as quick to put together as you are able to draw, and are often the first signs of life we see in our product.

I'll show you how to create paper prototypes, from the ground-up, to convey your ideas, but not how to create rich, navigable, clickable versions. If you work with a good designer, they can take care of this, or if you need to product high fidelity prototypes yourself, there are a tonne of great courses to help you get started. You could try Udemy, Springboard, as well as looking at content great design orientated companies create, like Airbnb, Facebook and so on.

Paper prototypes, like everything, can vary in complexity and sophistication, from a simple sketch on paper, to a digital mockup which closely mimics the real thing, that you can click and interact with.

The best way is to start very simply, and increase sophistication as your confidence grows in your concept. If you can sketch an idea in a minute, in two minutes you can get feedback. If you spend ages making your prototype look beautiful, with mimicking complex functionality, and then you put it in front of a user for the first time, there’s a very, very good chance much of what you’ve designed isn’t quite right.

Therefore for every new product concept, feature, interaction design, bug fix and so on, start simple and prove your assumptions with user feedback.

Software like InVision, AdobeXD and Marvel, to name a few, enable designers to digitally draw the product, on which they can then superimpose navigation and some basic logic, to make the prototype feel real. However these take time to learn, and much can be achieved with pen, paper, then Keynote (or PowerPoint).

One exception I’ve found very useful here however, is InVision’s Freehand product. This software doesn’t have to be downloaded, can be shared with others, doesn’t allow you to be too precious as the digital pen mimics a thick marker, and it’s free.

Your pen should only be as fine as your solution. The bigger your assumptions, the thicker the pen.

I’m butchering a phrase I’ve heard third-hand, so I apologise to whoever coined it. It changed how I approach paper-prototyping, and has undoubtedly helped me get better at design. The principle being that early in the design process, don’t be precious over how good your design looks, and in fact try using media which mean you can’t create pixel-perfect, super sharp mockups. For me, that’s thick markers, or if I’m using software like InVision’s freehand boards, the thickest pen setting.

Sticky-tape prototypes

This is a concept I’ve developed to help me design experiments which are not meant to produce reusable assets; the things I put together to test my ideas are throw-away, won't last, but good enough for a quick experiment.

The name refers to how I'd make things as a kid, with sticky-tape, straws, pipecleaners, plastic bottles etc; i.e. a temporary solution.

Sticky-tape can solve a lot of problems, temporarily. It’s quick to try, and if it works, you can replace it with something more sustainable, which requires more time, effort and resource (that is, if you need to replace it).

This ebook began life as a chapter in Notes on my Macbook. Then several chapters in Pages, then on this Squarespace site, where it sits currently. If I need to solve more problems which Squarespace doesn’t offer, I’ll change it, but right now, it does what I need it to. I could have built a website from scratch, but what would be the point? All the problems I had, which were, I wanted a good-looking site, compatible across browsers, easy to update, cheap, with lots of integration, and not too costly. I had multiple options to choose from too.

Let's imagine you see small businesses struggling to answer queries from customers on Facebook. This the problem you’re trying to solve; the basis for you product. Your solution is to search a list of FAQs and respond with the most appropriate answer, with an invite to chat if it didn't work. Speaking to you audience, they like it - it’s worth trying.

You could test this by offering a local business with this problem, your hands-on help to offer a solution. You sign into their account and answer questions manually, using a pre-prepared answer bank, copying and pasting. After a week you've learnt an incredible amount about what needs to be in the early built solution, but also you can ask the business if they'd pay for a product that did the same, now they've seen it in action.

Even if you're technical, this is where you should start.

If you can't figure out a very simple way to test your hypothesis, how is creating a much more complex prototype going to be easier?

Fast-forward a few weeks, and you've run the same experiment several times, with different businesses, all ready to hand over cash for the product. Scaling the solution would be the next problem, which is when you’d replace this current solution, with a longer-term sustainable solution - a product you’ll build.

To quote Paul Graham once more, "do things that don't scale".

Let's take another example. Using our recurring parent childcare example, we have two audiences, now two sets of users (when they start using your product, they become users), with parents looking to book childcare, and childcarers looking to take bookings.

If you are a human, the most likely thought process you'd go through is something like: create a website with a booking and payment system, advertise it on google and wait for the money to flood in. That sentence represents several months of effort, and thousands in investment (if you're not building it yourself). What you're testing is if the website works, are the user journeys easy to follow, can people pay. All you wanted to test however, was whether you could make parents feel safe enough to pay for childcare services, and if childcarers would accept bookings through you.

So how could we do this differently? One way could be creating a Facebook group, inviting both sets of users to it, manually verify childcarers with background and certification checks, then ask parents to post jobs, and childcarers to respond. When a parent makes a booking, take payment from the parent via PayPal, wait until the childcare session is complete, and then pay the childcarer.

Now you may say that this looks too shoestring for people to trust it, that you need a website to legitimise your product. However, for the time it takes to test your product in this way, this sticky-tape prototype will teach you more in 24 hours than you could have learnt any other way. If you can't muster bookings this way, why? Ask your users. If you can, what else would make this solution better?

So often, the means we need to test something are already at our disposal.