The uncanny valley of prototyping

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.

When something looks almost real it can be disconcerting. This is true with prototypes too. If it looks too much like a final website it can cause confusion.

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.

A video overlay which explains your prototype will manage expectations and improve the quality of feedback.

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.

  • Ivana McConnell

    Great post! I’ve often wondered what to do when a stakeholder receives a prototype or a design (or anything on which I hope for feedback), but has no context for it. The video is a great idea, since it’s coupled directly to the prototype itself— an e-mail or a list of targeted feedback questions often gets lots. Do you do mobile prototypes in a similar way?

    • Hmm… an overlay might be a bit tricky on mobile. I haven’t tried it to be honest. I guess it would depend on whether the ‘reviewer’ is using a mobile device or some kind of emulator. The alternative is to just showcase the prototype in video format and just send them a video file. They wouldnt be able to interact with it but it would ensure they get a good presentation.

      • Ivana McConnell

        Thanks! I think the video option could even be preferable, as it might prevent some of that uncanny valley creeping in, depending on the prototyping tool used, and its limitations. I.e., they may be worried about which aspects they can and should be able to interact with rather than where their focus should be directed. Prototyping applications can sometimes be a huge pain to set up on their devices also— it’s an interesting question, when the uncanny valley is created on different devices. Thanks for posing it! :)

  • Rasterfield

    I agree with having an introduction video, and we should tell stakeholders what they should be looking at in the prototype. This will have different scenarios depending on stakeholders to whom we show the prototype; for example, developers for the way retrieving data from the server or screen transitions, management and marketing team for copy writing/branding, or presenting own design team for overall interaction and look and feel, etc. Otherwise like you said, the feedback becomes a never ending story with personal preferences and it becomes less clear what we would like to learn from the feedback. Our R&D team shows us a part of future product, however I am unsure as to what I’m experiencing from it, whether its interaction or information architecture, or something else. Also presenting the timing of prototype should be considered within the project process.

    Mobile phone prototype: You can create a prototype in Axure, generate to HTML then upload to the server( your server or they provide server as well). You can send the URL to the stakeholder to open in their mobile browser.

  • jamesej67

    Really like this: ‘Lead stakeholders away from personal preference by asking the right questions’. It applies to any design task, and to yourself as well as other stakeholders. A great way of avoiding designing stuff some way just because you or others who happen to be influential happen to like it.

    • Thanks James. You make a good point about it focusing your own thinking too.

  • Peninah Adler

    I’m curious–why do you prefer a video to a phone call presentation, or a screenshare? Is it so the prototype can be passed around, so no one sees it without explanation? Do you just find it faster?

    Also, do you re-use the same video, or do you make new ones each time?

    • I do absolutely do a new video every time. The video has to show the prototype and so has to be unique to the project. It also needs to talk about the business objectives, user needs and success criteria all of which are specific to the project.

      As for why I prefer a video, you were right when you said it was because the prototype gets shown around. It is important that anybody who sees the prototype also sees the video.

      • Peninah Adler

        Makes sense. Thanks for the explanation.