How to prototype anything in one day

Andrej Berlin
Oct 25, 2017 · 6 min read

If you think that building a prototype to test your idea is difficult, requires a lot of resources or a skilled team, you might be right. But building prototypes for nearly anything for the last two years I found a few ways to make the right compromises, even if you don’t have a high end production studio.

Image for post
Image for post
This is me (right).

I work building prototypes in weekly Design Sprints, which means that almost every week for the last two years I thought “trying to prototype this in one day is impossible”. But I never really said it out loud and I love pushing my boundaries, so by the end of the week we always had a high-fidelity prototype and got all the test results we needed.

I want to tell you a little bit of what I think are some essentials in prototyping solutions and prioritising your effort to get it done in one day. To make it easier to understand, I’ve split them into three “principles”:

Principle #1: The fidelity of your prototype follows the purpose of the test.

I often get asked how real a prototype has to look to get the right feedback.

If you need to create a digital product with audio, video, etc. and for instance need to figure out if it appeals to Millennials, you might need a fancy prototype which looks and acts exactly like the real, finished product.

So to test the look and feel of the product, you might have to prioritise all the levels of playfulness and prettiness you are going for, while deprioritising UX or sometimes even content. This is a rare case for us, but when it happens we code our prototypes in FramerJS. Doing this requires a lot of effort but have full control of every element and comes really close to designing the finished product.

Image for post
Image for post
(I did not make this, found it on the framer.js website, but we worked on similar projects)

If, on the other hand, you are testing a purely psychological concept (which could be the interaction with content, building a habit, estimating quality of a product, etc.) it might be enough to stick to low fidelity.

When we worked on a chatbot concept, which was supposed to help people go to bed in time and wake up to a nice morning routine we literally only used Telegram and WhatsApp.

People would get pre-written, slightly robotic sounding messages and had the chance to react to them (the react-feature was only a hypothesis but later built into the product). Only after we finished the chatbot prototype, we moved on to improve the UX with Axure and later focused on the design.

Image for post
Image for post
(the first frame was supposed to say Telegram, not Whatsapp)

The compromise here is obviously the visual fidelity. It’s a chatbot, so why bother looking fancy?

Principle #2: Your prototypes need to appear real to your testers.

When you are running a test you want to simulate an environment as close to future reality as possible. You are basically pretending that what people have in their hands is not a prototype but actually real. Then, and only then you will get an emotional reaction.

Sometimes, that means testing technology which is not available yet or difficult to obtain in a short amount of time.
In the example below we needed to test how convenient wireless charging will be for phone users and how to make it a viable business (e.g. charging in a restaurant).

We could have bought an actual wireless charging dongle, or asked people to just imagine this technology exists, but we decided to fake it, because it was cheaper and faster. Take an Android with an NFC reader, and show a charging-screen when it contacts an NFC tag. This made the entire use process self-explanatory and we could focus on how people would deal with it.

Image for post
Image for post

This prototype was done with a mix of MarvelApp, InVision and the app Trigger. But, as exciting as it is, I don’t recommend getting too attached to fun high-tech - your prototype is still just a prototype. Leverage your resources with the effectiveness in creating a realistic experience.

Principle #3: You can prototype anything, the tools are there.

Maybe you’ve noticed that in the examples above I always used different prototyping software. So another top question I get asked a lot is which prototyping tool I use the most?

Do you need a 360° Video playing inside a phone app? Use Marvelapp.

Do you need to play videos and animate transitions? Use Flinto.

Do you want to customise and hard code everything? Use Framer.

Every tool is different and has its advantages and disadvantages and before jumping onto prototyping you always need to check what is important to test and what’s less important and choose your tool accordingly. This often means that you need to learn the software in less than a day and it can be a lot of hard work. But that’s life, if you want it the easy way go prototype sandwiches at Subway.

But obviously, prototyping is not limited to apps. When VR stuff first came out we had to prototype a VR experience to impress stakeholders of a large company, without any prior knowledge or experience. I used Unity to hack together a scene (super simple interface) and placed 360 videos (ripped from youtube) inside, then built a simple box and used the Google Cardboard as the headset. Done.

Image for post
Image for post
All possible in one day.
Image for post
Image for post
Andrej is my name.

When prototyping intangible products, services or processes, there are many ways to get people into believing that they are testing a real product. You might end up creating almost like theatre-experience for one person, guiding them through a process which you imagine building in the future.

For an aviation company which tried to improve their way of supporting children in traveling without their parents, we used the actual airport to create “checkpoints” with actors. We had parents and flight attendants simulate the scenario to see how kids would find their way through and behave.

Physical products are also not a problem. 3D printing exists and most of the time you don’t even need it. When we prototyped a snack bar to test its desirability we put a couple of our self-made fakes among 5 tons of real ones.

Image for post
Image for post
Yes. Most of them have been eaten right after the test.

You can even prototype marketing campaigns and videos. Remember the chat assistant from above? In order to find out how appealing the concept is, we made an ad for it using only stock footage.

Image for post
Image for post
You can still see the watermarks on some of the shots

So all of this is possible in only one day. If you know exactly what you need to test and exactly what you need to prototype, there is no way a prototype can fail.

Now go and prototype stuff!

By the way, if you are working with remote teams and are interested in how to run Sprints remotely, I wrote a little article how I faced the challenges of remote meetings:

If you have any comments or questions, leave them below or send me a message. Also follow @kischiman on Instagram, I sometimes post stories with my work. And follow @ajsmartdesign to see more design-y stuff!

Deep Work Studio

Deep Work Studio — Releasing User-Focused Blockchain…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store