How to prototype anything in one day
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.
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.
The answer is a question — what do you need to test?
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.
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.
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.
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?
The answer is again a question — what do you need to prototype?
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.
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.
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.
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:
https://medium.com/@kischiman/running-a-design-sprint-remotely-across-the-planet-301afcef9c3d
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!
