Lesson Prototyping DT LRP

Lesson Prototyping-DT-LRP
6.1: The Key Benefits of Prototyping

Estimated time to complete: 8 mins
“One of the big problems in corporate North America and Europe is that people think that
innovation is a thinking activity. You don’t innovate though powerpoint. You innovate by
building things.”
—Tom Wujec, Fellow at Autodesk. Autodesk is an American multinational software
corporation that makes software for the architecture, engineering, manufacturing, media,
construction, and entertainment industries.
Watch this video to learn why Tom Wujec encourages us to be innovative by “getting our
hands dirty” though prototyping. Tom Wujec will give you an overview of the key benefits of
quickly creating prototypes.
Video
References & Where to Learn More

XPRIZE, Rapid Prototyping, 2015: https://www.youtube.com/watch?v=oDdOqLblmVQ
Design Thinking: Get Started with Prototyping
Prototyping is an integral part of Design Thinking and User Experience design in general
because it allows us to test our ideas quickly and improve on them in an equally timely fashion.
The Institute of Design at Stanford (d.school) encourages a “bias towards action”, where
building and testing is valued over thinking and meeting. However, why is prototyping so
important in the design process? Moreover, how does it help you create human-centred design
solutions? Before we start making prototypes to test our assumptions, let’s get a closer
understanding behind the what, how and why of prototyping.
Imagine this situation: It’s an exciting new project, something your team had spent months
brainstorming and planning, then building and crafting to perfection. You did all you could
to ensure it was just right, with all the necessary features. You tried to ensure that you gave
design more focus and that your message was crafted well. The website attracted attention
and brought in many interested visitors looking for the products you'd collected on the site,
but somehow the product and service providers just weren't interested in testing it out. They
seemed comfortable just to keep doing business as usual, uninterested in the thousands of
hits your website was getting from potential customers. It made no sense to you, but there
you were months later, having sweated and spent valuable time, money, and resources and
even attracting visitors, but no customers.
What went wrong?
It's a story repeated time and time again—ideas being executed by people with an obsession
for making a dent in the market, making big changes in society or just completely re-
inventing the wheel, only to realise right at the end of their journey that they've been wasting
their time or focussing on the wrong thing.
This is where prototyping comes in by providing a set of tools and approaches for properly
testing and exploring ideas before too many resources get used. Many of us may recall the
art of prototyping from our early childhood where we created mock-ups of real-world
objects with the simplest of materials such as paper, card, and modelling clay or just about
anything else we could get our hands on. There is not much difference between these types
of prototypes and the early rough prototypes we may develop at the earlier phases of testing
out ideas.
“If a picture is worth a thousand words, then a prototype is worth a thousand meetings.”
– Saying at IDEO
What is a Prototype?
Author/Copyright holder: Samuel Mann. Copyright terms and licence: CC BY 2.0
Any finished product is just that—at the finishing line of a journey, a design journey involving
a prototype or two (or more) with working titles such as ‘Mark I’, ‘Mark II’, ‘Mark III’, and so on.
A prototype is a simple experimental model of a proposed solution used to test or validate

ideas, design assumptions and other aspects of its conceptualisation quickly and cheaply, so
that the designer/s involved can make appropriate refinements or possible changes in
direction.
Prototypes can take many forms, and just about the only thing in common the various forms
have is that they are all tangible forms of your ideas. They don’t have to be primitive versions
of an end product, either—far from it. Simple sketches or storyboards used to illustrate a
proposed experiential solution, rough paper prototypes of digital interfaces, and even role-
playing to act out a service offering an idea are examples of prototypes. In fact, prototypes
do not need to be full products: you can prototype a part of a solution (like a proposed grip
handle of a wheelchair) to test that specific part of your solution.
Prototypes can be quick and rough — useful for early-stage testing and learning — and can
also be fully formed and detailed — usually for testing or pilot trials near the end of the
project.
Prototyping is about bringing conceptual or theoretical ideas to life and exploring their real-
world impact before finally executing them. All too often, design teams arrive at ideas
without enough research or validation and expedite them to final execution before there is
any certainty about their viability or possible effect on the target group.
Why We Need to Prototype

Early Research isn't Everything
Research conducted during the early stages of your Design Thinking project does not tell you
everything you need to know in order to create the optimal solution. Regardless of whether
you have researched thoroughly and gathered a large body of information, or whether your
ideation sessions have resulted in what many perceive as a world-changing solution, testing
is still crucial for success. Design teams can easily become fixated on the research artefacts
they have gathered during the earlier phases of exploration, creating a bias towards their
ideas. By prototyping and then testing those prototypes, you can reveal assumptions and
biases you have towards your ideas, and uncover insights about your users that you can use
to improve your solutions or create new ones.
You can use prototyping as a form of research even before other phases in Design Thinking,
allowing you to explore problem areas in interfaces, products or services, and spot areas for
improvement or innovation.
Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0
Design Thinking is a design methodology that provides a solution-based approach to solving

problems. It’s extremely useful in tackling complex problems that are ill-defined or unknown,
by understanding the human needs involved, by reframing the problem in human-centric ways,
by creating many ideas in brainstorming sessions, and by adopting a hands-on approach in
prototyping and testing. The five stages of Design Thinking are not sequential steps, but
different “modes” you can put yourself in, to iterate on your problem statement, ideas, or
prototype, or to learn more about your users at any point during the project.
Prototype to Empathise, Define, Ideate, and Test
We can — and should — use prototyping as part of various stages of Design Thinking. You
can use prototyping as an ideation method, as it allows you, as well as users, to explore
alternative solutions. This is possible because prototypes are physical representations of
your solutions, and thus prototyping allows you to think by doing. Adopting a ‘thinking by
doing’ mindset is extremely helpful in letting you derive more value from researching,
defining, ideating, and testing.
Some of the purposes that prototypes fulfil are:
Exploring and Experimentation

You can use prototypes to explore problems, ideas, and opportunities within a specific area
of focus and test out the impact of incremental or radical changes.
Learning and Understanding

Use prototypes in order to better understand the dynamics of a problem, product, or system
by physically engaging with them and picking apart what makes them work or fail.
Engaging, Testing, and Experiencing

Use prototyping to engage with end users or stakeholders, in ways that reveal deeper insight
and more valuable experiences, to inform design decisions going forward.
Inspiring and Motivating

Use prototypes to sell new ideas, motivate buy-in from internal or external stakeholders, or
inspire markets toward radical new ways of thinking and doing.
How Prototyping Works

Bias Towards Action
One of the essential mindsets for Design Thinking listed in d.school’s Design Thinking
Bootcamp Bootleg Toolkit is having a bias towards action:
“Design thinking is a misnomer; it is more about doing than thinking. Bias toward doing and
making over-thinking and meeting.”
– d.school
This means that analysis paralysis is unable to take hold, because you will investigate each
assumption through active testing, instead of theoretically thinking it through. By using
controlled experiments, you can either prove or disprove your assumptions in their real
context and thus further refine — or even abandon — your initial idea.
Learning by Doing
One of the most important aspects of Design Thinking is exploring unknown possibilities and
uncovering unknown insights. This is the reason the discipline places emphasis on learning
and on activities that increase the learning potential of the team. You can boost action-
orientated learning by experimenting and exploring the proposed solutions in order to
understand what problems may exist with the assumptions behind those solutions. As such,
your team can iterate rapidly, modifying your test models and moving you closer and closer
to the goal.
Creative Serendipity
Do breakthrough ideas really just come from nowhere?—A spark of genius in a rush of
creativity? With the way breakthrough inventions, start-ups, and other revolutionary ideas
are “sold” to inspire and encourage creativity, one would think that all we need is flipping a
switch to a success mindset.
David and Tom Kelley, founders of international design firm IDEO, discuss in their
book Creative Confidence the importance of cultivating creative serendipity. They encourage
the adoption of approaches that lead to an epiphany-friendly environment within oneself.
The idea is this: by deeply immersing yourself within your subject of interest, you can open
up opportunities for happy accidents. What this means is that the vast majority of people
who "stumble" across breakthroughs do so along their journey of engaging with the subject
area.
The Kelleys cite various examples of people who made breakthroughs not by thinking
through solutions but by trying things and figuring them out. One of the best ways to learn
about the positive and negative dynamics of your solutions is to take physical action, by
experimenting with and exploring potential solutions. When you prototype, you bring your
ideas onto a tangible plane, which will enable you and your team to see and discuss the pros
and cons, to learn from users’ feedback, and to create little opportunities for creative
serendipity. So, stop thinking, and start doing now.
The Take Away

Many times, we tend to invest in exciting new ideas, brainstorming, and planning for their
implementation — until we realise, after launching them, that our brilliant designs
had no traction with our users. In other words, the assumptions we based our solutions on
might have been wrong – and when they are wrong, they can lead to significant wastes of
time and resources. Prototyping helps prevent this. Prototyping quickly, and frequently, is
the best way to test your assumptions, learn about users, and improve on your ideas.
Prototypes can be anything from sketches on a napkin to role-playing: just anything that lets
you makes your ideas tangible and testable. Prototyping helps create a bias towards action
(i.e., make rather than think) and opportunities for creative serendipity — the innovative
spark you need to create truly useful and revolutionary solutions.
d.school Bootcamp Bootleg, 2013: http://dschool.stanford.edu/wp-
content/uploads/2013/10/METHODCARDS-v3-slim.pdf
Tom Kelley and Dave Kelley, Creative Confidence: Unleashing the Creative Potential Within Us
All,2013.
Hero Image: Author/Copyright holder: m0851. Copyright terms and licence: CC0
PLEASE ANSWER THE FOLLOWING QUESTIONS
Prototyping in Design Thinking: How to Avoid Six

Common Pitfalls
The Design Thinking process cannot be done without prototyping and testing. However, for
companies or teams unfamiliar with the Design Thinking method, there might be some common
mindsets about prototyping that potentially undermine its effectiveness in helping you craft the
optimal design solutions. Let’s look at six of the most common misconceptions about
prototyping, and how to combat each so that you can avoid these pitfalls and build better
products or services.
If you were not (or if your team is not) familiar with Design Thinking, you might have some
ideas about prototyping — what it’s meant for, when it should be done, etc. — that are
actually counter-productive to the process. Thankfully, we have listed below six of the most
common misconceptions or incorrect mindsets, as well as solutions to each to help you
reframe your mindset or rethink your process. Let’s get started!
1st Pitfall: Diving into the First Good Idea
It's attractive to want to grab at the first glimmer of light you see and run with that as your
final solution. This is often inspired by a senior manager, not necessarily involved in the
process of prototyping or ideation, who might not have enough understanding of how it
works. Often, teams try to save time and move headlong into implementing their very first
promising idea.
This leads to an issue, because most problems we are trying to solve are more complex than
they look on the surface. The way people behave, constraints in the environment, and a
thousand other factors might cause matters to turn out differently from your or your team’s
expectations. A promising idea, pushed all the way into a fully formed solution without any
prototyping or validation, may turn out to have a couple of assumptions wrong (if you are
lucky). The result is a solution that doesn’t work, and lots of time and energy wasted.
Solution: Explore a Range of Different Approaches First
One of the keys of successful prototyping is working through a number of models and
exploring different approaches, before finally including the best characteristics and
removing the problematic ones for the final solution. Test out many ideas. Test them by
building prototypes — no matter how rough and simple — and test them on team-mates,
internal stakeholders, and users. Test many alternatives even within one idea, explore
variety, and don't discount possibilities until you've tested them. Most times, you will be
inspired to create more ideas, or merge a few solutions into a better and more successful
one, by testing alternative ideas and making quick and dirty prototypes.
2nd Pitfall: Falling in Love with Your Prototypes

The endowment effect, otherwise referred to as “investment bias”, can interfere
significantly with the value derived from prototyping. The endowment effect happens when
people ascribe more value to an object simply because they have ownership over it. In
prototypes, the endowment effect can create the dangerous situation wherein prototypes
become too “precious” to fail or give up on.
This is when the creators of a prototype becomes overly invested in their creation, resulting
in their overlooking of faults and insistence on implementing the current model due to the
amount of time, effort or resources invested in creating the model. It can happen when
designers become too emotional about prototypes or ideas that they have conceived, even
when it becomes clear that the ideas are problematic. This usually happens when designers
spend too much time creating and perfecting a prototype, when a rough and dirty model
would suffice. Additionally, executing early prototypes at too high a fidelity may result in this
kind of bias. If we were to do this with a prototype, the effort we’d put into making it as
realistic and looking as refined as possible (without reckoning on refining the actual faults
in it) might help us dupe ourselves into believing we’d landed on a miracle discovery—a
winner that would be sure to resonate with users. Usually, low-fidelity prototypes, such as
paper mock-ups or sketches, are sufficient for early stage testing. Only towards the end of
the project do you need to create higher-fidelity prototypes that require more energy and
time investment.
Avoid the endowment effect by creating quick, low-fidelity prototypes using cheap materials.
Solution: Start with Cheap and Fast Prototypes
Start simple. Make quick and fast prototypes. Make use of low cost, readily available
materials in early-stage, low-fidelity prototypes. Always make sure that your prototype has
just the level of detail required for what you are testing for, never too much. This would
prevent you or your team-mates from becoming too attached to a prototype.
Also, be prepared to break, completely destroy or throw those models away once the
questions they pose are answered. You can achieve this mentality by using low-cost
materials in your prototypes. Test out a number of ideas and models as rapidly as possible
in order to avoid becoming anchored to one stream of thought. Having an expendable
prototype is a million times better than having an expendable concept—i.e., one that won’t
latch with anyone, least of all your usership, no matter how fancy the model of it looks.
3rd Pitfall: Wasting Time Explaining and Pitching

Another problem you should avoid is spending too much time pitching and explaining ideas
— and too little time making things and figuring out issues with and challenges to your ideas.
This results in a theoretical focus and could lead to moving forward with ideas that you will
not have tested. Show; don't tell. To explain how a solution works, create a model and
show how it will work. If you are unable to show it working, you may find there are holes in
the idea — and that’s a learning opportunity right there!
Solution: Have a Bias Towards Action
Embrace the bias towards action mindset by opting to show the value of the ideas instead of
telling everyone how great your combination of these notions will be. When you build simple
prototypes to show what your ideas are, you also make them much easier to understand and
allow others to build on them. Illustrate what you want to explain physically. It's the best way
to know whether you're on to something or not.
For instance, when IDEO was approached by Gyrus ACMI, a medical visualisation and energy
systems company, the team met with specialist surgeons so as to understand their needs
better. After one of the surgeons explained (or tried to explain) how their surgical instrument
could be improved, an IDEO designer immediately created a rough prototype of the idea. The
team was able to understand instantly what the surgeon meant, and the discussion was
brought forward, thereby saving the team many more meetings. Prototype to show, because
showing is much more productive than telling.
4th Pitfall: Prototyping Without a Purpose

Rushing a promising idea into a solution is a bad idea, but creating prototypes without a
purpose is equally bad. Prototypes exist for a reason: to test and validate assumptions, test
our ideas for solutions, or explain and flesh out ideas. Prototyping for the sake of prototyping
can result in a lack of focus, or prototypes with too much detail (i.e., a waste of time) or too
little detail (i.e., ineffective in tests).
Solution: Have a Question in Mind
Before you create a prototype, ask yourself, “Why am I creating this prototype?” Make sure
you have a central purpose (i.e., to test my assumption X, or to test the usability of my
solution, etc.), and then build your prototype to match that purpose. For instance, if you need
to test your assumption that your users will not be willing to use a piece of equipment
heavier than 2 kg, then you might not even need to create a functional prototype. Simply
create a prototype that weighs below 2 kg, and another that weighs above 2kg, and
test both on users. You’ll save time by creating prototypes at the right level of fidelity, and
still be able to learn exactly what you want to learn.
5th Pitfall: The Failure Roadblock: Feeling Discouraged by

Failed Prototypes
When prototyping, you might feel a sense of failure at times. This is because the steps
involved in prototyping might fall into what we generally label as “failure”, especially when
tests reveal your false assumptions. However, being disillusioned when your ideas don't
work out can cause a negative state of mind and inhibit progress. The point of prototyping is
to ensure ideas will work and to validate the assumptions made when conceptualising the
ideas. To be productive when prototyping, we should unlearn what we are taught about
failure. When doing Design Thinking, you should embrace the right kind of failure. Failure
provides massive learning opportunities, which will eventually lead to new insights and
eventual success.
"Fail faster, succeed sooner."

— David Kelly, founder of IDEO
Solution: Reframe the Idea of Failure
“I have not failed. I’ve just found 10,000 ways that won’t work.”
– Thomas A. Edison, American inventor who developed the motion picture camera and the
electric light bulb.
Reframe the idea of failure in prototype testing into a learning mentality. Remind yourself
that wrong ideas and failed prototypes allow you to learn more than successful tests and
prototypes do. Embrace the principles of learn methodology by working validation
into every decision that you make or have a hand in making. Validation reframes the concept
of failure and makes it part of the process of learning instead of being a destructive influence.
When you think of prototypes and tests as learning opportunities, you set yourself up for a
kind of positive failure that leads to a new, more informed experiment.
6th Pitfall: Seeing Prototypes as a Waste of Time

By constantly having to build prototypes for every idea and assumption that you have,
wouldn’t you be wasting time? Many times, designers and teams who are not used to Design
Thinking feel that prototyping is a waste of time and resources. “Wouldn’t building
prototypes slow us down?” they ask. “Wouldn’t we be better off to stay focussed on the
drawing board before we get around to putting things together in the real world?”
The truth is the opposite. Although we might spend time when we build prototypes, they
actually allow us to move faster in the long term. It’s because, through prototyping, we are
able to seewhether our ideas would work out, and be able to refine or tweak them further...
or abandon them when we’ve realised that what seemed good on paper won’t hold water in
the sea of harsh reality and unforgiving consumers. In the long term, we will be able to reach
the ideal solution faster.
Solution: Adopt a Long-Term View
Build with a long-term view in mind. When making prototypes to test your assumptions or
learn about your users, remember that the small amount of time you are spending now will
help you save days and even weeks of time in the future. Communicate to internal
stakeholders who may be concerned about the time “wasted” on prototypes, so the whole
team (and ideally, the whole company) is on the same page. It may be counter-intuitive, but
spending time on prototypes will save you time. Tim Brown, CEO of IDEO, says it best: “They
slow us down to speed us up.”
The Take Away

Prototyping is crucial in every Design Thinking project. However, there are pitfalls that could
undermine your efforts to let prototypes work for your team. Specifically, you have six of
these to avoid, everything from becoming discouraged by the insight-giving nature of failed
prototypes to putting inordinate amounts of effort into your first prototype and clinging to
it because it seems infallible. Learn to embrace the idea of constantly and rapidly
prototyping, and make sure you have the right mindset when making prototypes. The old
saying goes that nothing is more powerful than an idea whose time has come. That may seem
all very well, but a series of prototypes will bring such an idea into the real world where
people can make it truly powerful.

Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires
Innovation, 2009
Peter Manzo. Sep. 23, 2008. Fail Faster, Succeed Sooner. Stanford Social Innovation
Reviewhttp://www.ssireview.org/blog/entry/fail_faster_succeed_sooner/
Tom Kelley and Dave Kelley, Creative Confidence: Unleashing the Creative Potential Within Us
All,2013.
Hero Image: Author/Copyright holder: Unknown. Copyright terms and licence: CC0
What Kind of Prototype Should You Create?
So, you want to create prototypes to help in your design process or Design Thinking project.
However, what kind of prototype should you create? How detailed should your prototype be?
What should your prototype be created for? If you’re asking yourself these questions, then great,
because you’re on the right track! We will go through the different levels of fidelity of
prototypes, as well as the kinds of prototypes you can create. We’ve also created some highly
useful templates that you can use to guide yourself in your prototype-making process.
Afterwards, you should be in a much better place for starting to create your own prototypes.
Prototypes begin as extremely rough, quick, and low-cost experiments in the early stages of
a design process or Design Thinking project, later moving towards higher-fidelity models,
which are more complex, detailed, and costly final drafts. Your design team will continue this
process until you manage to uncover or address problems sufficiently and in such a way that
the team feels confident that you’ve arrived at a production-ready solution. By then, your
solution should meet the needs of the user, as well as the business or organisational
objectives.
Fidelity of a Prototype
The fidelity of a prototype refers to its level of completeness and detail. The degree of
completeness of the prototypes you build depends on the stage of progress; these include
the following:
• Low fidelity – low cost, rough and quick to build

• Medium fidelity – slightly more detailed, still rough but closer to the solution
• High fidelity – much closer to final, very detailed and much more time-consuming
This represents a scale of completeness or closeness to the final product, which differs
depending on the type of solutions and needs of the situation. Prototypes can also have
different parts with varying levels of fidelity. For example, you can build a prototype with
high visual fidelity but with low functional fidelity — which would be useful if you were
testing the visual aspects, rather than functional aspects, of the prototype. The main aspects,
which are the focus of the prototype, should receive more focus and, ideally, higher fidelity.
Low-Fidelity Prototypes
Low-fidelity prototypes are much easier to execute and less costly; moreover, they require
less time and are less “precious” to the design team. This allows you to develop your idea
rapidly and iterate through many versions in a short space of time, without draining much
in the way of resources. You should mainly use low-fidelity prototypes at the early stages of
a project, where you will need to test many assumptions. At this stage, you can use low-
fidelity prototypes to weed out major problems with the proposed solution and evaluate and
validate the solution hypothesis (i.e., determine whether it meets the team’s internal
requirements as well as the user’s needs).
Author/Copyright holder: Samuel Mann. Copyright terms and licence: CC BY 2.0
Paper interfaces are an example of low-fidelity prototypes.
The low-fidelity stages of prototyping also feed nicely into the early divergent stages of
ideation, where there is freedom to explore and generate new ideas and solutions. You can
keep testing and iterating your low-fidelity prototypes until the team is satisfied that you all
have explored enough variants. You can then move the models that make it through early
rounds of testing to higher and higher levels of fidelity in order to explore the finer details of
execution.
Low-fidelity prototypes may include rough sketches, paper models, simple storyboards, or
rough paper prototypes of digital interfaces. You would base your choice of the type of
prototype on the type of solution you are seeking to create.
When to Use Low-Fidelity Prototypes
Use low-fidelity prototypes when you need to test rapidly and cheaply and explore a wide
range of options in order to figure out the best ways of executing your ideas. Use them as a
proof of concept model to test out and rapidly present ideas in tangible form.
Medium-Fidelity Prototypes
After working through some early models and resolving the most obvious and blatant of
issues, you should move out of the divergent mode of the prototyping phase towards
refinement and testing slightly finer details. In order to progress to the next stage of
prototyping, you need to add more details and refinements to prototypes, making them
resemble final products more closely.
Medium-fidelity prototypes take longer to develop, for the above-mentioned reasons, and
may be costlier. This is why you should test and eliminate enough early-stage problems and
assumptions with lower-fidelity models before moving on to using medium-fidelity
prototypes.
Author/Copyright holder: Dereckson. Copyright terms and licence: CC BY 3.0
Wireframes, like the one above created on the software Balsamiq, are commonly used medium-
fidelity prototypes.
When to Use Medium-Fidelity Prototypes
Use medium-fidelity prototypes when you need to give people a better sense of what the
solution or part of the solution might look like — and when you have already tested and
validated some early assumptions. Medium-fidelity prototypes are great for refining the
execution of solutions, while still providing room for changing direction and testing out
options.
High-Fidelity Prototypes
High-fidelity prototypes are the last line of testing before moving on to execution of
solutions. They allow for providing an accurate representation of what the solution might
look like with fine details; better still, they may include much of the expected functionality.
High-fidelity models may even contain all the functional elements required although we may
execute these using less-than-optimal mechanisms or technology.
High-fidelity prototypes aim to provide the closest representation of the idea

possible without the time and cost required of final production.
Author/Copyright holder: Bohemian BV. Copyright terms and licence: Fair use.
High-fidelity prototypes, like mock-ups produced in the application Sketch, have a high level of
detail and are close representations of the final product.
When to Use High-Fidelity Prototypes
Use high-fidelity prototypes when you need to test the full spectrum of dynamics of the
completed solution as well as analyse it for functional, visual and experience purposes. It
provides a much more realistic picture of what the end product may be like and allows for
final-stage refinements and experience tests. High-fidelity prototypes are excellent for the
final selling of ideas when funding decisions need to be made, or when potential markets are
being approached for feedback.
Prototyping for Empathy

While you will create most prototypes in order to evaluate the ideas that your team has come
up with, it is also possible to use prototypes to develop empathy with your users, even when
you do not have a specific product in mind to test. We call this “prototyping for empathy” or
“active empathy”, and we usually do it in the early stages of a design project. Use empathy
prototypes to gain an understanding of the problem as well as your users’ mindsets about
pertinent issues. You will find that using empathy prototypes is best after you have some
basic research and understanding of the design problem and users. They are extremely
useful in helping you probe deeper into certain issues or areas. Before building an empathy
prototype, hence, you will need to figure out what aspects of a user or the environment you
would like to probe deeper. Then, build prototypes that will effectively evaluate those
aspects.
“Prototyping is the conversation you have with your ideas.”

—Tom Wujec, Fellow at Autodesk, a global leader in 3D design, engineering and
entertainment software
For instance, if you want to find out about your users’ mindsets towards reading, you could
ask your users to draw how they think about reading. After they have finished, you could ask
them about what they have drawn and — from there — understand how they think.
Alternatively, you could create an empathy prototype for yourself and your team-mates so
as to help you step into your users’ shoes. If you are building prototypes for people with
visual impairments, such as the elderly, you could create a quick prototype by applying some
gel onto a pair of lightly tinted sunglasses. Wearing this prototype would simulate the poor
eyesight of the elderly and enable you to gain an idea of the obstacles they face.
You can download the “Prototyping for Empathy” template and use it as a guide for yourself
and your team.
Prototyping to Test
This will be the most common prototype you will create in a design project. Create iteratively
improved prototypes in order to test out solutions quickly, and then use the test results to
improve your ideas.
So as to start with prototyping to test, you will first need to identify the key question(s) you
want to answer through your prototype. That way, you can focus on building the aspects of
the prototype that test these questions, thereby saving time and allowing you to pursue
various ideas at the same time. Remember that not all questions require a functional
prototype: sometimes, creating something with the right weight or size will do the trick.
While prototyping, keep in mind how you will test the prototype. Figure out if you will need
to test the prototype in the natural environment of the user (chances are, the answer is
“yes”). If that is not possible, determine how best to simulate the natural environment.
You can download and print the “Prototyping to Test” template so you can get started
quickly testing out your solutions, and then use the test results to improve your ideas.
Prototyping to Decide
Sometimes in your design project, you may face conflicting ideas from different team-mates
or stakeholders. Prototyping can be an effective tool for enabling your team to compare the
ideas and prevent any disagreements from developing.
When building a prototype to decide, you can see how each of the solutions will work better.
You will be able to see whether the prototypes lack in some areas; for example, you may
realise that the prototype would not work in the natural environment of users. Your team
will also be able to see the different ideas tangibly, and hence discuss the ideas and build on
them, or suggest ways to merge the best aspects of each prototype.
After you have built the (preferably low-fidelity) prototypes, present them to your design
team. You can also invite internal and external stakeholders and experts — and, obviously,
your users — to provide you with sufficient feedback for moving on in the design process.
For your inspiration and guidance, you can download the “Prototyping to Decide” template.
The Take Away

Prototyping can seem confusing, but it does not have to be that way. Know when to create
the right level of fidelity of your prototype, as well as what exactly you are testing, and you
should be able to create prototypes rapidly in order to test many ideas. You can use
prototyping to test ideas and assumptions, to gain an empathic understanding of your users,
or to help your design team decide amongst a few competing ideas. Above all, prototyping,
in its various dimensions, will throw open the doors to offer you priceless early views of your
target audience in their environment.

Hero Image: Author/Copyright holder: Jo Szczepanska. Copyright terms and licence: CC0
Prototyping: Learn Eight Common Methods and

Best Practices
There can never be an exhaustive list of prototyping methods, since there is quite literally an
endless number of ways you can build prototypes. What we can do, however, is provide a useful
list of the eight most common prototyping methods, together with best practice tips that help
you maximise your prototyping and testing sessions. By arming yourself with these eight
common methods, you can begin your iterative process of building prototypes in order to
empathise with your users, to decide on and refine your ideas and to test your solutions.
Before we begin looking at the common prototyping methods, let us first briefly examine the
prototyping and testing process. You will need to pay attention to these four key components
of prototyping and testing, no matter what method you choose to utilise:
• People – including those whom you are testing and the observers
• Objects – static and interactive, including the prototype and other objects the people
and/or prototype interact/s with
• Location – places and environments
• Interactions – digital or physical, between people, objects and the location
When you are building your prototypes, as well as when you’re testing them, keep in mind
these key components. For instance, if you are testing your prototype in a lab, think about
how to simulate the natural environment in which your design will engage its users. Also,
take note of other objects that the prototype will be used with. When performing a task, for
example, will the users be wearing gloves, or have their hands full? What implications would
that have on how they can use a product or service? With these four components of testing
a prototype in mind, let us look at the eight common methods of prototyping that you can
use.
Sketches and Diagrams

Sketching is one of the earliest forms of prototyping you can use. It requires very little effort
and does not necessarily rely on artistic levels of drawing skill to prove useful, and therein
lies its value. Use sketches to illustrate your ideas and launch them into the real world —
even the simplest and crudest of sketches can easily achieve that. Sketch simple illustrations
of your concepts so that they don’t exist only in your mind, hence allowing you to share these
with your team-mates for further discussion and ideation.
Author/Copyright holder: Tom Maiorana. Copyright terms and licence: CC BY 2.0
Even the messiest of scrawls (not that what we see above is a messy scrawl) can serve as
nurturing “soil” to make the seed of an idea sprout into a first-class end product.
You can also sketch diagrams and mind maps in order to illustrate a system, process, or the
structure of your ideas. You can sketch the various touch points that affect a user’s journey,
and then identify how they relate to one another. Alternatively, you can visualise and analyse
how your ideas can relate to one another and complement (or sometimes compete with) one
another. Diagramming is a useful way to understand complex situations or use cases, where
many factors and players affect one another. Journey maps, behaviour maps, system flow
diagrams, and a range of other mapping methods are at your service to help you scope out
complex situations.
Sketching is a valuable method of prototyping because you can do it practically everywhere,

with a paper and pen, or even on your smartphone or tablet.
Paper Interfaces
Author/Copyright holder: Sage Ross. Copyright terms and licence: CC BY-SA 4.0
You don’t need to be an artist to sketch for an effective outcome. The beauty of sketching is that
you can get the idea down pretty much as soon as it hits you without worrying about it
vanishing — even if you have to lean awkwardly to scribble something while standing up on a
train, it’s a great start.
Digital products like mobile apps, websites, and web services, as well as other screen-based
products or experiences often require you to create a range of prototyping methods in the
run up to the final design and development. Paper interfaces are handy at the early stages of
prototyping for digital products. You can create paper interfaces by sketching them out, or
by drawing and cutting out usable parts of a user interface (such as a text field or a dropdown
menu, etc.).
Jakob Nielsen, co-founder of the Nielsen Norman Group, explains that paper prototypes are
extremely easy and cheap to produce, while they can provide you with many insights that
can help you save money. When designing digital products, you may be tempted to create
higher-fidelity prototypes directly on a computer, or start creating the product right away.
When you use paper interfaces, however, you can uncover many areas for improvement,
such as usability issues, that can help you make improvements to your design in the early
stages, thus avoiding production costs. According to Nielsen, usability studies show that
early-stage changes are about 100 times cheaper than changes made in later stages of a
product development process. As the old proverb goes:
“A stitch in time saves nine.”

—(Anonymous)
A commonly used process in creating paper interfaces is sketching and assembling

prototypes of a working digital system. We do this by using separate sheets of paper,
including moveable interface elements, scrolling pieces of paper, and other interactive
features.
Storyboards
Telling stories is an excellent way of guiding people through a user experience.
Storyboarding, a technique derived from the film industry, is something you can use for early
prototyping to allow yourself to visualise the user’s journey or how users would experience
a problem or product. When you draw storyboards, try to imagine the complete user
experience, and then capture it in a series of images or sketches.
In Storytelling for User Experience: Crafting Stories for Better Design, Whitney Quesenbery,
co-director of Center for Civic Design, and English writer Kevin Brooks explain the benefits
of using stories in design projects. According to them, stories not only enable us to collate
information on users, tasks, and goals but also spark new ideas by encouraging discussions
and collaboration between ourselves and other designers. By drawing out a user’s
experience, we also better understand their world and are thus able to think in their shoes.
Storyboarding, as a prototyping method, ensures that we know our users well enough (it
would be hard to sketch a storyboard otherwise) and allows us to keep in mind the context
of the solution we are designing. It is useful for developing an empathic understanding of
users — and for generating high-level ideation and discussions. Storyboards, however,
are not very useful for fine-tuning the details of products, because the drawings tend to be
more macroscopic in nature.
Lego Prototypes
Author/Copyright holder: Arto Alanenpää. Copyright terms and licence: CC BY-SA 4.0
Lego’s genius transcends child’s play — we have much to tap from Lego as regards prototyping.
Lego is a staple of any kid's toy box. Its versatility and ability to spark imagination is what
drives the company's success. As a designer, you can take advantage of Lego’s ubiquity and
versatility to create quick and simple prototypes of your ideas. The best part of using Lego
to build your prototypes is that they become easy to dismantle and tweak; simply detach a
part of your Lego prototype, swap it with an alternative design, and play with it to see if it
works.
As Tim Brown, CEO of international design firm IDEO, recounts in his book Change by Design,
Lego prototyping has been widely used in IDEO’s design thinking process, including once
where it was used to create a prototype for a complex insulin injection device.
In fact, Lego has taken its toy’s ability to stimulate creativity and ideation seriously. In
collaboration with Johan Roos and Bart Victor, professors at the International Institute for
Management Development in Switzerland, it launched Lego Serious Play, a methodology that
aims to foster creative thinking and problem solving in businesses.
However, for the purposes of prototyping, any Lego should suffice. You can use Lego bricks
to create rough prototypes of products... or use Lego characters to simulate a user’s journey.
This allows your team to dive straight into setting up your scenarios and telling stories.
Role-Playing
Role-playing, or experiential prototyping, is a method that allows your design team to
explore scenarios within the system you are targeting physically. We can make the best use
of role-playing in capturing and expressing the users’ emotional experience of using a
product or service. You can also use it to gain an empathic understanding of your users —
through simulating what they are experiencing. By re-enacting scenes and situations you are
attempting to improve, your team can get a better sense of what the experience may actually
feel like and where you need to concentrate your main focus on improvement. You can also
remember the experience more vividly when you physically experience it, rather than draw
it out in a storyboard, for instance.
We can use role-playing with varying levels of detail, but the best experience happens when
you simulate the physical environment of the user. You can create props, use objects around
your workplace (such as chairs and desks), and use audio simulations by playing a
soundtrack that mimics the user’s environment. If you are the facilitator of the role-playing
exercise, assign each participant a role, and choreograph certain skits depending on the
purpose of the role-playing exercise. For instance, if you are trying to feel the emotional
experience of using your service solution, your team can act out the parts of a user and a
service provider.
Decide on roles, scenes and storylines beforehand, and possibly combine this method with
storyboarding in order to capture the scenes and the lessons you will learn from each scene.
Physical Models
When the end result is a physical product, you can use a wide range of materials to build
mock-ups for testing. You can use rough materials, such as paper, cardboard, clay, or foam,
and you can also repurpose existing objects you find around you in order to build physical
models.
The purpose of a physical model is to bring an intangible idea, or two-dimensional sketch,

into a physical, three-dimensional plane. This allows for much better testing with users, and
it can spark discussions about the form factor of the solution.
Wizard of Oz Prototypes
Wizard of Oz prototypes are prototypes with faked functions — for instance, interactivity
that comes from a human rather than an algorithm or software code, with users believing
the latter is the case — that you can use to test with your users. Like the wizard of Oz in the
story (who generates an ominous, magical and deceptive appearance from behind a curtain),
you are mimicking some aspects of your product for the sake of prototyping it, allowing you
to save time and resources. The most common example of Wizard of Oz prototypes is a
prototype of a digital system, where the user is “tricked” into thinking the system responses
are computer-driven, when they are actually human-controlled — such as a piece of virtual
assistant software in which a human, working on another computer, types the responses.
Note—ethically, we as designers are well within the boundaries when doing this; it does not
involve manipulating users for immoral gain.
So as to create a Wizard of Oz prototype, you first have to decide on what you want to test or
explore. Then, figure out a way of mimicking or faking the interactions. This requires a fair
bit of ingenuity, but you can use ready-made tools such as social media, PowerPoint, instant
messaging and videos to create a realistic imitation of computer interactivity. For instance,
you could create an interactive PowerPoint presentation and use it together with messages
sent to a computer in order to fake the interactions of a social media website without having
to code.
You are best off using the Wizard of Oz prototyping method when testing interactions of your
product before building it. However, as you may have noticed, this prototyping method
involves a fair amount of time and effort. Therefore, you can really only make the best use of
it for testing the effects and interactions of complex systems or in the later stages of your
design project.
User-Driven Prototypes
A user-driven prototype is unlike any other prototyping method previously mentioned.
Instead of building a prototype to test on users, you will instead get the user to create
something, and from the process learn more about the user. When you ask the user to design
a solution, rather than provide feedback on a prototype, you can learn about the assumptions
and desires that the user possesses. The purpose of a user-driven prototype is not to use the
solutions that the users have generated; instead, it is to use their designs to understand their
thinking. You can use user-driven prototypes to gain empathy with your users or to fine-tune
the details of your product once you have an idea in mind.
In order to create a user-driven prototype, you should ask the users to create something that
enables you to understand how they think about certain issues. For instance, if you are
interested in creating an improved airport waiting experience, you could ask users to draw
out what they think is the ideal airport waiting process — or you could give them a bunch of
Lego bricks and encourage them to show you their dream waiting area in an airport.
Alternatively, if your solution is a website, you could ask your users to create a sketch of what
features they think the website should have. For user-driven prototypes to be useful, you
should balance the amount of help you offer the users so they do not feel lost (and thus fail
to ideate), while making the session open enough so that you can learn more about the users
without shepherding them towards your own ideas, which would defeat the purpose in this
light.
Which Prototype Should I Build?

With such a wide range of prototypes you can build, it might be a little overwhelming at times
when you and your team have to decide on what exactly to build. Thankfully, IDEO’s Design
Kit offers a simple, four-step process that you can follow in order to help you decide what
kind of prototypes to use.
• What’s your idea about?

With your team, note down the key components of your idea or ideas. Figure out what
needs to be tested, and ask a key question for each component of your idea that you
wish to test.
• Which questions do you want to ask?
Choose a few questions you want answered. For instance, if you want to test out
whether the weight of your product is acceptable and usable, consider building a
rough prototype with the same weight as that of the final product. On the other hand,
if you want to test the level of interaction between the product and the user, you may
want to use role-playing instead.
• What prototype makes sense?
For each question, think about the kind of prototype that makes the most sense and
that would most effectively answer the question. If possible, hold a brainstorming
session with your team so that you can generate as many alternatives as possible,
then narrow down the choices via discussion.
• Just do it!
Design Thinking has a bias towards action. This means that you should not spend too
much time deliberating on what to build, and how to build it — just go out there and
start testing! If you are not sure about what kind of prototype to use, make a few and
test them. Your first few prototypes may be failures, but they will tell you so much
more than just thinking about what to do would tell you.
The Take Away

When prototyping, pay attention to four key considerations: people, objects, location, and
interactions. These factors will affect how your prototype will work — and what to observe
in testing sessions. With these factors in mind, you can build prototypes based on any of the
eight methods we’ve just covered: sketches, paper interfaces, storyboards, Lego prototypes,
role-playing, physical models, Wizard of Oz prototypes, and user-driven prototypes. Finally,
if you are unsure of what prototype to build, you can use IDEO’s four-step process to help
you to start making prototypes. The range of choices is wide and clear enough for you to
latch — sooner rather than later — with the right prototype for you and hence take a large
step towards ultimately realising your ideas in the form of a serviceable, user-friendly
design.

Jakob Nielsen, Paper Prototyping: Getting User Data Before You Code,
2003: https://www.nngroup.com/articles/paper-prototyping/
Whitney Quesenbery and Kevin Brooks, Storytelling for User Experience: Crafting Stories for
Better Design, 2010: http://rosenfeldmedia.com/books/storytelling-for-user-experience/
Lego Serious Play: http://www.lego.com/en-us/seriousplay
d.school, Wizard of Oz
Prototyping: http://futureofstuffchallenge.org/download/prototype/bootleg-
wizardofoz.pdf
Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires
Innovation, 2009
IDEO, Determine What to Prototype: http://www.designkit.org/methods/34
Hero Image: Grant Hutchins. Copyright terms and licence: CC BY-SA 2.0
Don’t Build It, Fake It First – Prototyping for Mobile

Apps
The design phase for mobile applications should include a prototyping stage. It is at this point
that users can “play” with your ideas and concepts and give you valuable feedback that
shapes the final designs before you begin development. This can save time and money in
development and create products that offer significantly better user experiences than ones
that move from concept to production with no evaluative stages in between.
Prototyping is the act of creating a model of a product so that it can be tested by users before
you expend valuable development time on creating the actual product. In the sense we are
using it prototypes encompass everything from simple sketches of the product interface
right through to dynamic interactive computer models of the product and stopping at
wireframes on the way as an interim prototype.
The Good News

Prototyping for mobile apps has never been easier than it is today. There are numerous
software tools on the market that allow designers to quickly and easily create prototypes. In
fact, some of these packages are so easy to use that they may eliminate the use of sketches in
your prototyping procedures. Why hand draw when you can create screens, with a single
click, which mirror the mobile platform you are working on and then you just drag and drop
functionality in to them?
With that in mind we’re going to take a quick look at 5 of the most popular tools, today, for
creating prototypes for mobile app design.
5 Great Tools for Creating Mobile Prototypes
Balsamiq
Author/Copyright holder: Balsamiq. Copyright terms and licence: All rights reserved Img
source
Balsamiq’s strength is creating wireframes but there is a process by which you can create
simple interactive prototypes (it’s called “linking”) for demos and testing.
For those who love to sketch , Balsamiq, is the utility for you as the whole thing resembles a
simple whiteboard sketching area. However, there is a ton of community generated content
that you can import to rapidly improve the speed at which you create your content. You can
also grab some templates for iOS, Android and Blackberry functionality which is very handy.
Justinmind
Justinmind is a great prototyping tool which also includes simulations for things like gesture
control, tap and hold, swipe, etc.
As you build your wireframes, Justinmind creates the prototype, when you change a
wireframe model, the prototype immediately reflects this.
It also supports one of the widest ranges of mobile operating environments of any mobile
prototyping tools. There are pre-built “widgets” for these that are user generated and you
can design your own if you can’t find what you’re looking for in their library.
Moqups
Author/Copyright holder: Noupe. Copyright terms and licence: All rights reserved Img source
Moqups is completely free to use and one of the easiest tools to get started with immediately.
The interface is straightforward to get to grips with and they’ve produced a ton of pre-built
material to fill your designs with (including image placeholders, sliders, etc.)
There are phone templates and tablet templates too that come with UI elements associated
with those platforms.
Moqups only produces wireframes though; if you want interactivity – you’ll need to choose
a different platform for your prototypes.
Proto
Proto.io is a purely mobile prototyping platform. It allows you to quickly develop prototypes
(and simulations) that reflect the final product. There’s no coding required and it can be
accessed in almost any browser.
You create projects and manage them from a single screen. You use an editor to build the
prototype screens and the interactions between those screens and a player to deliver the
prototype. You can also create feedback when the player is in use and annotate screens to
your heart’s content.
You can also execute these prototypes on the devices themselves as long as they run iOS or
Android using a browser app (no cost).
UXPin
Author/Copyright holder: UX Pin. Copyright terms and licence: All rights reserved Img source
UXPin creates mockups and “clickable” prototypes for working online. It’s a very easy tool to
learn to use and there is some good use of UX design principles applied to the way the
software operates.
Prototypes created in UXPin can be used on multiple devices and be displayed in a range of
resolutions.
The software offers strong version control for iterating your designs. It also provides real-
time commenting, editing, etc.
15 More Really Popular Mobile App Prototyping Tools

If none of the options above suit your needs you can always try:
• Axure – the granddaddy of prototyping tools for corporate environments with

excellent mobile support.
• FlairBuilder – its strength is the speed at which you can iterate from low-fi to hi-fi
prototypes using a single click conversion.
• Fluid – with support for Android, iOS and Windows and lots of pre-built content for
your prototypes.
• HotGloo – very flexible and easy to use prototype creator with Apple stencils pre-built
for you.
• Invision – is not a mobile specialist platform but offers plenty of tools to get the job
done.
• iPhone Mockup – as you may have guessed this tool is for iPhone prototyping only
but it’s very simple to use and great for collaborative project working.
• iPlotz – simple creation tool for mockups and interactive wireframes. Great support
for Android and iOS templates.
• Mockflow – a quick to learn but sophisticated tool to build wireframes and interactive
mobile prototypes.
• Mokk.me – an easy to use platform but still in Beta, you’ll need to be patient if things
go wrong.
• Omnigraffle – great for wireframes and also great for creating diagrams. It’s very
similar to Adobe products in the way it works.
• Pencil Project – an open source prototyping tool with good functionality but it’s been
a while since there’s been a major update to the functionality.
• Pidoco – web-based and fantastic at creating clickable prototypes fast. Simulations
and tests run on devices without any need for installing additional software.
• Protoshare - a powerful way to create prototypes but with a little steeper learning
curve than some of the other options.
• Wireframe – it doesn’t get easier than this drag and drop utility to create wireframes
but it’s not the right tool for interactive prototyping.
• Wireframe sketcher – use as a standalone app or plug it into Eclipse IDE for additional
functionality.
Disclaimer
The Interaction Design Foundation does not use affiliate links and does not receive a
commission or any other form of payment from the companies mentioned above. Links are
provided to help you make the best decisions on tools for your projects only. We do not
endorse any particular product for any particular project and do not accept liability of any
kind for any choices of tool that you make.
The Take Away

Prototyping for mobile is easy if you have the right tools to hand to do the job with. The tools
above should get you pointed in the right direction but it is worth noting that new tools are
released regularly and that existing wireframing and prototyping software without specialist
mobile support may also be able to get the job done efficiently. Prototypes are invaluable for
testing ideas and iterations of a product in design prior to development commencing.
References
Hero Image: Author/Copyright holder: JustInMind1. Copyright terms and licence: Fair Use.
Test Your Prototypes: How to Gather Feedback and

Maximise Learning
Once you’ve built your prototypes based on the ideas you and your team generated, it’s time to
gather feedback from the people on whom you are testing these. Optimising how you gather
feedback — and, therefore, learn from your prototypes and users — is essential to help you save
time and resources in the Prototype and Test stages of the Design Thinking process – and in any
other human-centred design process. Being quick and efficient allows you to move rapidly from
creating a prototype, to putting it out to test it, to gathering feedback, and finally to creating a
new and improved iteration of your ideas. To maximise learning from your tests, we will share
six best practice tips on how to gather feedback, as well as three methods (with downloadable
templates!) on how you can organise your feedback.
Six Best Practice Tips for Gathering Feedback on Your

Prototypes
Gathering feedback is a crucial element in the Design Thinking process – and in all other
human-centred design processes. In order to maximise the benefits of gathering feedback,
however, you need to be purposeful about it. Here are some pointers to take note of when
thinking about gathering feedback from your users.
1. Ways to Solicit Feedback
How you solicit feedback from your users (or team-mates, if you are doing preliminary
testing with your prototypes within your team) depends largely on what type of prototype
you have built. For instance, if your prototype were a role-playing session, the experience of
acting out the roles would be a valuable source of observations and feedback in itself. On the
other hand, paper interfaces and physical models might require additional interviews with
users to get them to talk about their thinking process while using the prototype.
Nevertheless, there are some general rules of thumb you can rely on in order to solicit better
feedback. First, you can consider testing out several versions of your prototype on users
to gather feedback. This helps to solicit critical feedback — because people tend to hold back
on overtly criticising prototypes. When you present your users with alternatives, you allow
them to compare the various prototypes and tell you what they liked and disliked about each
version, and so you will get feedback that is more honest.
You can also consider using the “I Like, I Wish, What If” method to solicit honest feedback
in testing sessions. This method provides scaffolding for your users to voice their opinions
in a critical but positive manner. We will cover more on this method, and provide a
downloadable template for it, further down.
2. Test Your Prototypes on the Right People
Whom you test your prototypes on will affect the usefulness and relevance of their feedback.
If you are in the early stages of your design project and just want some simple and rough
feedback, testing prototypes on your team-mates would be good enough. Towards the end
of your project, when the prototypes get more detailed and closer to a final product,
however, you might want to consider testing on a wider range of users so as to get the most
relevant and helpful feedback.
Consider testing your prototypes on extreme users, on top of regular users. In order to
find extreme users, you will first need to define a dimension that is relevant to your
prototype. If you are working on an idea related to a supermarket, for example, your extreme
users could be people who shop at supermarkets every day, and — at the other end of the
scale — people who never shop at supermarkets. Testing your prototypes on extreme users
will often help you uncover some problems and relevant issues that affect regular users,
because the extreme users tend to be more vocal about their love (or dislike) of doing things
related to your prototype.
If your product or service is cross-regional or international, you should also test your
prototypes across regions and countries. Differences in cultures and customs might affect
how people living in different areas use your prototype.
Towards the final stages of your project, you should also get feedback on your prototypes
from stakeholders other than your users. Internal stakeholders in your company,
manufacturers, retailers and distributors will each have their own criteria for building,
making or shipping a product or service, and can have an impact on the success of your idea.
Gathering feedback from these stakeholders will thus prevent your team from receiving a
nasty shock when you realise that you won’t be able to implement the product or service you
have been developing as feasibly as you had believed.
3. Ask the Right Questions
Each prototype that you test should have a few core questions you want answered. Before
you test your prototypes and gather feedback, you should therefore be sure about
what exactly you are testing for. For instance, if you have built your prototype to gather
feedback about the usability of your product, then you should gear your testing session
towards teasing out how usable the prototype is to the user. Subsequently, in a post-testing
interview session with your user, you should then focus on finding out the positive and
negative feedback relating to usability.
Remember to keep an open mind when testing your prototypes, even though you have a
few core questions you want to focus on. Many times, testing sessions can reveal key points
on issues that your team did not even know to focus on. After testing, you should evaluate
the feedback and decide if there are new questions that you should ask during future testing
sessions.
4. Be Neutral When Presenting Your Ideas
When you present your prototypes to your users, try to be as objective as you can.
Highlight both the positive and negative aspects of your solution, and refrain from trying to
sell your idea. Remember that prototyping and testing is about finding ways to improve your
idea, and overly selling your idea can be detrimental to that goal.
When your users voice negative feedback about your prototype, refrain from trying to
defend it. Instead, probe them further to find out what exactly is wrong with your
proposed solution, so you can go back and improve your ideas. Avoid becoming too
attached to your idea, and always be ready to dismantle, change, or even abandon it when
the need arises. Remember, this stage is like a rehearsal, not the real “show”; you’re not being
cut to pieces in the marketplace — in fact, any careful corrections you can make that stem
from negative feedback will greatly help your chances of success later on.
5. Adapt While Testing
When you conduct tests on your prototypes, try to adopt a flexible mindset. For instance,
when you realise that certain components of your prototype are drawing attention away
from the core functions of the prototype, you can remove these or change them in order to
bring the focus back to the key elements of your idea. In addition, if you think that your
planned script for the testing session does not work well, feel free to deviate from it
and improvise during the testing session in order to get the best feedback from your
users.
6. Let the User Contribute Ideas
During your testing session, you should allow your users to contribute ideas that build on
your prototypes. You can ask your users how the product or service could be improved for
them, for instance. Doing so would encourage users to provide useful critiques as well as
help improve your solution.
You can also turn some questions that your users ask during the tests around, and ask the
users what they think. For example, if your user asks you how to charge an electronic
product, you can turn it around and ask them what would be the best charging method for
the product. Even if you do not adopt their ideas, their feedback would likely give you
insights about the key areas of concern that your users have while using your product or
service.
For your inspiration, you can go ahead and download our guidelines in this template: “Six Best
Practice Tips for Gathering Feedback on Your Prototypes”.
Three Methods for Maximising Learning from Testing

Gathering feedback from testing sessions can feel like a haphazard process. Thankfully, a few
methods are available which you can use to provide some structure and organisation to your
feedback-gathering process.
1. Feedback Capture Grid
A “Feedback Capture Grid” is a structured way of organising feedback that is gathered from
your testing sessions. You can use it during the test, as a way for you to capture feedback
from your users systematically, or after the test, when you need help organising the various
feedback you have gathered.
To start using a “Feedback Capture Grid”, divide a sheet of paper into four quadrants. Label
the top-left quadrant “Likes” — this will be where you will note down positive feedback. The
top-right quadrant is “Criticisms”, where you will capture negative feedback and criticisms
about the prototype. On the bottom-left quadrant is “Questions”, where you write down
questions that the users have asked as well as new questions the test session raised. Lastly,
label the bottom-right quadrant “Ideas”, where you take down any ideas that the testing
session had sparked. Try to make sure that each quadrant has at least a few notes. When
using the grid during a test session, for instance, you can steer the conversation towards
quadrants that are currently not receiving enough input.
To get help with starting, you can download our template on how to use the “Feedback Capture
Grid” method.
2. I Like, I Wish, What If
Like the “Feedback Capture Grid” method, the “I Like, I Wish, What If” method provides a
structure from which you can collect feedback from your users. Quite simply, the “I Like, I
Wish, What If” method invites the user (or your team-mates, during a discussion session) to
provide open feedback by coming up with three kinds of statements.
In “I Like…” statements, the user is encouraged to convey the aspects that he or she liked
about the prototype. This provides you with positive feedback about your prototype. In “I
Wish…” statements, users are prompted to share ideas of how the prototype can be changed
or improved so as to address some concerns or issues. This is an avenue to collect negative
feedback and constructive criticism. Lastly, in “What If…” statements, the user can express
new suggestions that might not have a direct link to the prototype. This opens up possibilities
for new ideas that your team can then explore in future iterations of prototypes.
One key advantage of the “I Like, I Wish, What If” method is that it frames the feedback that
someone is about to provide in a constructive and positive manner, enabling an open
discussion or absorption of his or her feedback. Rather than saying something like “This
feature sucks; why is this design even considered?”, users are framed to say something more
constructive, like “I wish you would change this part to…” and “What if you moved this…and
added…”.
Please feel free to download and print our template for the “I Like, I Wish, What If” method.
3. Sharing Inspiring Stories
Stories are powerful tools that you can use to inspire yourself and your team to think of
solutions. After doing a round of tests with your prototypes, getting together with the rest of
your team and sharing inspiring stories with one another is a very useful activity. Capturing
what resonates with you and your team-mates can help identify ideas and feelings that your
team can work on when thinking of new solutions.
Here’s how you can build on the power of stories to help you absorb and organise your tests
with users. One by one, you and your team-mates can share a couple of interesting and
inspiring stories you have observed while testing the prototype with users. Be as detailed as
possible, and take down notes and observations about the stories on Post-Its. Put up all the
Post-It notes on a wall; that way, when all participants have shared their stories, you have a
wall full of Post-It notes. You can then examine the stories you’ve shared and look for
common threads and possible insights about your users so as to translate the inspiring
stories into actionable next steps for the project.
To help you and your team get started, you can download our template for “Sharing Inspiring
Stories”
Build, Gather Feedback, Iterate

Absorbing feedback from your users through prototype testing is useless if you don’t put the
new information into use in your next iterations of prototype ideas. You need to develop a
habit with your team such that you actively integrate what you have learnt back into your
process, and consciously develop new iterations of your solutions as you move forward.
You can conduct a post-feedback discussion with your team to achieve this. First, you can
use the “Feedback Capture Grid”, “I Like, I Wish, What If”, or “Sharing Inspiring Stories”
method, and then gather and share the lessons you have learnt with your team. Next, start a
discussion on how to synthesise the feedback you have received. You can for example start
a brainstorming session to help generate ideas to integrate the feedback collected into your
prototypes. The next step is to go out there and create your next prototypes. Remember to
have a bias towards action! Keep iterating your prototypes by constantly testing and
integrating your findings, and eventually you will reach an optimal solution that addresses
most of the key areas of your user needs.
The Take Away

Gathering feedback on your prototype can be an exciting phase of your design project. It is
also an important phase, which you should try to optimise. Bearing in mind the six tips for
gathering feedback on your prototype — from testing on the right people to letting users
contribute their ideas — as well as using the three methods for getting honest feedback
(“Feedback Capture Grid”, “I Like, I Wish, What If”, and “Sharing Inspiring Stories”) will help
you maximise the amount of learning you get from testing your prototypes. Lastly, remember
to make it a habit to use the feedback you have gathered to build new and improved
prototypes, and keep working on that iterative process to move towards your final product
or service.

IDEO, Human-Centered Design Toolkit, 2009: https://www.ideo.com/work/human-
centered-design-toolkit/

IDEO, Integrate Feedback and Iterate: http://www.designkit.org/methods/4
IDEO, Share Inspiring Stories: http://www.designkit.org/methods/13
Hero Image: Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation.
Copyright terms and licence: CC BY-NC-SA 3.0
How to Get More Honest Feedback in User Testing

Many years ago, I was delivering a training course on products that would be introduced for
commercial sale in a telecoms environment. The information for that course had been
developed and provided by the product management team.
Taking this information on good faith, I went and delivered the course that they had
requested. Unfortunately for me, within minutes of starting delivery, it became apparent
that… well, the information I had been given didn’t match the reality of the business. I was
training people in abject nonsense.
At the end of the session, I explained that I was sorry for the content and that in order to be
able to go and revise the content before I delivered it again – I would need the participants
to say that the training hadn’t met their needs. Then I handed out feedback forms for those
participants. What happened? They all rated the training as excellent. Despite the fact that it
wasn’t. I knew it. They knew it. So why did they give me such good feedback?
This is an important question because it also relates to user testing. We’ve all watched a user
struggle with something in a test only to report that they found it incredibly easy when asked
about their experience at the end.
So what is it that leads people to give positive feedback even when that feedback is not
merited? And how can we avoid that to get better feedback?
People Don’t Want to Hurt Other People’s Feelings

That group I was training? They were people I knew. They didn’t want to give me bad
feedback, in part, because they thought it might be hurtful to me. This remained true even
when I’d told them, I wanted bad feedback.
This may be a big challenge to overcome in the classroom but it’s actually easier to do in the
user testing arena. You need to tell a small fib to your participants when you begin the testing
process. Explain that you are testing something for a third party and that you have no
relationship with that third party.
This means that they know that their feedback has no impact on you. They can’t hurt your
feelings because you’re not attached, in any meaningful way, to the product under test.
Author/Copyright holder: romana klee. Copyright terms and licence: CC BY-SA 2.0
People Often Assume That is Them Being Tested

Whether you’re saying; “Hey! I learned nothing useful in that training.” or “Hey! I found that
form a total PITA to complete.” It can lead to an assumption that you’re the one at fault. That
you’re the person being tested and not the training or the product.
Once again, if people think they’re under test – they’re going to give you different feedback
than if they’re testing the system. You’ll often hear; “I’m really sorry about that I just
blundered a little at that point.” as opposed to “It was really unclear what I was meant to do
at that point.”
So start your testing by explicitly stating; “We are not here today to test you. We are here to
test the system. We know this system has some issues. We need your help to identify those
issues.”
This helps the tester separate themselves from the test and sets them up to give honest
valuable feedback.
Author/Copyright holder: Dennis S Hurd. Copyright terms and licence: CC BY-NC-ND 2.0
People Often Focus on Completion Rather Than the Journey

In user testing there’s a certain sense of achievement that you have finished the test. (In the
same way that finishing a test at school made you feel good).
The trouble with this is that when people feel good, they tend to produce nothing but positive
feedback. Countering this requires a certain amount of additional effort. What you want to
do is walk them back through the process and collect feedback at each stage of the process.
Refer to your observations and bring up any issues that you saw them encounter on the way
through.
Push for a little more information and you’d be amazed at how quickly it’s forthcoming. Sure,
it means for a slightly longer test but it also means that you’re going to get actionable, useful
data rather than another meaningless pat on the back for a frustrating process.
People Can Show You More if You Let Them

You’re the expert and that’s why you’re conducting the tests. The assumption of your own
expertise can lead you to assume that you’ve picked up all pain points through observation.
This makes it less likely that you’ll ask your users to show you more.
Back when I started developing training, I had no real idea what I was doing. I knew that the
product was “fit for purpose” but I also knew it could be better. At the end of each day’s
session (it was a 2 week course), I would leave the room and give the group 15 minutes to
come up with 3 highlights of the day and 3 things they thought could have been improved
upon. The feedback that came out of those sessions was invaluable to finalizing the product
(and in fact after 3 run-throughs of the course, new groups could no longer think of any
improvements).
You have to ask; “How would you improve this product if you could?” at the end of a session
too. You won’t always get valuable input but you may find that you do.
Author/Copyright holder: Derek Bridges. Copyright terms and licence: CC BY 2.0
Summary
Getting better feedback out of users is a conscious process. It doesn’t require huge amounts
of effort to put processes in place to elicit better feedback.
You may also find that having a second observer or videoing the session can also extract
higher levels of feedback – reviewing or having a second pair of eyes can help pick up things
you missed that might have been obvious if you hadn’t have been focused on something else
at the time.
Heuristic Evaluation: How to Conduct a Heuristic

Evaluation
Learn to conduct a heuristic evaluation on any given user interface design. This article will
teach you how to generate and conduct your own heuristic evaluations so you can improve the
usability, utility, and desirability of your designs. The best practice is to use established
heuristics like Nielsen and Molich's 10 rules of thumb and Ben Shneiderman’s 8 golden rules as
a stepping stone and inspiration while making sure to combine them with other relevant design
guidelines and market research.
Nielsen and Molich's 10 User Interface Design Heuristics

Jakob Nielsen, a renowned web usability consultant and partner in the Nielsen Norman
Group, and Rolf Molich, another prominent usability expert, established a list of ten user
interface design guidelines in the 1990s. These heuristics have been reflected in many of the
products designed by some of the most successful companies in the world such as Apple,
Google, and Adobe. Note that there is considerable overlap between Nielsen and Molich's
heuristics and Ben Shneiderman’s 'eight golden rules'. These 10 rules of thumb further
iterate upon Shneiderman’s ideas 4 years after his initial publication.
• Visibility of system status. Users should always be informed of system operations

with easy to understand and highly visible status displayed on the screen within a
reasonable amount of time.
• Match between system and the real world. Designers should endeavor to mirror
the language and concepts users would find in the real world based on who their
target users are. Presenting information in logical order and piggybacking on user’s
expectations derived from their real-world experiences will reduce cognitive strain
and make systems easier to use.
• User control and freedom. Offer users a digital space where backward steps are
possible, including undoing and redoing previous actions.
• Consistency and standards. Interface designers should ensure that both the graphic
elements and terminology are maintained across similar platforms. For example, an
icon that represents one category or concept should not represent a different concept
when used on a different screen.
• Error prevention. Whenever possible, design systems so that potential errors are
kept to a minimum. Users do not like being called upon to detect and remedy
problems, which may on occasion be beyond their level of expertise. Eliminating or
flagging actions that may result in errors are two possible means of achieving error
prevention.
• Recognition rather than recall. Minimize cognitive load by maintaining task-
relevant information within the display while users explore the interface. Human
attention is limited and we are only capable of maintaining around five items in our
short-term memory at one time. Due to the limitations of short-term memory,
designers should ensure users can simply employ recognition instead of recalling
information across parts of the dialogue. Recognizing something is always easier than
recall because recognition involves perceiving cues that help us reach into our vast
memory and allowing relevant information to surface. For example, we often find the
format of multiple choice questions easier than short answer questions on a test
because it only requires us to recognize the answer rather than recall it from our
memory.
• Flexibility and efficiency of use. With increased use comes the demand for less
interactions that allow faster navigation. This can be achieved by using abbreviations,
function keys, hidden commands and macro facilities. Users should be able to
customize or tailor the interface to suit their needs so that frequent actions can be
achieved through more convenient means.
• Aesthetic and minimalist design. Keep clutter to a minimum. All unnecessary
information competes for the user's limited attentional resources, which could inhibit
user’s memory retrieval of relevant information. Therefore, the display must be
reduced to only the necessary components for the current tasks, whilst providing
clearly visible and unambiguous means of navigating to other content.
• Help users recognize, diagnose and recover from errors. Designers should
assume users are unable to understand technical terminology, therefore, error
messages should almost always be expressed in plain language to ensure nothing gets
lost in translation.
• Help and documentation. Ideally, we want users to navigate the system without
having to resort to documentation. However, depending on the type of solution,
documentation may be necessary. When users require help, ensure it is easily located,
specific to the task at hand and worded in a way that will guide them through the
necessary steps towards a solution to the issue they are facing.
Why You Should Evaluate Against Your Own Heuristics

Nowadays, designers are encouraged to establish their own design-specific heuristics to
evaluate their products, systems, websites, etc. Since Nielsen and Molich developed these
heuristics in the 1990s, technology has advanced and they are less attuned to many of the
products available in the market today. For instance, Nielsen and Molich's heuristics would
be too general to evaluate the usability of designs intended for online communities or mobile
devices where the working environment is constantly changing. However, the original
heuristics are still largely applicable in spite of the specific capabilities and constraints of
modern designs. Therefore, as a designer it’s crucial that you learn to incorporate Nielsen
and Molich’s heuristics into your designs as the first step.
Author/Copyright holder: StockSnap. Copyright terms and licence: Free to Use.
Then, instead of dictating the process with Nielsen and Molich’s heuristics, their 10 rules of
thumb should only generally be used to inform and inspire a designer’s and a company’s
development of their own specific heuristics. In combination with market research, other
design guidelines and requirements, using your company or product-specific heuristics will
better suit the design under scrutiny.
How to Generate and Conduct Your Own Heuristic Evaluation

Choosing and developing new heuristics is a task in itself; there are no fixed
recommendations, as each design presents its own set of different tasks, constraints,
functions, styles and other variables. However, most heuristic evaluations involve between
five and ten items, which are chosen on the basis of their applicability to the overall usability
of the system, website, application etc. being tested. Less than five heuristics might lead to a
lack of stringency when identifying potential problems and issues, but on the other hand,
more than ten may overburden the evaluator as they must analyze the design with all of
these heuristics in mind while the heuristics may also conflict with each other. Here’s how
you can get started in generating and conducting your own heuristic evaluation:
• Establish an appropriate list of heuristics. Use Nielsen and Molich's 10 heuristics

and Ben Shneiderman’s 8 golden rules as inspiration and stepping stone. Make sure
to combine them with other relevant design guidelines and market research.
• Select your evaluators. Make sure to carefully choose your evaluators. Your
evaluators should not be your end users. They should typically be usability experts
and preferably with domain expertise in the industry type that your product is in. For
example, an evaluator investigating a Point-of-Sale system for the restaurant industry
should have at least a general understanding of restaurant operations.
• Brief your evaluators so they know exactly what they are meant to do and cover
during their evaluation. The briefing session should be standardized to ensure the
evaluators receive the same instructions; otherwise you may bias their evaluation.
Within this brief, you may wish to ask the evaluators to focus on a selection of tasks,
but sometimes they may state which tasks they will cover on the basis of their
experience and expertise.
• First evaluation phase. The first evaluation generally takes around two hours,
depending on the nature and complexity of your product. The evaluators will use the
product freely to gain a feel for the methods of interaction and the scope. They will
then identify specific elements that they want to evaluate.
• Second evaluation phase. In the second evaluation phase, the evaluators will carry
out another run-through, whilst applying the chosen heuristics to the elements
identified during the first phase. The evaluators would focus on individual elements
and look at how well they fit in the overall design.
• Record problems. The evaluators must either record problems themselves or you
should record them as they carry out their various tasks to track any problems they
encounter. Be sure to ask the evaluators to be as detailed and specific as possible
when recording problems.
• Debriefing session. The debriefing session involves collaboration between the
different evaluators to collate their findings and establish a complete list of problems.
They should then be encouraged to suggest potential solutions for these problems on
the basis of the heuristics.
In a heuristic evaluation conducted by Jakob Nielsen in 1992, results showed different

evaluators identified different numbers and types of usability problems. Therefore, it is
highly recommended that multiple evaluators are employed in a heuristic evaluation to
ensure the highest possible detection rate so these usability problems can be solved before
the final design is produced. Nielsen suggests that between three and five evaluators is
sufficient because when the number of evaluators used increases, the number of problems
identified increases in turn.
The general consensus is that more is better, especially when the evaluators have different
skillsets (i.e. so the team is more likely to spot different usability problems), but financial and
time constraints will often determine the number of evaluators on a project. In consolation,
one or two evaluators are often sufficient in the early stages of development to identify the
majority of usability problems.
Author/Copyright holder: Nielsen Norman Group. Copyright terms and licence: All rights reserved. Img
The curve shows the proportion of usability problems identified increases as the number of
evaluators used increases.
Pros and Cons of Heuristic Evaluation

Like any suggested method in research and design, there are both pros and cons in the
usability inspection method of heuristic evaluation. Let’s examine a few of them:
Pros of Heuristic Evaluation

• Heuristics can help the evaluators focus their attention on certain issues
• Heuristic evaluation does not carry the ethical and practical issues/problems
associated with inspection methods involving real users.
• Evaluating designs using a set of heuristics can help identify usability problems with
individual elements and how they impact the overall user experience.
Cons of Heuristic Evaluation
• Choosing appropriate heuristics is extremely important; if the wrong set of heuristics
is employed, certain usability problems may be overlooked.
• Heuristic evaluation might be relatively time-consuming when compared to other
'quick and dirty' inspection methods, such as simple walkthroughs with a small
sample of users. Training evaluators takes about a week on average, not including the
time it takes to conduct the evaluations and debriefing sessions.
• Unlike cognitive walkthroughs, heuristic evaluation is based on preconceived notions
of what makes 'good' usability. However, this need not be seen as a negative point, as
heuristics are often based on the experiences of real users with hundreds of designs.
• Problems identified by evaluators can often be false alarms. For example, in the article
‘Usability testing vs. heuristic evaluation: A head-to-head comparison’ by Bailey et al.,
it was stated that 43% of 'problems' identified in three heuristic evaluations were not
actually problems. Furthermore, of the usability problems recorded by the
evaluators, only 33% could be classified as genuinely problematic characteristics of
the designs. In addition, only 21% of genuine usability problems were identified;
calling into question the strength and usefulness of findings from heuristic
evaluations.
The Take Away

Generating your own heuristics is an important skill to have. Utilizing both Jakob Nielsen and
Rolf Molich’s heuristics as well as your own when evaluating interface design will guide you
and your team in creating better experiences for your users. Heuristic evaluation can be a
useful inspection method; however, some experts have identified issues with evaluators
reporting false alarms, rather than genuine problem elements within designs. To limit the
affect misreporting has on the applicability of findings from heuristic evaluation, it helps to
use a number of different evaluators, collate their problems and carry out a debriefing
session to root out false alarms at various stages in the design process.
Where To Learn More

To see more information on Jakob Nielsen’s ‘How to Conduct a Heuristic Evaluation’ please
see:
https://www.nngroup.com/articles/how-to-conduct-a-...
To see more information on Jakob Nielsen’s ‘Enhancing the Explanatory Power of Usability
Heuristics’ please see:
https://static.aminer.org/pdf/PDF/000/089/679/enha...
To see more information on Bailey et al.’s article, please see:
http://www.humanfactors.com/newsletters/heuristic_...
References
Hero Image: Author/Copyright holder: Sarah B Brooks. Copyright terms and licence: CC BY 2.0
Unmoderated Remote Usability Testing (URUT) -

Every Step You Take, We Won’t Be Watching You
Unmoderated Remote Usability Testing (URUT) is a technique designed to help you

overcome the downsides of moderated usability testing. While moderated usability testing
is undeniably useful it suffers from the fact that it’s time consuming, it takes a lot of effort to
recruit participants, the costs (due to all that time input) are usually too high to conduct
moderated testing with large numbers of users and users are observed outside of their usual
environment (which may change their behaviours).
About URUT
URUT is designed for usability testing for products or interfaces. That means it measures
how satisfied (or not satisfied) a user is with the interface and operability of the product.
The idea is that participants will work through a task (or tasks) in their usual environment
without the need for a moderator to be present. These tasks are presented to the user via an
online platform.
Data is captured from URUT in one of two ways. The first is via click-stream and in this
instance URUT often resembles a survey and captures quantitative data for researchers. The
second is via video and will provide a more qualitative insight into user behavior.
Click-stream offers fast data capture and easy analysis but video offers deeper insight into
user behavior. It is possible to combine the two approaches but the tests need careful design
to benefit from this approach.
Author/Copyright holder: Frits Ahlefeldt-Laurvig. Copyright terms and licence: CC BY-NC-ND
2.0
It’s definitely easier to involve a user in Unmoderated Remote Usability Testing than it is to get
them involved in lab moderated testing.
When Should I Use URUT Rather than Moderated Testing?

A lot depends on the needs of your usability tests but some of the more common scenarios
include:
• Competitor benchmarking. URUT makes it easy to examine two different products

and capture enough data to make informed decisions based on the differences
discovered.
• Budget constraints. URUT is cheaper than moderated testing – if you don’t have the
money for the latter the former may be a better approach.
• Tight deadlines. If you need the data in a hurry it’s much faster to set up URUT than
moderated testing.
• Geographical constraints. If you want to test a global (or widely-dispersed)
audience then URUT is likely to be easier and cheaper to implement (by far) than
moderated testing.
• In the wild data. If the customer’s environment has a large influence over use then
moderated testing is probably not the way to go.
• Large sample sizes. Without the need for moderation – automated remote testing
can be scaled to deliver statistically significant data from the user base. Though it’s
worth remembering that Steve Krug, the usability expert says; “Testing one user is
100 percent better than testing none.”
Author/Copyright holder: Cosmocatalano. Copyright terms and licence: CC0 1.0
When you’re trying to save money – don’t forget the quality triangle for good project results.
Considerations for Running URUT

There are many considerations to developing and running URUT for your products and some
will be specific to your own needs but there are some general considerations for URUT too:
Prior to URUT
As with all forms of research; you need to be clear about the objectives or your research and
what questions you expect to answer with the research. You can work with stakeholders to
develop this understanding.
Participants
You’re also going to need to work out how to get people to take part in the study; your options
include:
• E-mail. If you have a list of customer e-mail addresses you can e-mail them to ask
them to take part.
• Pop-ups. If your customers are on your website; you can use a pop-up to redirect
them to the study. The advantage of this approach is that you’re likely to get a very
representative sample but the disadvantage is that it may distract them from
shopping or other more valuable business activity.
• Accessing pre-built testing databases. You can pay to access other people’s testing
databases if you don’t have your own. These resources can often be targeted quite
specifically to ensure representative audiences.
• Social media. There’s nothing wrong with asking for volunteers on your social media
channels either (if they’re active enough).
Author/Copyright holder: Jason Howie. Copyright terms and licence: CC BY 2.0
Assuming you have a large following on social media, it can be a great way to get participants
involved in your URUT.
You may also need to offer participants an incentive to take part. The less involved the
participant is with the product/service – the more of an incentive it usually takes to get them
on board.
Task Design
You’ll need to be very clear about the tasks that participants are expected to complete. You
must offer enough detail that they can do this without assistance (and you may need dummy
data to supply them with too – such as credit card data for a mock purchase).
Keep instructions as simple and minimal as possible and always include a call-to-action
when necessary.
Survey Questions
You can also include survey questions in an URUT exercise:
• Closed questions following each task can help measure how participants are feeling
about the usability of that task.
• Questions can be used at the end of the exercise to get a more general impression of
the exercise.
• Questions can also be used to derive demographic data.
• Questions can also be used to test comprehension of content.
Author/Copyright holder: JayWalsh. Copyright terms and licence: CC BY-SA 3.0
Survey questions can provide additional insight into emotions or even unrelated topic areas
during URUT. Wikipedia uses surveys, as seen here, to gauge how its editors feel about their
work.
Delivery of the URUT Tool
Make sure that the tool is easy to access and to get to grips with without any support. You
don’t want to introduce barriers to entry for participants.
Pilots
It can be very useful to test an URUT with a small number of participants and then evolve the
URUT before launching it with a large audience.
Support
You should offer some telephone or e-mail support to participants for both the URUT
exercise and if they have any questions after it has been completed.
Analysis
Once the URUT is complete – you need to analyze the data collected. You can apply any
qualitative or quantitative technique that you require to get a clear understanding of results.
It can be useful to define some headline metrics and measure these first to give quick results
back to stakeholders.
The Take Away

URUT (Unmoderated Remote Usability Testing) can be a useful replacement for moderated
usability testing in certain circumstances. The technique should be used with careful thought
and have clear objectives before being employed. It’s an excellent addition to a usability
tester’s or UX designer’s toolkit.
Resources
The Nielsen Norman Group offers some good tips on choosing URUT tools
- https://www.nngroup.com/articles/unmoderated-user-testing-tools/
UX Matters examines the case for and against URUT here

- http://www.uxmatters.com/mt/archives/2010/01/unmoderated-remote-usability-
testing-good-or-evil.php
Hero Image: Author/Copyright holder: leisa reichelt. Copyright terms and licence: CC BY-SA 2.0
From Prototype to Product: Ensuring Your Solution

is Feasible and Viable
The end goal of a Design Thinking work process is to create a solution that is desirable, feasible,
and viable. This means that your product or solution should not only satisfy the needs of a user
but be easy to implement and have a commercial model as well. During the bulk of your Design
Thinking work process, desirability would be at the forefront, as you are concerned with testing
your ideas and validating your hypotheses about your users. Towards the end of your project,
however, you should bring the focus to feasibility and viability as well so that your solution can
be sustainable. Let us now look at the best ways you can make sure that your design solution is
feasible and viable, on top of being desirable to your users.
From Prototyping and Testing to Thinking about Feasibility
The feasibility of your solution is about whether or not you are able to implement your
solution in an effective manner. It not only affects your company’s operations as it seeks to
implement your product or service, but it also impacts your users’ experiences in a direct
way. Consider, for instance, how your retail distribution network will affect where your
users will have to go in order to get access to your product or service.
To start thinking about the feasibility of your solution, you can focus on three main areas
that impact implementation: the distribution channels, the capabilities you need for pulling
off the solution and the potential relationships you can form with external partners. You
should think about these three factors for each of your solutions, and organise an exercise to
discuss them with your team-mates.
How Will Your Solution be Distributed?
To start thinking about the distribution channels of your solution, discuss with your team
the possible ways your users can experience the solution. Where would they go? When and
how would they experience the product or service? Why would the user want to gain access
to your product? From these questions, think of as many alternative distribution and
delivery possibilities as possible.
Make a list of all the potential people who — as well as channels that — will be involved in
delivering the solution to your users. If you are sending your product to your users, for
example, should you use the governmental postal office, engage with private courier
services, or hire your own deliverymen? If your solution is for hospital patients, will a doctor
or a nurse administer it? Are there other channels, conventional or unconventional, that you
might use to deliver your solution?
After you and your team have come up with a list of possible delivery methods, you should
then think of the pros and cons of each method. By thinking through the user experience and
weighing the benefits and costs of each distribution channel, you should have a clearer
picture of which ones are the most promising.
What Capabilities Do You Need for Creating and Delivering Your Solution?
Make a list of the various capabilities you will need for creating and delivering your solution
to users. Include all the manpower, manufacturing, financial and technological capabilities
that are necessary. For each capability, note down whether they exist in your organisation.
If they do, think about how you can see your solution added to your organisation’s workflow
and resource pool. If not, make a list of potential external sources of these capabilities in
organisations and networks you can tap on. Also, consider if your organisation should build
up its capabilities, either to augment existing ones or to add new ones so as to create and
deliver your solution.
With Whom Can You Partner Up?
If some of the capabilities you require are lacking in your organisation, make a list of
potential partners you can tap on to provide those capabilities. Examine if there are existing
relationships between your organisation or company and external companies that might be
useful in this respect. Are there any governmental grants or programs you can tap on to
partner up with service providers? Think of the various ways your company can engage with
external partners — and keep in mind the various business and legal interests at stake.
From the list of potential partners, try to narrow down to a few most promising choices. You
may need to involve stakeholders in your organisation to do so. Finally, think of the first
steps that your design team can take in starting to reach out to these potential partners.
Ensuring the Viability of Your Solution
The commercial viability of your product or service is an important factor that affects its
sustainability and long-term success. This is true even for non-profit organisations and
projects, because commercial viability will ensure that your solution will continue to work
even without constant inflow of funding from donors or governments.
To conduct an evaluation of your solution’s viability, you should analyse the value
proposition your product or service provides, think of potential revenue sources, and
consider various stakeholder incentives you can use.
What is the Customer Value You Provide?
Together with your team, think of the value that your solution provides to users. Does it
provide more convenience to your customers, therefore helping them save time? Or does it
provide security or safety that previously did not exist in a task? You can refer to your
prototypes and notes that you have taken down in past testing sessions with users to find
out what elements of your solution they find the most important or useful.
Next, try to figure out how much your users will pay for the value your solution provides.
You may rely on past prototyping and empathy-gaining sessions with users, which may shed
some light on how much they are willing to spend. Alternatively, you can consult experts or
internal stakeholders who may have a better idea of how much your solution is worth.
What are Your Revenue Sources?
Depending on whether your solution is a product or service, or a mixture of both, it can have
different sources of revenues. Together with your team, identify all the actors that will pay
for the solution. How much will each actor pay for the product or service? For instance, if you
are working with the government to implement a new service to people in need, will the
government be paying for the full cost, or will the end users co-pay a portion of the price?
Also, think about how the payment will be made. Depending on the industry conventions,
the country you are delivering your solutions to, and the needs of the users, you may want
to accept cash, credit, or payment in kind for your solution. Besides the payment mode, you
should also think about the most appropriate payment structure for your solution. Examples
of possible payment structures include the following:
• Membership, where users pay a regular fee (monthly, yearly, etc.).

• Commission, where you earn a percentage of transaction fees enabled by your
solution. (You can earn commission from the user or the user’s customer, or both.)
• Give the product but sell the refill, to encourage adoption of your solution and earn
revenue once users become repeat customers.
• Subsidise the price of the solution, possibly in collaboration with the local
government.
• Pay-per-use, where you charge a fee for every time a customer uses your solution.
What Incentives Does Each Stakeholder Possess?
Identify all stakeholders whom your solution will affect. Discuss with your team if the
solution provides value to each stakeholder involved. On the other hand, does your solution
increase the costs to some stakeholders?
Go through each stakeholder, and find out if they have any incentives or disincentives to
adopt or help you with your solution. For instance, if your solution helps supermarket goers
get even more value while shopping, would adopting your solution create a disincentive for
supermarkets? Consider how the proliferation of private-hire cars via companies such as
Uber and Lyft has prompted strong lobbying by the taxi industries in many countries, and
how it can impact the profitability of Uber and Lyft. Would your solution face similar
problems from stakeholders who would be disincentivised to help you? If disincentives exist
for stakeholders, try to think of ways in which you can tweak your product in order to
encourage their participation.
Test It Out: Launch Live Prototypes and a Pilot

Launch Live Prototypes
After you and your team have gone through assessing the feasibility and viability of your
solution, you may want to go ahead and launch a live prototype to test your solution in the
market. As designers, we use live prototypes to test our solutions in real-life environments
and conditions. Doing so allows you to test for the feasibility and viability of your product or
service.
To begin with live prototypes, you should determine what aspect of your solution you want
to test. For instance, you could focus on the distribution model of your solution... or getting
users to know about your product or service. This works similarly to a normal prototype,
where the first step is always to determine what needs to be tested. If you have many areas
of your solution you would like to stress test, or have more than one idea to test, you can
consider launching multiple live prototypes at the same time; however, that would require
more resources.
After you have a firm idea of what to test, you will then need to lay out the logistics behind
your live prototype. Remember that you need to use live prototypes in real-life conditions.
As such, you may need to rent some space, get materials to build a kiosk, or apply for
government approvals and licenses or permits if the need arises. If your solution is a service,
you may need to create uniforms and hire service personnel.
After you have figured out your logistical plan for the live prototype, launch it. Live
prototypes can last for days or weeks, depending on your needs. During the live prototype
launch period, be sure to take down notes and user feedback that you have gained, and do
this continually. If there are areas that went wrong, try to improve them during the live
prototype testing period, and see if the improved iteration works better. Keep gathering
feedback, iterating your prototype, and then testing to see if it works.
At the end of the live prototype, gather all the useful feedback you have gained from users
and other people involved in the process. By now, you should have a good feeling as to
whether or not your solution satisfies the three parameters of desirability, feasibility and
viability. When you feel confident in your solution (perhaps after a few runs of live
prototypes), you are ready to launch a pilot of your product or service.
Conduct a Pilot of Your Solution
While live prototypes are about testing aspects of your solution in real-life conditions, pilots
are about testing the entire system of your solution. It is a small step away from fully
launching your solution into the market, and it should give you a very firm idea of whether
the solution would work in the long term. When you launch a pilot, you are testing if each
component involved in creating and delivering the system works well with other
components, and if the entire scale of operations can run smoothly.
The first step in launching your pilot is to make sure you have a well thought-out logistical
plan for your product or service. Consider all the parties involved — manufacturers,
distributors, retailers, etc. — as well as pertinent aspects, such as legal considerations. If your
solution is involved with food products, for instance, you may need to apply for a food permit.
Next, consider your marketing plan. While Design Thinking might not sound compatible with
marketing, the success of your solution is going to rely heavily on sound marketing.
Brainstorm and strategise on how to market the values of your product or service to
potential customers. Compare your solution against the existing offerings in the market, and
list down the key competitive advantages you have. You can use insights about your users’
motivations and emotions you uncovered during the Empathise stage of your project to help
you identify the best ways to target and engage your potential customers. At this point, it is
also useful to think about the various metrics that you should be keeping track of during the
pilot program.
When you have nailed your logistical and marketing plan, you can launch your pilot. Collect
feedback from users and other parties involved to figure out what is working and what isn’t.
You can make changes to your product or service during the pilot phase, but, ideally, the
number of tweaks should be kept at a minimum, because the point of a pilot is to let you
know which parts of the system areworking... and which aren’t. Having too many changes
might make it difficult to tell whether the system is working; indeed, any scientist will tell
you that changing more than one variable in an experiment will cause confusion. Your pilot
can last for months as you test both your solution and how it reacts with real-life market
forces.
If your pilot is a success — congratulations! Your solution is ready for shipment to the
market!
Formulate a Learning Plan to Combine Analysis and Synthesis
Throughout the Design Thinking process, learning plays a central role in enabling you to
create solutions that target the needs of your users. As you begin to implement your
solutions after a successful pilot run, you should continue to keep learning a key part of your
organisation. After all, Design Thinking is a long-term process that will continually help you
improve your offerings.
After your product or service launches, you and your team should continue collecting stories
from users and gathering their feedback about your solution. You can compare the stories
you have collected at the early stages of your project with those collected after the project
has launched. Doing so will show you the changes that your solution has made on people’s
lives. The feedback you gather will also help you constantly improve the product or service
to meet the needs of your users.
This all ties back to the constant switch between analysis and synthesis that we as design
thinkers have to perform. In analysis, you collect data and break down the different parts of
your ideas or users in order to gain a fine-grain picture of the problems you are trying to
solve. Conversely, in synthesis, you look at all the notes you have taken and then try to
find patterns and themes that will help you generate new ideas and solutions. By actively
collecting stories and feedback after your solution has launched, you are performing an
analysis of your solution’s performance. Using this information, you can then synthesise and
come up with ways to iterate your product or service.
To augment your learning plan and help with your analysis and synthesis, you can also track
indicators relevant to your solution as well as the outcomes of your product or service.
Tracking the key performance indicators will allow you to have a measure of whether your
solution is performing up to expectations. You can track indicators such as the awareness of
your solution or the level of engagement with users.
Before you track the outcomes of your product or service, you first have to identify the
relevant stakeholders involved. Together with your team, try to define what success would
look like for the different stakeholders. With this in mind, develop a plan to monitor the
outcomes for each stakeholder, and use this information to feed into the next iteration of
your product.
Adopt the mindset that your Design Thinking project is an iterative, cyclical process: the
outcomes of a product or service that you launch will become the starting points of a new cycle
of analysis and synthesis. Learn, improve, and make the world a better place.
The Take Away
In most of your Design Thinking project, you will be primarily concerned with the
desirability of your solution — whether or not it meets the needs of your users. However,
towards the end stages, you will need to focus on feasibility and viability as well. Think about
your solution’s feasibility by considering the distribution channels, capabilities you require,
and your potential partners. Evaluate your viability by thinking about the kind of value you
provide to your users, your potential revenue sources, and the incentives for your
stakeholders. Finally, conduct live prototypes to test your solution in real-world conditions,
and then launch a pilot to test the entire system behind your solution. Always try to keep
learning a vital part of your organisation — by noting down user stories and feedback as well
as tracking key performance indicators and outcomes.

IDEO, Live Prototyping: http://www.designkit.org/methods/18
IDEO, Pilot: http://www.designkit.org/methods/8
IDEO, Human-Centered Design Toolkit, 2009: https://www.ideo.com/work/human-

centered-design-toolkit/
Hero Image: Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation.
Copyright terms and licence: CC BY-NC-SA 3.0

Lesson Prototyping DT LRP

Uploaded by

Copyright:

Available Formats

Lesson Prototyping DT LRP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lesson Prototyping DT LRP

Uploaded by

Copyright:

Available Formats

Lesson Prototyping-DT-LRP

6.1: The Key Benefits of Prototyping

References & Where to Learn More

Design Thinking: Get Started with Prototyping

What went wrong?

A prototype is a simple experimental model of a proposed solution used to test or validate

Why We Need to Prototype

Design Thinking is a design methodology that provides a solution-based approach to solving

Some of the purposes that prototypes fulfil are:

Exploring and Experimentation

Learning and Understanding

Engaging, Testing, and Experiencing

Inspiring and Motivating

How Prototyping Works

The Take Away

PLEASE ANSWER THE FOLLOWING QUESTIONS

Prototyping in Design Thinking: How to Avoid Six

Solution: Explore a Range of Different Approaches First

2nd Pitfall: Falling in Love with Your Prototypes

3rd Pitfall: Wasting Time Explaining and Pitching

Solution: Have a Bias Towards Action

4th Pitfall: Prototyping Without a Purpose

Solution: Have a Question in Mind

5th Pitfall: The Failure Roadblock: Feeling Discouraged by

"Fail faster, succeed sooner."

6th Pitfall: Seeing Prototypes as a Waste of Time

Solution: Adopt a Long-Term View

The Take Away

References & Where to Learn More

What Kind of Prototype Should You Create?

• Low fidelity – low cost, rough and quick to build

Author/Copyright holder: Samuel Mann. Copyright terms and licence: CC BY 2.0

Paper interfaces are an example of low-fidelity prototypes.

When to Use Low-Fidelity Prototypes

Author/Copyright holder: Dereckson. Copyright terms and licence: CC BY 3.0

When to Use Medium-Fidelity Prototypes

High-fidelity prototypes aim to provide the closest representation of the idea

When to Use High-Fidelity Prototypes

Prototyping for Empathy

“Prototyping is the conversation you have with your ideas.”

The Take Away

References & Where to Learn More

Prototyping: Learn Eight Common Methods and

Sketches and Diagrams

Author/Copyright holder: Tom Maiorana. Copyright terms and licence: CC BY 2.0

Sketching is a valuable method of prototyping because you can do it practically everywhere,

“A stitch in time saves nine.”

A commonly used process in creating paper interfaces is sketching and assembling

The purpose of a physical model is to bring an intangible idea, or two-dimensional sketch,

Which Prototype Should I Build?

• What’s your idea about?

The Take Away

References & Where to Learn More

Lego Serious Play: http://www.lego.com/en-us/seriousplay

IDEO, Determine What to Prototype: http://www.designkit.org/methods/34

Don’t Build It, Fake It First – Prototyping for Mobile

The Good News

15 More Really Popular Mobile App Prototyping Tools

• Axure – the granddaddy of prototyping tools for corporate environments with