Philipp schreibt zu Themen wie VueJS, JamStack, Produktentwicklung und Teamkultur.
“We have to prototype it!”, “Let’s build it.”, “We should test it beforehand.” – At some point there comes a point at which you want to transfer your ideas from a pure paper concept into a tangible product. The sooner that moment comes, the better. A well-thought-out prototype can provoke real reactions from testers. The goal of a prototype is to clarify the feasibility of an idea on three levels:
I think the main goal of the prototype should be to make the idea tangible and perceptible. You offer the user a gift, so to speak, and watch him use it.
To be able to carry out prototyping well, it is often advisable to question your mindset. We should get away from wanting to develop the perfect solution and prefer one that is good enough. Also, the prototype should not be seen as a long-term solution, but rather as a temporary solution that can and should trigger further change loops.
Unfortunately, we all too often experience that prototypes are thought of as the perfect long-term solution, which means that all the power of the actual approach is lost.
We can imagine two virtual lines in product development. The first milestone is reached when the product contains the basic function that is to be tested. As soon as this point is reached, users should be included in the first tests. Our idea has thus been converted into a real and concrete product that is good enough for testing. We save valuable time and also get initial insights into what users understand by the offer and how they use it for themselves.
We all know how convinced you can be of your idea and how painful it becomes when it meets reality. With the right speed in the development process, you can protect yourself from this emotional low. If you test your idea as a prototype as early as possible, you accept user reactions with a high willingness to change. You will understand that your original idea passed the user by and that you will have to readjust. The longer you work on your idea in secret, the lower your will to change will become and you will tend to assume that the users are simply too incompetent to understand and use your product.
If we start prototyping with the development of ideas, we avoid this dilemma and are open to changes during the process.
As soon as it is clear that it is advantageous to test your idea and hypotheses at an early stage, the question of how exactly a prototype can look like arises. Unfortunately, there is no general answer to the question of what exactly the perfect prototype is. It is always helpful to start with the assumptions about your idea that are most critical to its success. That means, if the chosen assumption does not come true, your idea is useless or does not provide enough value for the user.
In the design area, a distinction is made between low-fidelity prototypes such as mockups or storyboards and high-fidelity types such as clickable interfaces with the most important basic features. Storyboards in particular are suitable for testing the flow of information and for identifying termination criteria for users. I use low-fidelity prototypes more in the design of products, but not in user tests.
High-fidelity prototypes such as a landing page with a real purchase (however, the selected payment method of the user is not charged) make real actions and reactions from users clear. If the customer is ready to make a purchase that they perceive to be real, there is a good chance that the idea presented will be of great benefit to the user.
When you are clear about what you want to test and what type of prototype you want to carry out the test with, you are ready for implementation.
When you start to implement a prototype, it generally helps to think about which western backdrop you want to build.
I think the metaphor with the western backdrop is quite suitable for the procedure (I got the idea from here), since this approach exactly shows how the prototype should be thought of. The main street is shown in full detail and can be experienced in real life.
As soon as one of the side streets is entered, the prototype is visible.
You should ask yourself the question: how does my main street look like for the user? Which functions should you design and which doesn’t have to be functional? If you manage to get the user to walk down the main street in your product, your real idea and not notice that it is a prototype, they will react in the same way as they would react to the final product.
With these insights, you can successfully iterate your product and create real added value for your users.