Prototyping can be an important part of any development cycle. Project managers often rely on feedback from prototypes in order to validate concepts before writing up user stories.
If you’re developing a prototype that you plan to show the client, you probably need feedback from them about how that prototype is behaving. You certainly don’t want to create any unrealistic expectations about the state of development based on the state of the prototype.
Where the Confusion Starts
Tell me if you’ve been in this situation before: you’ve been working with the designers to mock up a prototype of the user interface for the web or mobile application you’ve been asked to build, and as soon as you present it to the clients, they start asking how close it is to being done. After all, the prototype looks great and it’s fully functional, so it can’t be that long before the product is ready, right?
In the mind of the client, it make sense. They’re not experts on development, they just want something done. The reason they hired you was because you understand all the stuff that goes on behind the user interface. As far as the client is concerned, that user interface is the actual product. How can they be expected to know that the prototype you’re presenting doesn’t have all the security features and performance optimizations necessary to make the product complete, or how much additional work that’s going to take?
There are a few things you can do to help make it clear to the customer when showing them the prototype that that’s exactly what it is; a prototype. A lot of it comes down to managing expectations effectively, rather than trying to explain the differences. You don’t want to sound as if you’re making excuses. But if you haven’t communicated how different a prototype is from the finished product, you can’t expect the customer to understand.
Five Useful Tips, Plus a Bonus Anti-Pattern
So here are five tips you might want to keep in mind when you’re about to show a prototype to a client:
1. Hold off on the visual design
One of the reasons your clients may be confused by prototypes is that they don’t understand the difference between a prototype and a finished product. All they see is the surface, and that’s going to distract them from being able to provide you with the feedback you need. The closer your prototype looks to the finished product, the more likely they are to focus on the alignment of the borders and the color of the shadows than on the fundamental behavior. To avoid that, keep the artwork as basic looking as possible. As long as the prototype doesn’t have clean and refined visual design components, there’s no way the client can confuse it with the finished product. Using rough, sketchy styles for the fonts and iconography will help you keep the focus of the prototype review on the way to protect behaves, rather than on the color of the submit button.
2. Present a paper mockup
It’s easy to forget these days how much you can get accomplished with just paper and pens. By representing your product or service using index cards or sheets of paper, indicating on each piece what actions the user can take and what happens next, you can present an interactive demonstration without any code at all. You’ll also avoid wasting any engineering time on mocking up prototype code. The important thing is to show the client what’s in development, and get their feedback in a way that lets them participate without any confusion about the state of the product itself. (Unless of course you promised them a stack of paper as the final product, in which case all bets are off.)
3. Go with a slideshow presentation
We’re all fond of our slideshows for giving presentations, but the power of these tools also lets you go pretty far toward prototyping the behavior of many basic web and mobile products. Depending on your slideshow skills and what you’re developing, you may be able to do everything the final product needs to do visually using just slides, media, and transitions. And it will be easier to communicate the idea that these are just slides and transitions, rather than actual working code.
4. Use an interactive prototyping tool
If your prototype is more complicated than something you can put together using slideshow tools, there are visual interactive prototyping tools such as InVision, Adobe Comp, or Origami. There are plenty of them out there, and most are pretty easy to learn. These tools give you access all of the interactive power of mobile devices or web browsers, and allow you to create interactive walk-throughs that are very clearly not finish products because of the flat or simple nature of their visual design. Some of these services also let you give clients remote access to play with the demonstrations directly, although it’s important not to give them access to make changes. Keep the information pipeline under your control, and don’t let random input alter the client’s expectations or your engineering team may suffer the consequences.
5. Use ridiculous colors and patterns
Most prototyping tools use simple grays blacks and whites, avoiding any color at all, to make their output look different from a finished product. However there are clients who like that look. What’s considered ridiculous will vary from one client to another. Figure out what aesthetic your client prefers, and use colors that violate those standards. For web component prototyping, I’ve been known to create a CSS class named “.fpo” (a reference to “for-placement-only” graphics used in print publication). I add this class to any element on a prototype webpage that is clearly not complete, so the client won’t have any confusion. For example, once I created a .fpo class that added garish pink and purple diagonal stripes to any element that was on the page just for placement purposes. The client’s website aesthetic used a lot of soft shadows, pastel colors, and muted grays. There was no confusion.
Bonus anti-pattern: Don’t use silly, embarrassing, or copyrighted imagery and text
While I do recommend using inappropriate colors that stand out, I don’t recommend going much further than that. It can be dangerous to include prototype text and graphics that may be amusing to your developers, but may get the client into trouble if they’re missed in the handoff and end up somehow appearing in the final products. You don’t want Beyoncé’s lawyers calling you up because you forgot to remove her likeness from one of the screens of your app. It’s amazing how easy it is for temporary elements in the prototype to become part of the production release. Consider yourself warned.
The Struggle Never Ends
No matter how careful you’ve been to set reasonable and realistic expectations during initial negotiations, the client is always going to try to push for faster delivery. After all, they can’t start making the money that they need to pay you until they have the products that you’re building for them.
Keep control of the situation by holding off on the visual design. Use paper mockups when you can, or use slideshows or prototyping tools when you need something more sophisticated. Don’t forget to distinguish the prototype with colors and patterns that will stand out from the client’s visual design aesthetic. But be careful not to use elements that could get the client into trouble if they ended up in the final product because somebody missed them.
Be realistic and reasonable, and never let them think that the prototype that they’re evaluating is anything more than a feedback mechanism.