I'm sure many of us have asked ourselves the question: Is a prototype really necessary? We have been planning long enough, why should we now create a prototype that not only eats up time but also money?

A prototype describes a model, which is the first draft of a future product. With this model, workflows, the effect or the perception can be tested without already having the finished product. After such a test, the product is improved until it meets all requirements. If this is the case, the product is brought to the market.

To better understand the process of how a prototype is created, let's look at an example:

Luigi is the proud owner of a pizzeria. Due to the Covid 19 pandemic and the resulting lockdowns, he has lost some revenue and has been thinking about how to recoup it. His son had an idea: Luigi should not only take call orders, but also take online orders. But since Luigi doesn't have his own app and can't program either, he approaches us (The UX designers he trusts).

After conducting some interviews with potential users and finding out what users need to achieve their goal (ordering pizza to get full), we arrive at the point where we can start with a first draft of Luigi's pizza app: the low-fidelity prototype (Lo-Fi for short).

Low-fidelity prototype

A low-fidelity prototype is a prototype which is less concerned with design and more focused on showing the functionality of an interactive system (e.g. an app). Mostly, low-fidelity prototypes show a rough overview of the layout. Here, images are usually shown with a placeholder (e.g., a rectangle with an "X" in the middle) and text is shown with dummy text or with lines. A major advantage of such prototypes is that they are quick to create and inexpensive. Low fidelity prototypes can also be roughly hand drawn on a sheet of paper. These can also be quickly tested by colleagues/friends/customers and updated within moments. A single page of a low fidelity prototype is called a wireframe.

Wireframe

The first drafts of the layout and features have been made. However, Luigi has some suggestions for changes. He wants to have his functions divided differently and a different arrangement of the images. Since the low fidelity prototype is so simple, these changes can be implemented within 5 minutes. The first concept is ready and the next step will be to build a more detailed prototype, the high-fidelity prototype.

High-Fidelity-Prototype

High-fidelity prototypes usually show a fairly detailed representation of a future product (e.g. a website). Here, the design plays an important role in showing colleagues, customers or other stakeholders exactly how the future product should look. The advantage here is that without programming experience, interactions can be built in using a prototyping tool (e.g. Figma) and thus the functions of the user interfaces (e.g. a button that says "order now") can be presented to others. It is also a better way to communicate ideas and what needs to be implemented to developers.

The high-fidelity prototype has now been created and presented to Luigi. He likes it, but is not yet sure whether his new app will be well received by customers and whether the app is user-friendly. The prototype therefore still needs to be evaluated.

A (usability) evaluation is a test in which products or prototypes of future products are examined for user-friendliness and usability. Errors found during such a test are subsequently corrected or improved.

The high-fidelity prototype is tested and it turns out that the most important thing was forgotten: the payment option for the customer. This bug is fixed by quickly and easily creating a new page in the (Hi-Fi) prototype and adding the missing feature. No developers are needed for this step, as prototyping programs are intuitive and simple. After fixing any bugs that seem relevant, the app is handed over to the developers and programmed.

Luigi is very happy with his new app and has even gained some new customers.

To answer the question if a prototype is always necessary: yes it is.

Prototypes help test and improve products. Without them, a new product would have to be built or programmed for every new attempt at a functioning product, which would not only eat up much more time in the long run, but also much more money.