The steps that take you from idea to product are numerous, and among them, the prototype is particularly fashionable, for testing and validating concepts and ideas prior to development. But what about a Lean and Agile environment, where design and development happen at the same time, through short iterative cycles? So is the prototype stage still relevant?

What is a prototype?

In this article, the prototype refers to Simulation of an application : an interactive visual representation that emulates the behavior and user journey envisaged for the final application. It is this interactive side that differentiates it from the model - the graphic representation of a page - or from the wireframe - the layout diagram of the elements of a page - which are static elements.

Do I need to prototype to test?

What are the advantages of the prototype as a test medium?

The prototype is used a lot as validation and testing tool ideas and concepts: functionality, ergonomics of a page, fluidity of a user journey... It has the advantage of being relatively quick and inexpensive to create, and can therefore easily be taken up and modified as the tests are carried out, in order to reach an ideal product vision.

Do I have to prototype when developing an MVP?

Lean promotes the development of a Minimum Viable Product, which is the simplest version of your product that you can put in the hands of your users. The aim is to provide a solution to your users' problems as quickly as possible, to test it directly with them, and to iterate more quickly based on their feedback. Your team therefore needs to move quickly, both in design and in development. However, keeping a prototype up to date will require time and energy that you could have invested elsewhere. The prototype then appears as an intermediate stage that slows down the development of your MVP. without having a direct impact on your users.

Moreover, since the prototype is above all a simulation, it will never be a reliable reflection of reality. Testing on a prototype means restricting the user to the perfect path that you have imagined, and who can ignore a lot of parameters: unexpected use cases, data loading, error management... The conclusions you draw will therefore never be as complete and relevant as if you had done the test with your MVP.

But what if I want to develop a very expensive feature?

While it is true that testing and iterating on an MVP is a more pragmatic solution, there is a case where a prototype can really help you: when a feature is particularly complex and expensive to develop, and of which you are not not sure what value it brings to your users. The prototype then helps you confirm or invalidate your hypotheses, without having to invest too much time or resources on them.

But be careful: not every prototype will help you reach this goal! Prefer a low-fidelity prototype, that is to say, a prototype that does not seek to come close to the final rendering of the application (you can see an example hither). This has several advantages: it is faster to do and modify, and it allows you to stay focused on the core of your functionality - positioning in the application, layout, itinerary... - by avoiding too much emphasis on form, which could distract your interlocutors.

Can I use a prototype to communicate?

The advantages of the prototype as a communication medium

The prototype is often used to transmit your vision to your development team, or to promote your future product to various stakeholders (managers, sales teams or others).

This is a useful approach when the design and development phases are separate, and when communication between teams is ad hoc, because the visual and interactive side of the prototype helps you communicate product specifications effectively.

Prefer collaborating to prototyping

In Lean UX, the focus is on collaboration. Developers are included in the design process, just like designers, just like any other stakeholder with decision-making power or with the necessary business knowledge. Everyone is thus aligned with the same vision of the product at all stages of development.. Designers can then focus on creating the journey and models rather than updating a prototype, and they are available to developers in case of doubt about the behavior of a feature to be developed. Development is only accelerated, and features are in the hands of your users sooner.

What if I want to convince investors?

One thing is certain: you will never be as convincing to an investor as if you have an initial version of your product online. On the one hand, because if you already have a few users, you have just proved that you have worked, and on the other hand, because you can give a real demonstration, which will allow your investors to project themselves much more easily into a concrete use case. Hence the importance of getting to the point very quickly with an MVP.

Obviously, it is not always possible to finance the development of an MVP from the start, just as it happens to have to raise funds when the development is still in its early stages.

At this moment a high fidelity prototype - that is to say a prototype that is very close to the real rendering, both in graphic and interactive terms (example hither) - could help you communicate the vision of your product and better convince investors.

Here the trap would be to want to spend a lot of time to create a prototype that includes additional functionalities that you are considering over the longer term. You may then drown your interlocutors in details and make them lose sight of the essence of your concept - not to mention the time required to produce such a high-fidelity prototype. To get to the point quickly and to the point, stay close to what you are going to offer in your MVP.

As you will have understood, the prototype is not an essential tool in Lean and Agile environment, where we prefer to have an immediate impact on users by developing an MVP, and by eliminating intermediate steps as much as possible. However, there are cases where the prototype is interesting, either because you are hesitant about an extremely expensive feature, or because you need to meet investors very quickly. So make sure you don't spend too much time on your prototype, staying close to an MVP vision. After all, the aim is to have a useful application, and not a pretty prototype!