Prototyping is a crucial tool in the development of websites and other digital services. In this post I explore its potential and share tips and techniques for getting the most from it.
Although popular, prototyping is often misunderstood. People fail to get the full value from it because they are approaching it in the wrong way.
The result is that when deadlines are pressing, and budgets are tight, prototyping is often one of the first things to be cut. Instead, organisations leap into production or fall back on lengthy specification documents in the hopes of shortcutting the process. In the end, they achieve precisely the opposite.
In this comprehensive introduction to prototyping, I share over 22 years of experience building prototypes. I will show you that prototypes have a lot more potential than you might initially suspect.
Together we will explore:
- What is a prototype?
- Why is prototyping important?
- Questions to ask when prototyping.
- How to make a prototype that inspires.
- Who should be involved in prototyping.
- How to prototype collaboratively.
- The best tools for prototyping.
- How to present a prototype to others.
- Taking prototyping further.
If that sounds good, then keep reading!
What Is a Prototype?
Most of us have a vague idea of what we mean when we talk about a prototype. But how does that relate to a website or mobile app?
To my mind a prototype is a proof of concept that can be used to validate an idea for a user interface. That might be as simple as a hand drawn sketch or as elaborate as an interactive, fully designed experience.
In between these two extremes are a variety of different approaches. Approaches that each have their pros and cons serving different purposes.
For example, you could argue that a design mockup of the user interface is a type of prototype. It is highly designed, but lacks any interactivity. That means it is good for validating visuals, but poor for testing usability.
Then there are wireframes. Wireframes are typically lower quality visually and so quicker to produce. They are good for testing visual hierarchy with users and whether they know what to do on the page. But they offer little in terms of testing aesthetics.
That said, wireframes can vary in design detail and could even be linked together allowing limited navigation.
It is possible to build HTML prototypes too. These are good for testing usability, visual hierarchy and navigation. They also allow testing across devices. The downside is that they can be more time consuming to create especially as richer design or interactivity are added.
Finally, there are prototypes that mimic the user interface as much as possible. The aim of these prototypes is to provide as accurate a sense of the final experience for testing, without having to write the underlying code and functionality. This type of prototyping is the most time consuming of all, but gives the most accurate picture of what is being built.
You maybe thinking that all of this sounds very time consuming and hard to justify. That is not an unusual response. But the benefits of prototyping are huge.
Why Is Prototyping Important?
I don’t see prototyping as a tool that can just help design better interfaces. I believe that like so many parts of design thinking, it can have benefits to all areas of the business.
Prototypes Create a Compelling Vision
Many ideas fail, not because they are flawed, but because people didn’t ‘get it’. It can be hard to imagine new products, services or features. That is where traditional specification documents and business plans fail. They do not excite people about the potential. They do not show them what could be.
When staff at Disney wanted to persuade the executive to invest $1 billion in renovating their parks to support a better user experience, they turned to prototyping. Instead of writing a document that only appealed to the executive on a rational level, they built a prototype so management could feel what a better experience would be.
When so many companies now differentiate on quality and service, how something feels is incredibly important. A prototype enables you to experience that and so excites stakeholders about what is possible.
Prototypes are a great way of unifying people around a shared vision, but this has another related benefit.
Prototypes Reduces Misunderstandings
Another advantage prototyping has over documents like business plans and specifications is that it reduces the chance of misunderstanding. A paper that describes what you are going to build requires people to imagine the final solution. That needs a degree of interpretation on the part of the reader.
A prototype, on the other hand, shows stakeholders what you are going to build. That means everybody has the same picture of the end goal. It significantly reduces the need for people to ‘fill in the gaps’ with their imagination.
Many stakeholders struggle to imagine a finished product or service. Not only does this lead to misunderstanding, but it also creates scope creep.
Prototypes Limit Scope Creep
The clarity that a prototype brings will reduce the amount of scope creep, as much of it is born out of misinterpretation. But prototypes reduce scope creep in another way too.
To understand why a prototype reduces scope creep one must first understand why it occurs. One of the main reasons is stakeholders struggle to think through the specifics of a service. It is not until they start seeing it that they realise what is missing or what should be different.
By producing a visual representation of the product in the early days, it helps stakeholders see what is missing or wrong early on, while things can be easily adjusted.
But it is not just stakeholders who will be able to spot shortcomings with the solution; users can too.
Prototypes Are Perfect for Testing
One of the primary reasons to create a prototype is to have something that you can test. A tangible product that can be put in front of users and they can try out. By testing with users, it is possible to identify problems early, when fixing them is still inexpensive. But testing a prototype can do more than just identify problems.
In the early days of a project, we make a lot of assumptions about what users want. Some companies do market research, but just like stakeholders users often struggle to picture what it is you are proposing building.
By creating a prototype, users can try out the service you are considering building. They can provide valuable feedback that will save you a lot of money.
For example, you might be considering building a specific piece of functionality that turns out users don’t need. Alternatively, you might have missed something that users consider essential and would have been expensive to add later.
Testing a prototype allows you to validate the assumptions you make and be confident you are building the right thing.
Prototypes Encourage Experimentation and Iteration
Digital projects are very different to others. In traditional projects, upfront planning is crucial, because the cost of changing direction once the project is underway is prohibitive.
But when it comes to digital, pixels are cheap. It is easy to experiment and try different approaches until you find the perfect way forward. The cost is even more affordable when working with a prototype.
You can quickly build ideas and test, before improving them through iteration. Combined with the unprecedented level of data that you can gather on a prototypes, this allows you to quickly iterate towards your minimum viable product and even beyond.
Prototypes Keep Costs Low
All of the advantages we have outlined so far boil down to a single compelling argument; prototypes save the business money. That is ironic considering one of the biggest excuses not to prototype is the cost. But in truth, you cannot afford not to prototype. Just look at all the ways they save money:
- They reduce time spent in meetings trying to agree on a direction.
- They avoid changes caused by misunderstanding between stakeholders.
- They limit scope creep and the associated costs of retrofitting new functionality.
- They avoid building functionality that is not required.
But the cost of not prototyping is more than financial; it costs in time too. Projects stall, you miss deadlines and opportunities are lost. The company wastes time because of a lack of clarity about what they are building.
This time will ultimately cost the organisation money and market share. Again, this is ironic as another argument against prototyping is a lack of time. Once again, I argue you don’t have the time not to prototype.
Resist the urge to rush into projects or resort to lengthy specification phases. Instead, start with a prototype. I guarantee it will save you money and time in the long run.
Questions to Ask When Prototyping
There is no definitive answer as to how to make a prototype. Any of the approaches outlined above are perfectly valid.
But before you start building it is worth asking two questions.
How Much Time Do You Have for Prototyping?
Many dismiss prototyping as a luxury that only bigger projects can afford. But that is because most people think of hi-fidelity prototypes, rather than sketches on a piece of paper.
In truth, prototyping can fit any budget and any amount of available time. But, the approach you choose to take will be dependant on these factors.
Decide how much time you can set aside for producing and testing a prototype. Once you have done that you can then decide what kind of prototyping that allows.
If all you have is a couple of hours, then sitting down with a user and running through a few hand drawn sketches might be all you can do.
If you have a few days then you can explore some wireframing with a handful of different sample users.
Once you start getting into weeks then you can build something more interactive and representative of the final product. You can also run multiple rounds of usability testing to validate the approach.
That said, even these rich, interactive prototypes often start out as a few sketches. They are just taken further by the team over time.
Although time is the biggest constraint, it is not the only consideration. You also need to ask yourself why you are creating a prototype in the first place.
What Are You Using the Prototype For?
Prototypes can be used in many ways from inspiring management to testing various approaches and establishing a clear direction. In many cases it will be used for a number of these purposes, but it is worth being clear about what your number one objective for the prototype is. That is because it will help define your approach.
For example, if your primary purpose for building a prototype is to excite management and sell them on your approach, then a highly designed prototype will probably be preferable. While, if your objective is simply to test a websites information architecture, you will need nothing but some blank pages and clickable navigation.
If you choose to use your prototype as a specification for the project, then it will need to be fairly detailed, including providing a strong sense of any interactivity required.
But it is important to remember that a prototype can change over time. It can start simple and evolve becoming increasingly representative of the final deliverable. In fact in most cases this is preferable.
How to Make a Prototype That Inspires
When you first start prototyping a lot of what is being produced is educated guesswork. That means it makes sense to minimise the effort being put into it as it will almost certainly need to change. That is why pen and paper or a tool like Balsamiq are a good fit in those early days.
As you become more confident in the direction, based on testing and discussion with stakeholders, you can start to flesh out the prototype by introducing depth, design elements and better copy.
A prototype should repeatedly pass through a loop of design, testing and iteration. Each round of testing should help you refine the approach and ensure you are heading in the right direction.
Through this process of iteration, the detail of your prototype should reflect how confident you are in your chosen direction. The more you work on it, the more finished it will appear.
But this process of iteration can be damaging if it is allowed to limit our thinking.
The problem with the process of iteration is that it leads us to see our prototypes as steps along the road to the final solution. But that means anything we add to the prototype has to be practical. We will need to get agreement for it, and it will have to be something we can build on the agreed technology stack. There is just no point in prototyping something that isn’t practical or will never get approved.
That is a dangerous mindset as it immediately constrains the prototype. We start compromising the user experience because we know the development team will say it is not possible or senior management will reject it.
Stop Constraining Your Prototypes
Depending on how we are going to use our prototype that attitude could well be a mistake. For a start, we make a lot of assumptions when we decide some aspects of our prototype are not practical. After all, it is possible to build anything; it just depends on how much we are willing to spend.
As for stakeholders, we are often wildly wrong about what they will accept or reject. We will not know until we try.
Most importantly, prototyping within these constraints set the bar too low from the outset. Stakeholders never get to see just how good a great user experience could be.
Show Management What Good Looks Like
If you show a stakeholder an outstanding experience they often get excited by it, and that motivates them to make it happen. It isn’t until you show them what a good experience could be, do they see its value. Only then do they become willing to make the compromises required to make it a reality.
It is also surprising just how often our assumptions about who will accept what, proves wrong. Somebody who you thought would reject your approach, becomes your greatest advocate when they see the potential.
Use a Prototype to Shift the Conversation
Then there is the fact that showing an inspiring prototype can shift the conversation. Imagine for a moment that you wanted to design an experience you knew was impossible on the existing technology stack. It would fall to you to convince management that the whole technology stack needs changing. That will be an uphill battle.
However, if you build a prototype that ignores the technology constraints and management love it, then it now falls to the developers to explain why the technology stack cannot support it. The burden of proof has switched.
Set the Bar High and Compromise Down
I am not claiming that if you prototype the perfect user experience suddenly everybody will buy in and you will get it approved. There will be compromises. But these compromises will begin from a high starting point, and everybody will be clear as to what users and the business will lose. If you don’t show them what best practice looks like, they can never know the cost of that old technology stack, or the companies out of date attitudes.
This approach to prototyping which is designed to inspire and excite stakeholders works even better when you include them in the process of creating the prototype.
Who Should Be Involved in Prototyping?
The worst thing you can do when prototyping is work in isolation. Doing so will not only lead to an inferior solution, it will also undermine many of the benefits listed above.
Delivering quality digital services requires many specialists working closely together and many more people to agree with the chosen approach. That makes it almost impossible for a single person to sit down and design a prototype.
Who then do you need to involve? Well, the people you need fall into two categories – those who will produce the final digital service you are prototyping and those whose buy-in is required.
Let’s look at each in turn.
You really need as many of the team who will be building the digital service involved in the creation of the prototype as possible.
To start, you obviously want a user interface designer in the room. Their expertise in visual hierarchy in particular will be invaluable.
If you have separate user experience designers, make sure they are represented. They will provide a perspective on how the service being prototyped fits into the broader customer journey.
Have content specialists involved too. They will be able to help with messaging and information architecture.
Then, if you have them, include a user researcher. Somebody with a clear understanding of what the user wants to achieve and what questions they have.
Finally, don’t forget to include developers. They are often left out, but their involvement is crucial. Too often decisions are made at the prototyping stage that have serious ramifications for development further down the line.
Beyond the core team, also include representative stakeholders from across the organisation. Typically these include:
- Senior Management.
- Product Owners.
In fact, I encourage an open door policy when it comes to prototyping. If somebody wants to be involved, allow them. That is because if they are involved in the creation of a prototype they feel a sense of ownership over it. If they have a sense of ownership over it then they are less likely to criticise it and more likely to defend it to others.
Admittedly, including a large number of people in the prototyping process can sound intimidating. But, done right, it can be hugely effective.
How to Prototype Collaboratively
How you approach collaborative prototyping will be dependant on the number of people involved and who those people are.
However, whatever the circumstances, not everybody needs to be equally involved. Depending on the type of prototype you are producing, some people will be doing more work than others.
That said, some form of kick-off prototyping workshop with as many of your participants as possible is a good way to begin. It is an opportunity to explore lots of different ideas and move towards an initial direction.
One way of running this session is called a design sprint.
Run a Design Sprint
Design Sprints were born out of Google Ventures, the venture capital arm of Alphabet, Inc. They were initially developed to aid startups to address business challenges they face. As the Sprint website says:
The sprint is a five-day process for answering critical business questions through design, prototyping and testing ideas with customers.
In many cases, this translates into a way to define and kickoff some form of digital project, although Google Ventures have used the technique beyond that field.
Google has created a highly structured five-day process with activities defined for each day. A typical design sprint runs as follows:
- Monday: The group works with experts from across the organisation to identify the ultimate goal and map out the challenge for the week.
- Tuesday: The team starts exploring a variety of solutions through looking at sources of inspiration and sketching various approaches that they could take.
- Wednesday: The group looks at the solutions explored on Tuesday and decide which ones have the best chance of fulfilling the target for the week. The team then expands those sketched solutions into storyboards.
- Thursday: The group turns the storyboards into a working prototype designed to mimic the final approach ready for testing.
- Friday: The final prototype is shown to prospective users and its viability is tested.
The whole process is highly interactive, experimental and user-focused. In short, it embraces many of the principles of design thinking to produce something tangible with which everybody can agree.
The problem with design sprints is that they are time intensive. Although it maybe possible to get your core team in a room for a week, getting other stakeholders may prove difficult, especially those in senior management.
Monday does provide an ability for stakeholders to be involved to a more limited level, but this still leave the danger of somebody in senior management derailing the process further down the line if they don’t like the output of the sprint.
There are two ways of addressing this problem. The first is that they delegate their authority to somebody in the room that they trust. If they take this approach they have to recognise they lose the ability to overrule later.
The other approach is for them to check-in regularly throughout the week to review progress. That will allow them to course correct the group if they are uncomfortable with the direction, before too much work is done.
Of course, getting five days of uninterrupted time for anybody is going to be tough, not just senior managers. That is why sometimes a shorter workshop is preferable.
Run a Shorter Workshop
The key with shorter workshop sessions is to have a clear idea of your objectives. It is also important to ensure you are actually creating something together, rather than just having a meeting.
What that something is will be dependant on available time. If you only have a couple of hours, the best approach might be to focus on identifying a prioritised list of tasks and questions that the prototype will need to address.
Given more time you can explore the visual hierarchy and content for key pages in the prototype. That can be done through a range of interactive exercises.
Whether you are running a 2 hour long workshop or a 5 day design sprint, one thing you should always do is upfront research.
Do Your Research
Starting to prototype without really understanding your users will lead to disaster. It will result in a prototype that meets the needs of internal stakeholders, while largely ignoring users. For the final digital service to be effective, that cannot be allowed to happen.
Any prototyping workshop has to be relentlessly focused on user needs and that means you have to know what those needs are.
You need to understand the following:
- What the users ultimate goal is.
- What tasks users are looking to complete.
- What questions user have.
- How users are feeling.
- What pain point are users wanting help with.
- Where the prototype fits into the overall user journey.
With this in mind, before you start collaborating on a prototype it is important to first undertake some user research. Go into the meeting with a customer journey map or some other visualised form of that research to help focus everybody involved on user needs.
Hopefully, by the end of the workshop, you will have a clearer idea of how you can meet those needs. What you won’t have is a fully working prototype. That will have to be produced following the workshop.
The inevitable question at this point is what should we use to produce the prototype?
Which Is the Best Tool for Prototyping?
There seems to be endless debate about which tool is best for prototyping. In truth, there isn’t one. They all have their pros and cons, with each being better suited to different situations.
Some argue that you cannot beat pen and paper. That is certainly true for workshops because everybody can draw boxes, but pen and paper lacks interactivity and is low-fidelity.
Others argue you should prototype in a browser. That certainly is great for evolving a prototype overtime and is much more representative of the final deliverable, but it can be time-consuming too.
Which of these tools you use is up to personal preference. But there are a few questions you might ask to guide your decision making:
- Is it regularly updated and developed?
- Does it have a community creating downloadable libraries of preset objects?
- Does it let you assemble wireframes without fuss – could you use it quickly in front of a room full of people?
- Does it have a complete site map allowing quick jump from page to page?
- Is it fast and responsive even with large projects?
- Can you build a working prototype with it in a fraction of the time it would take you to build in HTML?
- Does it allow the creation of complex interactions when you need them?
- Does it allow the creation of realistic forms?
- Does it allow logical operations, ‘if’ statements etc?
- Does it have templates, or a library function of updatable objects to ripple changes rapidly across your model?
- Does it support the visual appearance you want?
- Does it allow commenting and feedback from stakeholders?
Which of the above matters to you will depend on the project and type of prototype you are creating. But the last point about commenting and feedback is worth particular consideration. That is because sooner or later you will have to show your prototype to people who were not involved in its creation.
Presenting Your Prototype to Others
As you will have gathered by now, I am a huge fan of prototyping. But they are not without their problems. The biggest of which is that they can confuse people who were not involved in their creation.
Those seeing a prototype for the first time are often left wondering what exactly they are looking at. Is this meant to be the final design? What does it include and what has it left out? Is this set in stone or open to discussion?
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. The key to success with this approach is to present the prototype as a discussion piece. The first iteration of a prototype should never be what you build, but instead be a vision of what is possible. Do that, and you will be shocked at just what can get approved.
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" are 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 is in my opinion is worth the investment.
Taking Prototyping Further
I am very conscious that this is the longest post I have ever written, but that is with good reason. Prototyping is the foundation of modern digital design. It is an incredibly valuable tool, so valuable in fact that it can be used for a lot more than improving your user interface.
Increasingly businesses are adopting prototyping to solve all kinds of user experience challenges. I have seen prototyping used to address transition points between social media and the website or from the website to a mobile app. I have even seen it used to re-imagine offline experiences too.
As I said earlier, Disney even built a prototype showing how a Magicband could improve the experience in their parks. A prototype that led to their executive green lighting over $1 billions in renovations.
However, I am also conscious that prototyping can feel intimidating. It can involve changing how you have traditionally worked and persuading many stakeholders to get onboard.
I would encourage you to start with some simple sketches or initial wireframing. You can expand beyond that over time. Alternatively, drop me an email. I would love to work with you to integrate prototyping into your organisation.