Noupe Editorial Team March 7th, 2018

Design: These Prototyping Tips Prevent You From Losing Your Customers and Your Mind

It doesn't matter whether you call it prototyping, design draft, mockup, or proposal. It's the same topic. The customer wants to see what his digital product will look and work like as soon as possible. You're no wizard, though. What now?

Design Prototypes Always Require a Compromise. But Your Customer Doesn't Know That…

Us designers like to consider ourselves experts - especially when we're able to look back at a bunch of successful projects of the past. In comparison to our typical client, we really are experts. Under this basic assumption, it seems unnecessary to make a prototype for easy projects. The customer wouldn't agree with that. He wants to see results as fast as possible. This early on in the project, the most we can show is a mockup, a prototype, a wireframe model. Of course, we know that the mockup won't be able to satisfy the clients' needs. They don't want what we consider a prototype - no, they want to see a complete and fully functional website or app. At the same time, they expect all changes to be made immediately, and at any time, no matter how massive they may be. This is cause for conflict. Even if we don't want to cause an argument, we still know that, with the client's idea in mind, a prototype always has to be a compromise. This may strengthen the urge to forgo the wireframe entirely, or at least to devote as little time as possible. With the prototyping tools and UI kits available today, creating a draft doesn't have to take long. With some experience and the mentioned means, you should be able to get a rough draft complete with interactions in about two hours. With a calm and professional approach, you can prevent losing both your customer and your mind. This is a win-win situation in many regards. Thus, take a clinical look at the following tips, and decide what's more important to you. Being right, or keeping the customer.

Tip 1: Don't Lose Your Understanding of the Customer

I have experienced this more often than I'd like to: the designer builds himself up in front of the client, and may even be angry about the client sticking to his own idea of a prototype, even after multiple attempts to convince him. After all, the designer has the expert knowledge on his side - maybe he even studied design, which would make him a certified expert. His customer is a complete idiot! [caption id="attachment_104189" align="aligncenter" width="1024"] It's his fault! No, he's to blame! (Photo: Pixabay)[/caption] However, those that enter the ring with their existing or potential clients will start a hopeless fight. Even if the client ends up relenting, he won't be satisfied. He'll feel run over and definitely won't build a lasting client relationship.
Remember: You will never win a fight with your customer.
Thus, always approach the design process with an open mind and a lot of appreciation for the customer. He's the one that pays for the music - so he is allowed to decide what you play. If he expects Serenade No. 13, but you only know how to play the electric guitar, you might not fit together. But even that can be dealt with intelligently.

Tip 2: Don't Think of Prototyping as Unnecessary Effort

First of all, making a prototype means effort. However, it's also about quickly defining the direction of a project, and communicating basic components of the commission with the client. [caption id="attachment_104194" align="aligncenter" width="1024"] Mockup, Prototype, Wireframe - don't put too much detail to it. (Illustration: Pixabay)[/caption] Because of that, a prototype is never a waste of effort. However, there is nothing bad about keeping that part of the creative process as short as possible. Standardize your prototyping workflow. Get a building block system that lets you move the default elements of each project to quickly form a mockup. Even if you don't want to admit it. The basic components are almost always the same - after all, we're not artists, but rather craftsmen that create more or less standardized solutions with given materials. In the past, I created mockups in my Moleskine notebook - totally hipster. At one point, I stopped, since I wasn't able to tell the drafts apart anymore. Since then, I've been using Sketch on the basis of three templates, which I have created for prototyping in my clients' main branches. That Sketch ends up in InVision, where the individual screens are extracted automatically, so this doesn't result in any additional effort for me. Now, I quickly implement the interactions via hotspots - done. This minimizes the work I need to put into the mockup creation while contributing to the communication and planning with the customer.

Tip 3: Build Interactive Prototypes

It used to be conventional to create and print out a pure design draft. That print was often glued to a large piece of colorful cardboard to make an impression. The client got to see at least five versions - one of which was awful on purpose, to guide the client into a particular direction from the beginning, stimulating his decision-making. [caption id="attachment_104187" align="aligncenter" width="1024"] Rapid Prototyping in Adobe Xd. (Screenshot: Adobe)[/caption] Of course, creating an interaction-free prototype is still the easiest way, but with the prototyping tools available today, this would be near careless. In the noughties, I used Powerpoint for that purpose. Today, there are a bunch of better tools, and even standard web technologies allow for the fast creation of prototypes. If you want to work contemporarily and provide an interactive prototype, that should be more than just a slideshow. Build a prototype with hotspots in the right places, which lead to the appropriate screens when clicking them. If you don't do that, you're already setting yourself up for the next pitfall. Aside from the previously mentioned Sketch, I also like to use Adobe XD a lot. I explained why and how I'm doing that in this article. Adobe XD lets you present your prototype via Creative Cloud using your smartphone. This is really impressive, as I was able to see from the dropped jaws of some customers. Definitely, try that.

Tip 4: Make Sure The Client Understands Your Prototype

As I've mentioned before, designers and clients often have fundamentally different ideas of a prototype. The customer expects a polished finished product, which you can not provide at that point in time. Thus, before the presentation, explain what should be expected from the prototype, and what not to expect. This may seem unnecessary to you, as you are very familiar with the term. But you customer will happily put you right. It's up to you to explain which restrictions your prototype is subject to, and why that is the case. Be careful with your wording, or read tip one again.

Tip 5: Always Request Precise Feedback

When it comes to collecting feedback on your prototypes, you should avoid very general questions. Generally, when asking for feedback, you're likely to receive it, but unlikely to obtain useful information. Always ask for feedback on specific aspects, like the feel of the page navigation, or if the form X is well-placed in position Y, for example.

Tip 6: Form a Comfortable and Firm Collaboration Base

Let's be honest: I have yet to find a perfect solution for this myself. One thing I know for sure, though, is the fact that collaboration on one prototype with more than two people is guaranteed to result in a catastrophe if done via email. It only takes a few days until nobody knows what was talked about and agreed on. I've been using the cloud solution InVision, which I presented in this article, for years. While InVision provides a pretty good approach, this solution is still very far away from perfection. In any case, the tool is a much better alternative to email. In this article, my colleague Denis Potschien shows you different alternative collaboration solutions that are worth checking out.

Tip 7: Don't Make More Prototypes Than You Have to

I always try to leave it at a single draft and change it step by step. I have stopped creating multiple proposals about fifteen years ago: back then, I parted ways with a client that still wasn't satisfied after the tenth (!) functional, and utterly different design prototype. Nowadays, I create a single well-thought-out draft. I explain it thoroughly. In my first draft, I always make sure not to make any concrete design decisions. At this point in time, the look of the project is as undefined as possible. Now, I work on this mockup with the client, trying to find a consensus we're both happy with while solving the problem at hand. When taking a different approach, and throwing tons of drafts at the customer, you're suggesting that the proposal is worthless individually, while also indicating a certain level of randomness in your solution approach. In conjunction with the existing difficult collaboration, this may lead to complete chaos in no time.

Tip 8: Always Direct the Customer's Attention to the Core Aspects

This should seem familiar to all of us. The client is sitting in the meeting, criticizing the fact that the date on the mockup doesn't match the current date. It seems like it's tough to tell apart a static draft from a final product. This aspect requires explaining as well. The client needs to understand that, even with limited interaction, the prototype is still just a decoy supposed to lead the way. Thus, it doesn't help when the client criticizes the font or the weight of some orientation lines. It takes a certain amount of body control to stay calm in these situations. But what else are we experts for? (The article was initially written in the German language by our author Dieter Petereit for our sister magazine Dr. Web.)

Noupe Editorial Team

The jungle is alive: Be it a collaboration between two or more authors or an article by an author not contributing regularly. In these cases you find the Noupe Editorial Team as the ones who made it. Guest authors get their own little bio boxes below the article, so watch out for these.

Leave a Reply

Your email address will not be published. Required fields are marked *