11/22/2020, 10:50 a.m. No time right now?
Note: We have used commission links in this article and marked them with “*”. If an order is placed via these links, t3n.de receives a commission.
Call it prototyping, design draft, mockup or proposal – it doesn’t matter: it’s about the same topic. The customer wants to see how his end product will look and function as early as possible – regardless of whether it is an app, website or web app. That’s legitimate – that’s how you go about it.
We designers like to consider ourselves experts – especially when we can look back on a large number of successful projects. Compared to the typical customer, so are we, of course. Under this basic assumption, it sometimes seems superfluous to us to build a prototype for manageable projects.
Design prototypes: always a compromise
The customer almost always sees it completely differently. We designers often realize at an early stage that a mockup is basically not suitable for satisfying the customer’s wishes. They actually don’t want to see a prototype as we understand them – no, they want a complete and finished website or app that they can use to their full extent. At the same time, however, he expects that even the most fundamental change will be implemented at any time and without delay.
This is a matter of conflict. Even if we don’t aim for a dispute, we are aware that a prototype can only ever be a compromise under this basic requirement. This may increase the urge to forego the creation completely or at least to sacrifice as little working time as possible for it.
Prototyping: You should avoid these mistakes
You can start professionally at the last point. With the prototyping tools and UI kits available today, design doesn’t have to take long. With a little experience and the tools mentioned, you should have roughly designed an app and provided it with interaction in about two hours.
You should avoid the following pitfalls.
Arrogance doesn’t help
I have seen it more often than I would have liked: The designer builds himself up in front of the customer, wants to convert him and is perhaps even angry that the customer is still insisting on his own wishes despite multiple attempts to convince him. After all, he sees the specialist knowledge and thus the law on his side – maybe he even studied design and is therefore a state-certified expert.
However, if you step into the ring against your existing or potential customers, you start a hopeless fight. Because even if the customer should finally give in, they will not be satisfied. He will feel run over and will almost certainly not build lasting customer relationships.
So approach the design process openly and with great understanding for the customer. He’s the one who pays for the music – so he can also determine what is played.
Don’t see prototyping as an unnecessary expense
Of course, creating a prototype means a lot of work. However, it is also about quickly determining the direction of a project and agreeing with the customer on the basic components of the order.
A prototype is therefore never an unnecessary expense. However, there is nothing wrong with keeping the creation process as short as possible. Standardize your prototyping workflow. Prepare a building block system on the basis of which you can quickly assemble the standard elements of each project. The basic components are almost always the same – after all, we are not artists, but rather craftsmen who create more or less standardized solutions with available materials.
Prototyping in Sketch (Quelle: Bohemian)
I used to create mockups in my Moleskine notebook – totally hipster. At some point I stopped because I could no longer tell the designs apart. Since then I have been using Sketch on the basis of three templates that I created for the purpose of prototyping in the industries I mainly serve.
The sketch then ends up in Invision, where the individual screens are automatically extracted so that I don’t have to do any additional work. Now I quickly build in the interactions via hotspots – done.
In this way, on the one hand, I minimize the effort involved in creating the mockup and, on the other hand, make an important contribution to communication and planning with the customer.
Do not forego interaction
In the past, it was common practice to prepare and print out a pure design draft. In many cases, the printout was glued to large colored cardboard to make an impression. The customer got to see at least five drafts – at least one of them was terribly bad in order to steer the decision in a certain direction from the start.
Of course, it is still the simplest way to design a prototype without interaction, but with the prototyping tools available today that would be almost negligent. In the noughties I used Powerpoint for this purpose. There are a number of better tools out there today, and even standard web technologies are quick to prototype.
So if you want to work in a contemporary way and offer an interactive prototype, then it shouldn’t just be a slideshow. Builds the prototype with hotspots in the right places, which then lead to the right subsequent screens with a click. If you don’t, you are already pulling the next pitfall.
Make sure the customer understands your prototype
As already mentioned, designers and customers often have fundamentally different ideas about a prototype. The customer expects the finished, polished end product, which of course you cannot deliver at this point in time.
So make it clear in the run-up to the presentation what can be expected from the prototype – and what not. This may seem superfluous to you because you are more than familiar with the terminology. Your customer will be happy to teach you better.
Can your prototype also be used on the move? Then make that clear and show it. What are its limitations and why? Explain that in detail.
When it comes to collecting feedback on your prototypes, you should avoid generalized and overly open questions. For example, if you formulate a request for feedback in general, there is a high probability that you will get feedback, but not one that you can use.
Therefore, always ask for specific feedback on certain aspects, for example to find out how the page navigation feels or whether the form X is required at position Y.
Ensures a consistent basis for collaboration
Let me be honest: I haven’t found a perfect solution here myself. The collaboration on a prototype with more than two people can turn into disaster if it is carried out via email. It only takes a few days before nobody really knows what was discussed and decided when and how.
Invision offers a pretty good approach, but this solution is still a long way from being perfect. In any case, this tool is a much more valuable alternative to e-mail.
Don’t build more prototypes than absolutely necessary
I try to stick to a single draft and change it step by step. I said goodbye to the unspeakable practice of constantly generating new designs in 2004: At that time I parted with a customer who was still unsatisfied after the tenth (!) Functional and completely turned inside out design draft.
Today there is just one well thought out design. I work on this with the client to find consensus. Anyone who proceeds differently and always offers a bunch of drafts suggests to the customer that they are worthless.
In interaction with the already difficult collaboration, a symphony of chaos can emerge at this point in a very short time.
Always draws the customer’s attention to the key points
Who does not know it? The customer is sitting in the meeting and complains that the date in the mockup does not correspond to today’s. Apparently it is difficult to distinguish a static design from the final product.
This aspect also needs an explanation. The customer needs to understand that, despite limited interaction, the prototype is still primarily a mock-up, purely intended to provide directions. In this respect, it is not very helpful if the customer complains about the font or criticizes the strength of individual orientation lines.
It takes a certain amount of body control to remain calm in such cases. But what else are we professionals for?
(The article was last extensively revised on November 22, 2020.)