Prototypes are the bread and butter business of an UX Designer. In the last years I worked on hundreds of prototypes ranging from hardware to software, from low fidelity to high fidelity. No matter what tools I used – hotglue and Arduino or Hololens and Unity – they all had one thing in common. They were built to communicate an idea.

But as IXD and UXD gain more grip and acknowledgement in the industry every manager is shouting for prototypes. As if they would bring salvation to their rusty processes and liberate them from thinking. So, they set prototyping as their mantra and push their employees to create “the one thing” that satisfies all their needs – concept, design, development – and will lead the way into a bright future. 

Too many times I have seen this approach, and shamefully even supported it as I was fascinated by the idea to create a solution for all their problems. And too many times I have seen it fail and end in frustration. I helped creating monsters; growing too big to move, relying on constant live support and consuming motivation and budget. And once those monsters have slowly past away into the archive folders the managers try to harvest their organs of databases, and frameworks to stuff them into the next monstrosity.

But where did it go wrong? Why did the amazing prototypes we created, which where celebrated at their introduction, so often end in frustration?

We had to find the answers.

So we analyzed every little aspect – the process, the intent, the tools, the fidelity.

The result was a compendium about prototypes. A guide for designers, project managers, developers, accountants and CEOs.

Here are the most important findings.

The value of prototypes:

A prototype is a way to communicate with others. Prototypes take the abstract elements of visual design, information architecture, interface elements, use cases, technologies and combine them. It is a step in between abstract element and the holistic and authentic experience of the real product.

It gives you the experience of behavior, change, connection and correlation before the product is build. This experience has to be leveraged for decision making.

But consider that creating a prototype takes time. This ranges from minutes to months. 


A good prototype always has one purpose. And one purpose alone.

This can be:

To validate an idea,

To present a vison,

To describe a behavior.

It is crucial to keep those aspects separated as combining them will grow your workload exponentially.

Example: Your research team has a new idea how to interact with the system. They can quickly test the placement and feedback of buttons in a simple low fi prototype.

Now your design team wants to present this in high visual fidelity with motion and transitions in a simulator to the board. As you are already putting a lot of work into it, development asks for an API to grab timings and values to transfer them into the real product.

Now imagine making a change to the interaction.