Why you’re thinking about prototyping the wrong way
Let me ask you a question.
If you were making a website, would you choose a framework or template before knowing what the website was for?
My guess is, you would never design a site or an app without understanding the goals first. You would base the functionality on what the users were trying to achieve.
Now imagine you have an idea for a new concierge app, and you want to know whether people would use it. What would you do?
If someone asked you if you knew how to “prototype” what would you say? “Yep, I know how to use Sketch, Invision, and Axure”
In digital design, the conversation about prototyping centers around tools for testing screens and UI. This is a problem for 2 reasons: First, there are often upstream assumptions that need to be tested such as, “will people pay for this product”. And second, not all products and services can be tested with screens.
Prototyping isn’t just a way to test UI or user flow concepts, but simply a method to test user behavior. You can use prototyping to validate problem-solution fit, pricing, or any other part of your business model.
Experiments aren’t one-size-fits-all. Neither are prototypes. It’s as important to understand what you are trying to learn before designing an experiment as it is to understand a problem before designing a solution. Instead of jumping straight into Sketch or Invision, let’s take a step back.

Back to basics — What do you mean by “prototype” anyway?
A prototype is an early proof of concept that we use to learn. A prototype can be used to gauge product market fit, test usability, or feasibility. It is related to the idea of the MVP, or minimum viable product. The MVP that Eric Ries describes in Lean Startup, refers to the simplest artifact needed to test product hypotheses. The term MVP, however, is now often used to refer to a product that has been implemented and is ready for a general release, or a “minimum saleable product”. For that reason, I prefer to use the word prototype.


At it’s most essential, a prototype is a tool to test hypothesis early, to reduce business risk. Don’t want to spend time and money building a product that doesn’t make sense, and people don’t want? Try making a prototype. When creating a prototype, you want to re-create the real situation you are testing, whether a buying situation or usage situation, as closely as possible to get the most accurate results. The name of the game is not “flashy demos”, it’s reducing business risk by eliminating as much uncertainty as humanly possible.
Prototyping methods flow from what you are trying to learn
As will any research questions, prototyping methods starts with hypotheses. ( If you don’t know where to start, fill out a business model canvas. Anything on there that hasn’t been tested is a hypothesis).
For example, say I have a hypothesis that “small cafe owners will fill out a 5 page form for the chance to get a loan, as it is still much easier than the bank’s process.” Since I want to test behavior, a prototype makes sense.
To test this, I could create a preliminary version of the paperwork. By using a landing page to market my loan, I could ask people to apply to be on the waiting list and prompt them to complete the application paperwork. I could measure the difference between people who click the link to apply and those who complete the process. If using paper forms, I could print them out and give them to potential customers, and see whether they would fill it out. At the same time, I could ask questions to help me understand whether they are in my target market. This is a version of a test sale that tests a specific hypothesis.
Another example — let’s say I wanted to make a new service that acts as a personal concierge for users. Maybe I want to eventually use machine learning to automate answers to user’s request. My hypothesis is that people will be willing to pay a certain amount for a concierge service through text messages. Maybe my first prototype is a signup page to gauge interest. Once I have a few users, I can have them text message this super awesome concierge bot, which is really me, at my phone number manually replying to them. Not only would I start to learn what kind of requests early adopters of this service would make, I would also see whether these uses were willing to pay me for the service. I would do this by simply responding to their request with a price, and see whether they wanted to go forward with the service. Quickly I would be able to figure out whether someone is willing to pay money for this product.
A prototype can be made of paper, code, or a manual version of your product. The point is to test your ideas with the least amount of investment necessary. It can be helpful to brainstorm multiple ways of testing a hypothesis, and then choose the one that will be the most accurate with the least effort. You can even repurpose existing service processes or code, but layer on different manual processes and/or product positioning to quickly test different offerings at small scale. Focus on what you need to learn, not the tools you use or making something flashy and cool, and you might be surprised by how much you can discover.
Do you have examples of creative ways you’ve prototyped and tested new products? Please share! I’d love to learn from you.

