Category: Innovation Day

“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:

• Is the idea technologically feasible?
• Is it economically viable?
• Does the idea create any real benefit?

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.

Save time and gain insights faster

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.

Avoid the risk of falling in love with your idea

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.

Types of prototypes

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.

Build your western setting

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.

A good challenge can have a positive influence on the start and progress of an innovation project. In the same way, a challenge that is too general or too openly formulated can also influence the project and procedure. To find the right challenge, you should take your time and pay attention to the correct formulation of the question. In this post, we introduce the Why-How-Laddering method.

What is needed:

• A moderator
• Flipchart marker or whiteboard pen
• A large sheet of paper (A1 or even better A0) or a whiteboard

In Why-How-Laddering, the question of the challenge should be adapted. Questions are always asked upwards with “Why …” and downwards with “How …”. Like climbing up or down in the laddering like on a ladder.

For example, we received the question “How do I become a pop star” for revision. The challenge is an example of a rather unsuitable initial question for a design thinking project. She does not name a specific problem and the target group “I” is very limited.

To revise the question, write it in the middle and then start the process. For example with the question: “Why do I want to become a pop star?”. Answers such as fame, recognition, or attention seem obvious.

To be able to derive a new question from these, it makes sense to include these new terms in the laddering. For example, the question can now be: “How do I get fame?”. On this basis, new fields open up that were not considered by the initial question.

Now the clear solution no longer seems so simple. A reformulation of the challenge could be, for example, “What do I have to do to acquire an extraordinary talent?”. So the very explicit solution has already been opened up a bit. The laddering can be expanded as required.

The method should be carried out until the questions are naturally saturated. Then a new question can be searched for.

What does it take to have a great challenge?

To be able to successfully process a design challenge, it is important from our point of view that three essential basic requirements are met.

• Does the Design Challenge identify a clear problem? Caution: Symptoms or possible solutions are not the problems in and of themselves: A problem that is too narrowly defined does not offer enough leeway because a possible solution may already be included. On the other hand, a concept that is too broad offers little traction and makes concrete solutions difficult.
• Has the problem been described from the user’s point of view? Such a change of perspective usually helps enormously in the development and validation of meaningful solutions.
• Is the situation in which the problem is noticeable to the user clearly described? A good definition of the situation gives important clues as to what the team should experience during the understanding phase through observation and interviews.

At the start of an innovation project or design thinking process, it makes sense to critically deal with the given question or challenge and to reformulate it if necessary. Why-how-laddering can be a good way to shift the level and focus of the initial question.

In product development, in particular, numerous ideas and improvements arise during the development process that should be carefully considered and prioritized. Not infrequently, if the ideas are not classified, a blurred picture of the final product arises, which incorrectly ties up important development resources. In this text, we show how a simple but very effective classification of the projects can be achieved with the help of the Impact-Effort-Matrix.

What is needed:

• Rectangular post-its, we like yellow
• Sharpies (for insiders the term for suitable pens for writing on post-its) or, to put it simply, thick pens for writing
• A large sheet of paper (A1 or even better A0) or a whiteboard
• Create the matrix and prepare items

The Impact Effort Matrix is exciting and, at the same time, a simple instrument for prioritizing tasks, development tickets, or milestones during product development. As the name suggests, it is a 2 by 2 matrix with the axes of effort and influence. To be able to start, you should draw the basic grid of the matrix on a large sheet of paper or whiteboard and indicate the quarter division by central axes.

In the meantime, all items to be prioritized should be written on individual post-its so that the solution ideas can then be evaluated individually.

Evaluate the items in a team

Ideally, the features are arranged in a joint team within this matrix. This should be discussed but within the framework of the given categories. A team member should take an item and first move it on the horizontal axis until the team has unanimously decided on the effort. Now it’s the turn of the vertical axis and thus the influence of the respective item. Here, too, the team member moves the map until the correct position for the item is reached. This whole procedure is carried out with all available cards.

We look for high impact and little effort

As soon as all items are arranged in the matrix, a certain picture emerges within the matrix. It is obvious and expedient to take a closer look at the area of ​​high influence, low effort relatively quickly. All items that are located here should be given a high priority and quickly implemented or validated.

Finally, all solution ideas in the area of ​​high influence, the low effort can be marked with a point so that they can be quickly recognized when used later.

The impact-effort matrix is ​​a good method to quickly and easily derive a prioritization of the upcoming product features. The approach helps especially in a team to build a common understanding of the coming development steps.