Clients and colleagues can misunderstand the nature of a prototype. It falls to us to explain its role.
It is a rare project where I do not recommend the use of a prototype. A good prototype can be an excellent way of defining a project and testing its validity with real users.
Unfortunately, although prototypes can be invaluable for development, they can be confusing for stakeholders.
Prototypes are often so basic that stakeholders have trouble imagining what the final result will be like. It is not uncommon to hear a stakeholder exclaim "why is it black and white" or "is that going to be the final image?"
This leads many of us to refine our prototypes overtime. They start out basic when dealing with other digital professionals (such as developers). They then become a little more defined when we carry out some initial testing with users. Finally, we give them a nice coat of paint before showing them to anybody with sign-off. Unfortunately this can often backfire.
Don’t let your prototype fall into the uncanny valley
If a prototype is too refined it can fall into the uncanny valley. The uncanny valley is a term first coined to talk about depictions of people in animation, computer games or robotics. Over the years these depictions have become so advanced that they look almost human. But almost can be a problem. Something that looks almost human, but not quite, disturbs us. To our eyes it doesn't appear quite right. Something is off.
Many stakeholders react in a similar way if our prototypes become too designed. It looks like a finished website or app, but it's not. Something is not quite right and they start picking at it trying to find the problem.
Often the answer is to show them earlier prototypes. Prototypes that are not so refined. Prototypes that haven't fallen into the uncanny valley.
Of course the problem that you now face is that clients don't understand what they are looking at. But that can be overcome with a bit of education.
Explaining a prototype
The danger comes when not everybody who sees the prototype receives that education. Maybe a stakeholder shows another colleague or somebody just sends them a link in an email. Whatever the case they are not having the prototype explained and that can be disastrous.
My preferred solution to this problem is a video. Whenever somebody visits the prototype they first see a video (often as an overlay). Before they can view the prototype I have an opportunity to explain what they are about to see.
I start by making it clear that the prototype is not the final site. I often refer to it as a visual specification to define how the final site might work.
I emphasise that the aim of the prototype is to gather feedback. Feedback from stakeholders, but also real users.
I explain which user groups we have focused on and what content and functionality we have included for those audiences. Finally, I make it clear which audiences we have not addressed and what associated content we have left out.
Manage the feedback you want
Depending on the stage of the project, I also sometimes include a request for feedback. But it you decide to take this approach be careful. Never ask people for open ended feedback. If you do they will share their personal preferences. Comments like "I don't like the colour" is not helpful.
Instead ask structured questions. Questions that will help you improve the prototype. But also will help educate stakeholders about where they should focus. Questions such as:
- Does the prototype enable our target users to complete their tasks? If not, which tasks are missing?
- Does the prototype highlight our calls to actions?
- Does the layout of pages place the emphasis on the most important elements to us as an organisation and to our users?
- Is the tone of voice in copy consistent with our brand?
Your final set of questions will depend on how refined the prototype is and what feedback you need. But you get the idea. Lead stakeholders away from personal preference by asking the right questions.
Beyond your explanatory video
You want to keep your video as short as possible. But that doesn't mean you cannot provide more information for those with an interest. Many of the videos I have produced appear alongside links to a blog outlining the work we are currently doing.
It is also useful to include a timeline so stakeholders can see how far you have progressed and what you have left to do. If people can see progress they are less likely to complain about you not having launched the new site yet.
Prototypes, videos, blogs and timelines may seem luxuries that your project cannot afford. But if that project has a lot of stakeholders they are invaluable and speed up the process. By keeping stakeholders informed and engaged a project is much less likely to get derailed. That in my opinion is worth the investment.