We all understand that constructing a new building always starts with a scaled-down model, allowing the architect to ensure the integrity of the ensemble. Similarly, when designing a space shuttle, a prototype is created first to conduct necessary research and calculations. However, in the development of technological products, the prototyping stage is often deliberately skipped or simply ignored. This approach can lead to increased development costs or even the release of a product that does not meet user needs. So, let's methodically examine what a prototype is in product development, why and when it's necessary, what principles should be followed to create a quality prototype, and which tools can be used to help us with this.

First, let's define it. A prototype is a simple experimental model of a proposed solution, used for testing ideas, design assumptions, and ways of using the product quickly and inexpensively. It allows for necessary refinements and changes in the product's development direction. In other words, a prototype enables you to:

• Test an idea and/or hypothesis;
• Check how a user will use the product to solve their problem and identify any obstacles they may encounter;
• Gather feedback;
• Reduce the risks of launching a product/feature.

What a prototype IS NOT:

• A website layout or scattered wireframes. Previously, a prototype was understood as a stage of development before the design drawing, i.e., the UX and interface work. Now, a prototype is considered to be a dynamic model of the product that simulates one of the scenarios of its use.
• The final design of your product. A prototype does not necessarily have to be in your style or follow the latest online fashion trends. If it accomplishes its task—testing a hypothesis—it doesn't matter what it looks like. You will still need to completely redo it before proceeding with product development.

There are two main types of prototypes for technological products:

• Clickable prototype. Such a prototype can be indistinguishable from the real product to an average user, as it fully simulates online behavior, with the only difference being that the user is significantly limited in the scenarios of its use.
• Paper prototype. This could indeed be on sand or even made from Lego bricks. The essence of this type is to simulate the product with handy means offline.

The choice of prototype depends solely on the hypothesis you are testing.

Okay, a prototype is a model we build from available resources (offline or online) to test an idea. What basic goals are we pursuing with this?

These can be divided into four categories:
1. Exploration. The prototype allows us to inexpensively research user problems and seek solutions.

2. Understanding. It helps us grasp the dynamics of the problem and pinpoint what exactly makes your product work or, on the contrary, stops it.

3. Engagement. It enables quick and cost-effective engagement of both users and stakeholders in testing the product.

4. Inspiration. The prototype allows for selling a new idea even before its implementation.

One of the best ways to identify the strengths and weaknesses of your future product is to start experimenting with a potential solution. Prototyping gives your ideas a tangible form, allowing you and your team to see and discuss all the pros and cons, hear feedback from users, and showcase your uniqueness to potential investors.

Suppose we've convinced you that a prototype is cool and you really need one. But when should you start thinking about it?

In the classic design thinking concept, the following sequence of actions is assumed:

• Problem Definition. At this stage, you need to empathize with the user and identify their pain point, around which the product hypothesis will be built.
• Research. Now, it's time to give context to this problem, gather as much relevant information about the user and their behavior patterns as possible.
• Idea Generation. Having immersed in the context, it's time to generate ideas and form product hypotheses, from which you need to select one.
• Prototyping. And only after you have a consciously formulated hypothesis, you can start prototyping the product based on it.
• Testing. Finally, with the prototype ready, you need to return to the users and test your idea. Otherwise, what was all this for?

So, you should start creating a prototype when you are already immersed in the user's context, understand their pains and problems, and have a clear product hypothesis to solve these issues. In other words, this is the moment when you are ready to assemble a product development team and create the coolest revolutionary product :) It's precisely at this moment that it's best to pause, take a breath, and assemble a prototype to test your ideas.

We've covered the what, why, and when. The main question remains: how do you make a quality prototype?

For that, keep in mind a few key principles:
- Reflecting the product's use case(s). The prototype should enable testing how a user would approach solving a particular task and what obstacles they might encounter along the way. When testing the prototype, you should hand it to the user, state the task, and step aside. If stepping aside is not possible and you constantly need to answer questions and assist, it might be time to revisit and rework the use case.

- The prototype must always be interactive. This logically follows from the first principle: you cannot encapsulate a scenario in a static image. A static image can only tell you how much this person likes the look of your prototype visually. Here we remember that the prototype does not have to share anything in common with the final design, making such an assessment utterly useless.

- The prototype is based on a hypothesis. You'll only gain value if you know what exactly you want to test. Formulate a hypothesis so that it can be clearly answered with a "yes" or "no". Then, outline how the prototype will provide an answer to this question.

- Test, don’t validate. Humans unconsciously seek confirmation for their ideas, so it's important to remind yourself that you need an objective evaluation. It makes no sense to push the user towards a solution that suits you. You could spend a lot of time and money on product development, launch it, and find that users do not convert into buyers. Avoid this pitfall and be prepared for any outcome.

- Minimum assumptions. Try to test everything, even if you're sure you know your user.

You can go through this list as a checklist after your prototype is ready, asking yourself: is this principle reflected? If you can check off all the items, you can confidently move to the next stage and test the prototype with users, investors, and stakeholders.

Great, things seem clearer now. But you're faced with the blank page problem: it's known what to do, but how to start?
There are many tools available for creating clickable prototypes.

Here are some of the most popular ones:

• inVision, Marvel, Flinto – these tools allow you to link different page layouts into a dynamic prototype, indicating which area of one page to display another upon a click.
• Prott, POP – these tools don't even require layouts from you. Just draw a sketch with a pencil on paper, take a photo, and link them in the app to form a user scenario.
• Proto.io, Framer, Origami, Form – more complex tools that allow you to animate individual objects (layers) and make more complex and interesting transitions. However, they still fundamentally rely on page layouts.
• Webflow, Figma – these tools are website builders that can be used to create not just a prototype but also the first version of a product. However, they are also well-suited for prototyping, especially when you need more than transitions between static screens.

Let's recap:

What: A prototype is the simplest model of your future product (or a specific part of it), based on a hypothesis and a user scenario to test it.

Why: To learn and better understand the user and their pain points, engage users and stakeholders in product testing at an early stage, and sometimes even attract investments and inspire people with your idea.

When: When there is an understanding of the user and their context and a clearly formulated product hypothesis, i.e., exactly when you feel like assembling a team and starting development.

How: By choosing a tool suitable for your situation or turning to those who will do it for you (for example, contact us at ineedmvp@mvplab.org)

We hope you found this interesting and useful!