Unit 5 IDT

Download as pdf or txt
Download as pdf or txt
You are on page 1of 53

ES IG N

N D FO
IO U
T

N
C

DA
Join us
RA

TIO
INTE

N
Est. 20 0 2

Get a FREE Copy of Don Norman’s latest eBook

Define and Frame Your Design Challenge


by Creating Your Point Of View and Ask
“How Might We”
by Rikke Friis Dam and Teo Yu Siang | 몭 years ago | 몭몭 min read

몭,몭몭몭
shares

De몭ning your design challenge is probably one of the most important steps in the Design
Thinking process, as it sets the tone and guides all of the activities that follow. In the De몭ne
mode, you should end up creating an actionable problem statement which is commonly
known as the Point of View (POV) in Design Thinking. You should always base your Point
Of View on a deeper understanding of your speci몭c users, their needs and your most
essential insights about them. In the Design Thinking process, you will gain those insights
from your research and 몭eldwork in the Empathise mode. Your POV should never contain
any speci몭c solution, nor should it contain any indication as to how to ful몭ll your users’
needs in the service, experience, or product you’re designing. Instead, your POV should
provide a wide enough scope for you and your team to start thinking about solutions which
go beyond status quo. Here, you’ll also learn to frame and open up your Point Of View,
which is the axis that Design Thinking revolves around – a challenge well-framed is half
solved.

"Your point of view should be a guiding statement that focuses on speci몭c users, and
insights and needs that you uncovered during the empathize mode.

More than simply de몭ning the problem to work on, your point of view is your unique
design vision that you crafted based on your discoveries during your empathy work.
Understanding the meaningful challenge to address and the insights that you can
leverage in your design work is fundamental to creating a successful solution.”
– d.school, Bootcamp Bootleg

Your POV is Your Guide


Your Point of View (POV) de몭nes the RIGHT challenge to address in the following
mode in the Design Thinking process, which is the Ideation mode. A good POV will
allow you to ideate and solve your design challenge in a goal-oriented manner in
which you keep a focus on your users, their needs and your insights about them.

You should construct a narrowly-focused problem statement or POV as this will


generate a greater quantity and higher quality solutions when you and your team
start generating ideas during later Brainstorm, Brainwriting, SCAMPER and other
ideation sessions. In the ideation process, POV will be your guiding statement that
focuses on insights and needs of a particular user, or composite character. It’s easy to
get lost in the ideations sessions if you don’t have a meaningful and actionable
problem statement to help keep your focus on the core essence of your research
results from your previous work. A great POV keeps you on track. It helps you design
for your users and their needs. If you neglect to de몭ne your POV, you may end up
getting lost in the ideation processes and in your prototyping process. It’s all too
easy to end up focusing on you and your company’s own needs, trying to ful몭ll your
and your company’s own dreams, not to mention the risk of getting lost in creating
amazing buttons in the beautiful colours. It’s time to 몭nd out how you de몭ne your
POV.

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright


terms and licence: CC BY-NC-SA 3.0

How do you Define your Point Of View?


Step 몭
De몭ne the type of person you are designing for – your user. For example, you could
de몭ne the user by developing one or more personas, by using a몭nity diagrams,
empathy maps and other methods, which help you to understand and crystallise
your research results – observations, interviews, 몭eldwork, etc.

Select the most essential needs, which are the most important to ful몭ll. Again,
extract and synthesise the needs you’ve found in your observations, research,
몭eldwork, and interviews. Remember that needs should be verbs.

Work to express the insights developed through the synthesis of your gathered
information. The insight should typically not be a reason for the need, but rather a
synthesised statement that you can leverage in your designing solution.

Step 몭
Write your de몭nitions into a Point Of View template like this one:

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright


terms and licence: CC BY-NC-SA 3.0

Your Point Of View template:

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright


terms and license: CC BY-NC-SA 3.0

Step 몭 – POV Madlib


You can articulate a POV by combining these three elements – user, need, and
insight – as an actionable problem statement that will drive the rest of your design
work. It’s surprisingly easy when you insert your 몭ndings in the POV Madlib below.
You can articulate your POV by inserting your information about your user, the needs
and your insights in the following sentence:

[User . . . (descriptive)] needs [Need . . . (verb)] because [Insight . . . (compelling)]

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright


terms and license: CC BY-NC-SA 3.0

Condense your Point Of View by using this POV Madlib.

Example: An adult person who lives in the city… needs access to a shared car 1-4
times for 10-60 minutes per week … because he would rather share a car with more
people as this is cheaper, more environmentally friendly, however, it should still be
easy for more people to share.

Author/Copyright holder: Sam Churchill. Copyright terms and license: CC BY 2.0

You articulate a POV by combining these three elements – user, need, and insight – as an
actionable problem statement that will drive the rest of your design work. An example
could be: “A person who lives in the city… needs access to a shared car 1-4 times for 10-60
minutes per week … he would rather share a car with more people as this is cheaper, more
environmentally friendly, and it should still be easy for more people to share.” Here you
see one of Google’s driverless cars – a driverless electric car could be a part of the solution
to this design challenge. However, at this stage of the design process, we’re not ready to
look for solutions just yet.

Step 몭 – Make Sure That Your Point Of View is One That:


Provides a narrow focus.

Frames the problem as a problem statement.

Inspires your team.

Guides your innovation e몭orts.

Informs criteria for evaluating competing ideas.

Is sexy and captures people’s attention.

Is valid, insightful, actionable, unique, narrow, meaningful, and exciting.

Yay! You’re now well-equipped to create a POV and it’s time to understand how to
start using your POV which crystallizes all of your previous work in the Empathise
mode.
You can download and print the Point Of View template here:

Get Your Free Template For “Point Of View ­ Problem


Statement”

Name Secure form

Email

We respect your privacy

Get free UX design learning material every week

Download free template

“How Might We” Questions Frame and Open Up


Your Design Challenge
You start using your POV by reframing the POV into a question: Instead of saying, we
need to design X or Y, Design Thinking explores new ideas and solutions to a speci몭c
design challenge. It’s time to start using the Design Thinking Method where you ask,
“How Might We…?”

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright


terms and license: CC BY-NC-SA 3.0

When you’ve de몭ned your design challenge in a POV, you can start opening up for
ideas to solve your design challenge. You can start using your POV by asking a
speci몭c question starting with, “How-Might-We?” or “in-what-ways-might-we?”.
For example: How might we… design a driverless car, which is environmentally
friendly, cheap and easy for more people to share?
How Might We (HMW) questions are the best way to open up Brainstorm and other
Ideation sessions. HMW opens up to Ideation sessions where you explore ideas that
can help you solve your design challenge. By framing your challenge as a How Might
We question, you’ll prepare yourself for an innovative solution in the third Design
Thinking phase, the Ideation phase. The How Might We method is constructed in
such a way that it opens the 몭eld for new ideas, admits that we do not currently know
the answer, and encourages a collaborative approach to solving it.

For example, if your POV is:

“Teenage girls need… to eat nutritious food… in order to thrive and grow in a healthy
way.“

The HMW question may go as follows:

How Might We make healthy eating appealing to young females?

How Might We inspire teenage girls towards healthier eating options?

How Might We make healthy eating something, which teenage girls aspire towards?

How Might We make nutritious food more a몭ordable?

These are simple examples, all with their own subtle nuances that may in몭uence
slightly di몭erent approaches in the ideation phases. Your HMW questions will ensure
that your upcoming creative ideation and design activities are informed with one or
more HMW questions, which spark your imagination and aligns well with the core
insights and user needs that you’ve uncovered.

“We use the How Might We format because it suggests that a solution is possible and
because they o몭er you the chance to answer them in a variety of ways. A properly framed
How Might We doesn’t suggest a particular solution, but gives you the perfect frame for
innovative thinking.”
– Ideo.org

How Might We?


The How Might We question purposely maintains a level of ambiguity, and opens up
the exploration space to a range of possibilities. It's a re-wording of the core need,
which you have uncovered through a deeper interrogation of the problem in your
research phase, the Empathise mode in Design Thinking – and synthesized in the
De몭ne mode in Design Thinking.

"How" suggests that we do not yet have the answer. “How” helps us set aside
prescriptive briefs. “How” helps us explore a variety of endeavors instead of merely
executing on what we “think” the solution should be.

"Might" emphasizes that our responses may only be possible solutions, not the only
solution. “Might” also allows for the exploration of multiple possible solutions, not
settling for the 몭rst that comes to mind.

"We" immediately brings in the element of a collaborative e몭ort. “We” suggests


that the idea for the solution lies in our collective teamwork.

Without a statement of a clear vision or goal, “How Might We” is obviously


meaningless. The words require a well-framed objective, a POV, which is neither too
narrow so as to make it overly restrictive, nor too broad so as to leave you wandering
forever in in몭nite possibilities.

An Inspiring HMW example


David and Tom Kelley's book Creative Con몭dence has the story of the Embrace
Warmer, a design challenge undertaken by Stanford Graduate Students aimed at
solving the problem of neonatal hypothermia, which costs the lives of thousands of
infants in developing countries every year. Faced with the situation where hospital
incubators were too expensive as well as physically inaccessible to villagers who lived
in rural settings, a team of students engaged in some Empathy research, which led
them to formulate the HMW statement:

"How Might We create a baby warming device that helps parents in remote villages give
their dying infants a chance to survive?"

This HMW question inspired the design of the Embrace Warmer sleeping bag device,
which provides the warmth premature babies in rural villages need, and which they
are able to access at a fraction of the cost of traditional hospital incubators.
Whilst a traditional approach may have resulted in technological attempts to reduce
the cost of the incubator, empathic research revealed that one of the core issues was
the inability or unwillingness of mothers to leave their villages or leave their babies
at hospitals for extended periods. This resulted in the reframing of an incubator to a
warming device.

Author/Copyright holder: Embrace Innovations. Copyright terms and license: Fair Use.

Expand on Your How Might We Questions


Marty Neumeier's Second Rule of Geniusis all about framing and opening up your
Point Of View by helping us dream of wishing for what we want. To start wishing, ask
yourself the kinds of questions that begin with:

How might we...? (This is the commonly structured framing phrase used to express
the essence of the challenge at hand.)

In What Ways Might We…. (Expand on HMW to add the possibility of multiple ways.)

What's stopping us from...?

In what ways could we...?

What would happen if...?

From there, you can ask follow-up questions such as:

Why would we...?

What has changed to allow us to...?

Who would need to...?

When should we...?

“When you let your mind wander across the blank page of possibilities, all constraints and
preconceptions disappear, leaving only the trace of a barely glimpsed dream, the merest
hint of a sketch of an idea.”
– Marty Neumeier's Second Rule of Genius

Best Practice Guide to Asking How Might We


1. Begin with your Point of View (POV) or problem statement. Start by rephrasing and
framing your Point Of View as several questions by adding “How might we” at the
beginning.

2. Break that larger POV challenge up into smaller actionable and meaningful
questions. Five to ten How Might We questions for one POV is a good starting point.

3. It is often helpful to brainstorm the HMW questions before the solutions


brainstorm.

4. Look at your How Might We questions and ask yourself if they allow for a variety of
solutions. If they don’t, broaden them. Your How Might We questions should
generate a number of possible answers and will become a launchpad for your
Ideation Sessions, such as Brainstorms.

5. If your How Might We questions are too broad, narrow them down. You should aim
for a narrow enough frame to let you know where to start your Brainstorm, but at
the same time, you should also aim for enough breadth to give you room to explore
wild ideas.

You can download and print out our How Might We template which you and your
team can use as a guide:

Get Your Free Template For “How Might We Questions”

Name Secure form

Email

We respect your privacy

Get free UX design learning material every week

Download free template


A Good POV will Make Your Problem Statement
Human­Centred
Creating your POV will help you to de몭ne the problem as a problem statement in a
human-centered manner. A human-centered problem statement is important in a
Design Thinking project because it guides you and your team, and focuses on the
uncovered speci몭c needs. It also creates a sense of possibility and optimism in that it
encourages team members to generate ideas during the Ideation stage, the third and
next stage in the Design Thinking process. A good problem statement should thus
have the following traits. It should be:

Human-centred. This means you frame your problem statement according to


speci몭c users, their needs and the insights that your team has gained during the
Empathise phase. Rather than focus on technology, monetary returns or product
speci몭cations, the problem statement should be about the people the team is trying
to help.

Broad enough for creative freedom. This means the problem statement should not
focus too narrowly on a speci몭c method regarding the implementation of the
solution. Neither should the problem statement list technical requirements, as
these would unnecessarily restrict the team and prevent them from exploring areas
that might bring unexpected value and insight to the project.

Narrow enough to make it manageable. On the other hand, a problem statement


such as “Improve the human condition” is too broad and will likely cause team
members to feel easily daunted. Problem statements should have su몭cient
constraints to make them manageable.

Linear Problem Solving vs. the Non­Linear Nature of


Design Thinking
This design challenge framing is in stark contrast to the business models for linear
problem solving, which rationally attempt to de몭ne everything upfront, and then
etch away at achieving the set solution systematically. Design Thinking is also very
systematic, but its approach is more about uncovering the problem rather than
etching away at a set solution. Idris Mootee mentions in his book, Design Thinking for
Strategic Innovation, that more than 80% of management tools, systems, and
techniques are for value capture, but that the role of Design Thinking is for value
creation.

Well­framed Challenges
A well-framed challenge has just enough constraints, with space to explore. You
might have encountered the following linear problem-solving approach by your
manager telling you: "Design a poster which increases sign-ups to our next
event."—or—"Redesign the packaging so our product is more noticeable on the
shelf." These kinds of briefs quite often attempt to solve the problem of target
markets not responding well enough to what's on o몭er, and are attempts to put a
patch on things. Design Thinking digs deeper and helps us understand the users,
their needs and our insights about them before we decide upon which course of
action to take. As such, Design Thinking will instead help us ask and research: “Why
are people not signing up for the event?” and “What is it about our product that
causes people to ignore it?”

Design Thinking helps us focus on what kind of userswe’re dealing with, their needs
we're trying to address in our design challenge, and then understand whether we're
actually addressing those needs well enough.

Define and re­define – The Non­Linear Nature of


Design Thinking
Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright
terms and licence: CC BY-NC-SA 3.0

The 몭ve stages of Design Thinking are not sequential steps, but di몭erent “modes” you can
put yourself in, to iterate on your problem de몭nition, ideas, or prototype, or to learn more
about your users at any point during the project. It is important to be aware from the
outset that the initial de몭nition of your challenge is based upon your initial set of
constraints or understandings, and that you should revisit and re-frame your de몭nition
often as you uncover new insights indicating a problem in the framing as you work in the
other four Design Thinking modes.
Know Your History
One of the most commonly structured framing phrases which we use to express the
essence of the challenge at hand is: How Might We? (HMW). The Phrase is rumoured
to have been popularized by Min Basadur at Proctor and Gamble, then on to IDEO,
next at Google and later at Facebook in a viral breakout, that has since revolutionised
how companies frame their innovation challenges. GK Van Platter of Humanti몭c
references a much earlier example in an article entitled, Origins of How Might We?
(2012). The reframing technique has its roots all the way back in the mid-sixties,
with a work by Sidney J. Parnes Ph.D "Creative Behavior Guidebook", which touches
on the concept of "Invitation Stems" or "How Mights" .

The Take Away


Spend enough time to carefully consider the format and composition of your POV and
HMW questions to ensure that your upcoming creative ideation and design activities
are informed with one of more HMW questions, which spark your imagination and
align well with the core insights and user needs that you’ve uncovered. Creating your
POV helps you de몭ne your problem statement in a human-centred manner.

“If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and
5 minutes thinking about solutions.”
– Albert Einstein

References & Where to Learn More


Idris Mootee, Design Thinking for Strategic Innovation: What They Can't Teach You
at Business or Design School, 2013

Ideo.org, How Might We.

Marty Neumeier, The Rules of Genius #2, Wish for what you want, 2014.

Sarah Soule: How Design Thinking Can Help Social Entrepreneurs, 2013.
Warren Berger, The Secret Phrase Top Innovators Use, 2012.

Hero Image: Author/Copyright holder: Simon Powell. Copyright terms and licence:
CC BY 2.0

Topics in This Article:


Design Thinking Point of View Defining the Problem How Might We

Problem Statements

Make Design Better: Share This Article


몭,몭몭몭
shares

What You Should Read Next


The 몭 Stages in the Design Thinking Process

Design thinking is a methodology which provides a solution­based approach to solving


problems. It’s extremely useful whe

몭.몭k shares 몭 mths ago

Read
What is Design Thinking and Why Is It So Popular?

Design Thinking is not an exclusive property of designers—all great innovators in literature,


art, music, science, engin

몭.몭k shares 몭 mths ago

Read

Personas – A Simple Introduction

Personas are fictional characters, which you create based upon your research to represent the
di몭erent user types that

몭.몭k shares 몭 year ago

Read

Stage 몭 in the Design Thinking Process: Define the Problem and


Interpret the Results

An integral part of the Design Thinking process is the definition of a meaningful and
actionable problem statement, whic
actionable problem statement, whic

몭.몭k shares 몭 years ago

Read

What is Ideation – and How to Prepare for Ideation Sessions

Ideation is the process where you generate ideas and solutions through sessions such as
Sketching, Prototyping, Brainsto

몭.몭k shares 몭 years ago

Read

Stage 몭 in the Design Thinking Process: Ideate

In the Ideation stage, design thinkers spark o몭 ideas — in the form of questions and solutions
— through creative and c

몭.몭k shares 몭 years ago

Read

Stage 몭 in the Design Thinking Process: Prototype


One of the best ways to gain insights in a Design Thinking process is to carry out some form of
prototyping. This method

몭.몭k shares 몭 years ago

Read

Stage 몭 in the Design Thinking Process: Empathise with Your Users

Design Thinking cannot begin without a deeper understanding of the people you are
designing for. In order to gain those

몭.몭k shares 몭 years ago

Read

Empathy Map – Why and How to Use It

Did you know that users are more likely to choose, buy and use products that meet their
needs as opposed to products tha

몭.몭k shares 몭 years ago

Read
몭몭 Insightful Design Thinking Frameworks: A Quick Overview

If you’ve just started to embark on your journey into the field of design thinking, you may have
noticed di몭erent frame

몭.몭k shares 몭 years ago

Read

Top Articles
The 몭 Stages in the Design Thinking Process
몭.몭k shares

What is Design Thinking and Why Is It So Popular?


몭.몭k shares

Bad Design vs. Good Design: 몭 Examples We can Learn From


몭.몭k shares

Personas – A Simple Introduction


몭.몭k shares

몭 Great Sites for UI Design Patterns


몭.몭k shares

Top Topics
User Experience (UX) Design

Design Thinking

User Research
Usability

User Interface (UI) Design

With 149,980 graduates, the Interaction Design Foundation is the biggest online
design school globally. We were founded in 2002.

Connect With Us
Reach us at [email protected] or through our online contact form.

Have questions? Check our frequently asked questions.

Get Inspired Weekly


Join 312,093 designers and get weekly inspiration and design tips in your inbox.

Your email Subscribe


UX Courses

Beginner UX Courses

Intermediate UX Courses

Advanced UX Courses

Community

Master Classes

Local Groups

Discussions

Literature

UX Daily Articles

UX Topics

UX Books

About

About Us

The People Behind

Contact Us

Careers
Terms of Use / Privacy

For companies

What is UX Design?

Give as gi몭
   MENU

An Introduction to the Design Iteration Process

Table of Contents [SHOW]

What Is Design Iteration?

What Is Design Iteration?


Design iteration is the repeatable process of improving a product (or part of a product) in
relatively short but regular bursts, otherwise known as ‘design iterations’. These design
iterations can consist of high-fidelity prototypes, mid-fidelity wireframes, low-fidelity sketches,
or even simple diagrams such as sitemaps.

Design iteration drives the overall design process forward.

Why Is Design Iteration A Part of the Design Process?

Jumping immediately into product development and then trying to validate the end result
using research (e.g. usability testing) leads us to design the worst possible version of our
using research (e.g. usability testing) leads us to design the worst possible version of our
product. When this happens, the journey from the worst possible version to the best possible
version is a costly one, and not least time-consuming.

A better approach to designing human-computer interfaces is design in iterations. It enables


us to learn along the way, using feedback and trial-and-error to collect clues about how the
design should look and function. It won’t be a straight road to the finish line, but we won’t end
up moving completely in the wrong direction either. In the long run, design iteration awards
the design process with more time, insights, and stability.

What Are the Benefits of an Iterative Design Process?

It Saves Resources

An iterative design process almost always saves the most amount of time because it regularly
provides us with user feedback (or stakeholder feedback, at the very least) that propels us
forward at a steady pace.

Although positive feedback can tell us when we’re on the right path, negative feedback can
tell us when we’re on the wrong path as well — so we’re constantly moving forward, never
truly wasting any valuable time.

With no feedback at all, we risk rushing all the way to the finish line only to fail, which is a huge
waste of time and bandwidth. Plus, since time is money, this makes design iteration the most
cost-effective option too.
It Facilitates Collaboration

An iterative design process facilitates healthy collaboration too since it awards stakeholders
the opportunity to express their feedback and even share their own ideas. This provides us
with insights that we’d have never discovered on our own because we’re only able to see
things from our own perspective.

It Addresses Real User Needs

Without a methodic design iteration process (specifically one that incorporates collaboration),
designers tend to fall into the trap of working in an isolated bubble. Being siloed causes us to
become too introspective, which then leads us to make hasty assumptions and unproductive
perfectionist behaviours.

However, implementing an iterative design process ensures that we stay focused on user
needs and make decisions in accordance with user feedback. Also, it helps us to prioritize the
next best way to improve the design rather than focus on random improvements.

As an added bonus, user feedback can also help to settle any conflicting opinions amongst
stakeholders.

Facilitates Regular Updates

Having an iterative design process enables us to provide progress updates to stakeholders at


regular intervals, as opposed to just dumping the end-result on them and leaving them in the
dark until then.

For developers in particular, it means that development can begin even while the design is still
in progress (in fact, it allows developers to leverage an iterative development process, so
everybody wins).

When working with clients, frequent updates can illustrate the effort that’s going into their
product, helping to foster good relationships with them. Regular product updates can even be
relayed to customers to generate marketing buzz and acquire public feedback.

UXPin prototypes can be shared with customers and stakeholders within seconds. In just a
few clicks, designers can begin acquiring contextual feedback comments as customers and
few clicks, designers can begin acquiring contextual feedback comments as customers and
stakeholders test design iterations that look and function like the real thing. When using
Adaptive Versions, simulated prototypes will even adapt to their device and screen size. Just
remember to use Preview mode to check prototypes for errors and oversights before sharing!

Where Is Iteration Used?

Iteration isn’t only for designers. Software developers can also take an iterative approach to
their work, working asynchronously or in tandem with iterative design. On a much larger scale,
even entire projects can be methodically managed in iterations.

Iteration in Design

In design, iteration is a key aspect of many design methodologies such as:

• design sprint methodology,

• human-centered design,

• design thinking, lean UX,

• and rapid prototyping approach.

Regardless of the methodology used, teams can asynchronously address multiple user needs
at once using concurrent iterative design processes as long the necessary resources are
available to do so.

Iteration in Software Development


Iteration in Software Development

In software development, iteration is used to facilitate continual improvement, provides a


margin for error, and avoids blocking other aspects of the product development process
(unlike the waterfall methodology, which is linear and enforces all processes to be done
sequentially). In fact, an iterative approach makes it possible for design and development
team members to work in tandem (e.g. combine agile UX and agile software development to
build out functionalities).

Iteration in Project Management

Finally, iteration can also work at a higher-level, becoming the overarching theme of the whole
product or project management process. Iteration provides project stakeholders with regular
updates about the direction of the product throughout its lifecycle, along with data that can be
used to measure core success metrics.

Iteration can even be used to improve internal operations (e.g. DesignOps and DevOps),
providing a massive boost to the team’s morale and productivity.

Iteration in Research

Iterations should be fueled by research. Whether that’s focus groups in design or browser
testing in development, anything learned during research should be used to push us into the
next iteration.

In some cases, research can be conducted asynchronously and independently and doesn’t
need to result in a ‘designed’ or ‘developed’ deliverable. For example, when figuring out how
to label and structure a navigation, designers can iterate through various formative and
summative card sorting studies before finally winding up with a simple set of requirements.

What Does the Iterative Design Process Look Like?


An iterative design process can differ from methodology to methodology, but can generally be
summarized into 5 distinct stages: planning, ideation, prototyping, testing, and finally, review.

Stage 1: Planning

Iteration should be quick but effective, hence a certain amount of planning is required in order
to keep iterations focused on a particular user need.

The planning stage is mostly about deciding which problem to solve during the iteration.
Occasionally this means listening to stakeholder observations but most of the time it means
directly collecting user feedback from previous iterations (or somewhere else such as a
feedback form).

Either way, this stage is always fueled by research and driven by a purpose. In many design
methodologies problems are reframed as opportunities, and when many opportunities
present themselves, methodology states that stakeholders should vote on what appears to be
the best opportunity to improve the product. As an example, the design sprint methodology
relies on ‘how might we’ and ‘dot voting’ for choosing opportunities.

In short, the planning stage should answer the question: “what should we improve in this
iteration?”

Stage 2: Ideation

At this stage in the process the objective is to generate as many ideas as possible no matter
how bad they are, usually via sketching. This is an iterative design process in itself where we’ll
usually refine our best ideas and put aside the worst ones.

Iterative methodologies exist (e.g. Crazy 8s, Four-Step Sketch, etc.) to ensure that the creative
juices remain flowing, and they also enforce time limits to keep the process lean, fun, and
productive.
productive.

Eventually, we/our team will choose one slightly refined idea to move forward with. Chosen
ideas are often phrased as user stories so that the prototyper then has a problem statement, a
clearly defined actionable task, and a detailed-enough visual guide.

Stage 3: Prototyping

Once we’re at the prototyping stage the iterative design process starts to feel a little simpler
as we’re now focused on a specific idea.

The time limit is usually enforced for maximum productivity, so it’s best to use a design tool
that supports your workflow, such as UXPin. Better yet when the product team has a design
system at hand and the UX designer understands it thoroughly, it can help tremendously.

Stage 4: Testing

The objective of the testing stage is to find out whether or not the prototype solves the
problem we’re trying to solve, and how well it solves it. We won’t be implementing anything or
even synthesizing the research, it’s simply about using the right research methods to learn as
much as we can about the solution and documenting any feedback, findings, and insights.

Stage 5: Review

The final stage — the review stage — is about synthesizing the research and coming to a
conclusion about the effectiveness of the solution. A conclusion usually falls into one of the
following categories:

• “Great” — time to implement

• “Good, but…” — circle back to prototyping

• “Flawed” — circle back to ideation

The Do’s and Don’ts of the Design Iteration Process


Do: Fail Faster

Adopting a ‘fail faster’ mentality, embrace trial-and-error to learn what not to do even when
missing the mark. Failure is inevitable so it’s best to get it out of the way early while making
sure to learn from it.

Do: Be Flexible

Although design methodologies have strict rules to help us express our creative freedom
without spending too long on each iteration, they still allow for a certain degree of flexibility.
Ultimately, it’s up to us to decide which opportunities to focus on first, when to iterate or test
more, and how many concurrent design iteration processes should be active at once.

Leveraging any data and research available, these decisions largely depend on instinct and
experience.

Do: Work Asynchronously

Utilizing all available resources (tools, teammates, etc.), achieve the most in the shortest space
of time by allowing other designers to solve other aspects of the product asynchronously, and
developers to begin implementing validated solutions too. Doing both of these will shorten
product timelines significantly.

Do: Collaborate and Listen

Which problem should we solve? Which iteration is best? Is the prototype ready for testing?
What does all this feedback mean? Acquiring fresh perspective and unique expertise from
collaborating teammates gives us the confidence to answer these questions.
Don’t: Try to Solve Everything

Once the problem we’re solving during the design iteration process has been decided, avoid
trying to solve additional problems. Although it’s normal to identify things that can be
improved (during testing or through observation), note them down because they might be
good starting points for later iterations.

Allowing scope creep (additional problems to creep into our design iteration process) will only
distract us, slow us down, and make it difficult to measure the impact that iterations are having
on key metrics.

Conclusion
Now that we understand the foundations of design iteration, the next step is to choose an
iterative design methodology that works for us and our team, and allow ample time for
everybody to master it.

However, no design methodology is perfect. If something isn’t working then consider adapting
the workflow or simply move on and try another method.

Iterative Design with UXPin


UXPin is an end-to-end design tool built to help product teams iterate quickly, collaborate on
ideas, acquire actionable feedback, and eventually hand off high-fidelity prototypes that are
code-based and give developers much more to work with.
With UXPin, go from validated iteration to production much quicker by letting developers
implement prototype specs that are already translated to HTML, CSS, and JavaScript,
collaborate on design system documentation, and even import real React components into
prototypes using UXPin Merge.

Discover Merge

F O U N D T H I S U S E F U L? S H A R E W I T H

  


STILL HUNGRY FOR THE DESIGN?

UXPin is a product design platform used by the best designers on the planet. Let your team easily design, collaborate, and
present from low-fidelity wireframes to fully-interactive prototypes.

Start your free trial

FOLLOW US
 /uxpin

SUBSCRIBE TO OUR NEWSLETTER

Email address
Free e-Books Free UI Kits Design Articles

Sign me up!

We protect your data with care – just as described in Privacy Policy.

DEFINITIVE CONTENT

E-BOOKS

Design Trends 2020

Web Design Trends 2019

Web Design Trends 2018

Creating a Design System Quickly With UXPin

Scaling Design Thinking in the Enterprise

Product Development for Distributed Teams

BLOGS

Designing the Overlooked Empty States – UX Best Practices

7 Pricing Page Examples and Design Lessons that Come with Them

5 UI Components in Atomic Design

Fluent UI – A New Interactive UI Library in UXPin

What is Happy Path in UX Design?

Content Design System – Do You Need It?

WEBINARS

Enterprise Design System – How to Build and Scale

Opening Keynote | Design Value Conference

DesignOps Layers of Impact | Design Value Conference

A Path to Proving DesignOps and Business Impact | Design Value Conference

DesignOps 2.0 – Scaling Design | Design Value Conference


Privacy • © 2010 - 2023 UXPin Sp. z o.o.
® Designers Top 3% Why Clients Enterprise Community Blog About Us

Design What are you looking for?

UI DESIGN 9 MINUTE READ

Perfect Your UX Design


Process: A Guide to
Prototype Design
Prototype design is a powerful process detailing how designers do everything
required to test, iterate, and develop prototypes, beginning with user flows and
ending in functional wireframes.

authors are vetted experts in their fields and write on topics in which they have
demonstrated experience. All of our content is peer reviewed and validated by Toptal
experts in the same field.

By Judit Casacuberta Verified Expert in Design

Judit is a UX Designer and researcher with a master’s degree in Human Computer Interaction.
EXPERTISE

Prototyping UI Visual

The process of prototyping—from creating simple wireframes to testing fully functional


mockups—is one of the most potent and powerful set of skills any designer can master. It’s also
World-class
SHARE

fraught with peril in workplaces where the process is skipped in lieu of just “designing a
prototype” as a simple deliverable to give to the next department to build. No matter how articles,
diligent your business is with prototyping, the actual process can often make or break your final delivered
product. weekly.
How and why to actually build a prototype is often a mystery. Ask many designers and they’ll Enter your email

tilt their heads like confused puppies. “What do you mean? You just do it,” they’ll say. And true
Get great content
enough: We all know how to create a prototype. We just don’t know how we know.

Subscription implies consent to our


privacy policy
This is especially critical considering how prototypes are often the most valuable deliverable.
Clients and managers want to see what you did, whether it’s a website or a physical product.
They want to try it out, inspect the various elements, and understand the workflow. They want
to see “how it works.”

TRENDING ARTICLES
Building a prototype is not enough; we have to understand the process involved with
DESIGN › UX DESIGN
constructing a product’s initial drafts. This article will go in depth on everything a designer
needs to know, and do, to accomplish that.
Shopping for
Apparel in an Online
World: UI/UX Design
Prototype Design - What Prototypes Are for
for Virtual Clothing
Human beings are highly visual. In fact, 30 percent of our cerebral cortex is devoted purely to
Try-on
vision. So when you see a prototype, the most important thing about it is that you see it! When
DESIGN › UX DESIGN
the client can view it, and understand all of the processes involved with the product, especially
areas of contention for future testing, that prototype comes to life. Improve the Product
Development
So what is a prototype? A prototype is a tool for visualizing a smorgasbord of interactive design Process With This
work; in effect, prototypes (at almost any stage) are an amalgamation of all the work that came Simple, But
before into a single, visible, functional piece. This visual representation demonstrates what the Powerful, User Flow
product is doing at any given point, what the interactive elements are, and how the product Analysis
would function in the real world.

DESIGN › BRAND DESIGN


While there are plenty of mechanisms for the various aspects of prototype design (like creating
4 Keys to
sketches), it’s easy to miss things and make mistakes.
Remarkable Brand
This makes the work for how a prototype is built tremendously valuable, since in many ways it
Storytelling
describes how the purpose of the product is actualized. Not perfectly, and definitely not
DESIGN › BRAND DESIGN
accurately most of the time, but as the name implies, prototypes aren’t final.
You Be You: Creating
Content for the Gen
Z Design Aesthetic

SEE OUR RELATED TALENT

Prototyping Experts

UI Designers

They slow us down to speed us up. By taking the time Visual Designers

to prototype our ideas, we avoid costly mistakes such UX Designers

as becoming too complex too early and sticking with a


weak idea for too long.

— Tim Brown, CEO and president of IDEO


Freelancer?
Find your
next job.
A simple way to think of prototypes is as a mechanism to demonstrate functionality.
Prototyping Expert Jobs

That practical explanation of how something works has a number of high-value benefits,
including:

Making it real – Before any prototypes are built, the product is completely conceptual! HIRE TALENT
That’s fine for a little while, but eventually it must become something that stakeholders
and users eventually understand and appreciate. A prototype is the first step in moving
from conceptual to actual. Judit Casacuberta
Verified Expert in Design

Work a problem – Sometimes, we have a design challenge without a solution. As a skill,


prototyping is a great way to visualize the problem and introduce solutions quickly. If it
doesn’t work, throw out the prototype and try again.

Iterate – Prototyping comes in stages, but the result is the same: to evolve your ideas.
From sketches to hi-fis, each new iteration offers a plethora of behaviors and functions
to test. And with more data, we can iterate both faster and smarter.

Detect unintended scenarios – Once something is visible, we have the limitations of our
product available for study, which also provides better context on what should be there…
and what shouldn’t!

Detect usability problems – This is where many designers live: Once a product has a
prototype of any kind, usability challenges suddenly become easy to spot and fix.

Presentation – Prototypes at any stage are a standard for presentation. Whether you’re
testing a version of a page or presenting a product to a client, a prototype in some form
should be there. And if it isn’t, you can bet that someone will ask where it is and why it
wasn’t included.

How to Start the Prototyping Process

After receiving a 50-page requirements document from a client, looking at a blank canvas can
be daunting. Reviewing unorganized thoughts from client meetings, napkin sketches, and dirty
whiteboard photos rarely help.

Because prototypes are built on so much other information, it’s important to gather the
necessary details in advance to putting pen to paper. Consider the following checklist and
review the details provided by your client or manager:

1. What are the goals of the project?

Start with the big picture. Does the product solve a real need? How does it solve that need?
Understanding the product’s utility is critical to delivering any sort of viable solution.

2. What competitive products do people currently use?


A strong competitive analysis will provide a clear picture of the state of the marketplace for the
product type, plus what today’s users expect.

3. Who is the audience? What are their goals?

Understanding demographics and user needs provides the context necessary to create products
geared toward providing for those particular user types and fulfilling their needs.

4. What type of product is it, and what (device) is it for?

With so many different technologies and solutions, UX designers need to know how the product
will be used (web app, responsive website, mobile app, etc.), on what device(s), and how
different versions will coexist (if at all).

5. Are there any visual precedents to follow?

If the product already exists and the project is for improvements or a redesign, it’s possible that
some requirements exist in consideration of current user behavior with the product.

6. What are the deliverables?

Setting expectations about deliverables and the process is critical for your planning and
workflow. Every project is different, but if the deliverables are well defined, the rest of the UX
design process has a higher chance of going smoothly.

Draw Your Prototypes

With our data available and organized, the next step is to start drawing. Many designers will
already have an idea for the layout, structure, or even where specific elements of the visual
design belong before ever drawing it out. That’s fine, but the purpose of initial sketches is to
explore the available space to highlight what’s possible—and, more importantly, what isn’t.

Gather your writing instruments of choice, be it pencil and paper or whiteboard and marker.
The sketching process is akin to a writer freewriting, or a musician strumming; draw what you
feel based on all the work you’ve done in advance, and considering the pieces below:

01 | User Flows – Follow identifying user flows. See how the users meet their goals and how
they interact within the system.

02 | Information entities – Each user flow will show some user inputs and outputs. Identify
what they are, how they relate to the user behavior and expectations, what interactions they are
involved with, and how they work.

03 | First sketches – After getting an idea of who will use the system, what they are going to do,
and with what, it’s time to see how. Sketch your user flows—no need to create the layout yet,
just get the functionality resolved.

04 | Sketch a rudimentary structure – After your user flows are sketched, you will have a better
idea of the best layout for the product. This will include content (text, photos, video, etc.) that’ll
show up as basic boxes or scribbles. When written by hand, they won’t fit to size, so all structure
and content is just for visualization, not for actual use.

One additional tip is to use sketch pads, specially formulated paper, or tools to make clearer
wireframes while sketching. They provide the basic layout for the viewport in question, are
fairly low-cost, and with the proper stencil also make sketches come up more cleanly. These are
tremendously helpful if you’re a messy drawer since they provide the correct aspect ratios and
gridlines for smartphones and web browsers.

This process can continue for as long as you want, but it’s time to move to the next step once a
user flow is completed and the process of completing that flow is clear. It’s a good idea to
bounce back and forth between sketching and building digital wireframes, mainly to keep the
process creative. As you progress through more flows, the product will feel more concrete, and
you’ll naturally shift away from sketching.

Moving to Digital (Low- to High-fidelity Prototypes)

Once there are enough complete sketches to move forward, it’s time to digitize them. Whether
Once there are enough complete sketches to move forward, it’s time to digitize them. Whether
it’s Adobe XD or Sketch, Framer, or Flinto, or something else entirely, creating digital versions
of sketches is the first step to formalizing them. The focus therefore shifts from creatively
adding necessary elements to organizing assets and structure within the designs.

As the prototypes become more practical and the elements more structured, the product takes
shape. When moving to digital prototypes, the fidelity is determined by the level of
interactivity, visual design, and content. A prototype can be low or high fidelity individually on
these areas, though hi-fis incorporate all three at the highest level.

Consider hierarchy in regards to reaching user needs. Each sketch connects to a user flow and
story, and the sketches are a first step toward determining the layout and structure of a product.
Today’s digital tools can speed much of this up—for example, setting master elements that
apply to all pages and templates for page types.

With each new wire and iteration, ask two major questions: Does this page account for its
purpose in the larger user flow? And does the interaction make sense (meaning did the user
understand how to complete the action)? We ask these questions a lot. The more we do, the
more likely each new iteration is to bring the prototypes closer to a final draft.

Digital prototypes are also far easier to test since they’re not only more legible but also faster to
reproduce and iterate en masse. This is where UX prototyping tools like InVision and Proto.io
come in very handy to create clickable prototypes. When it’s clickable, it becomes easy to test
the usability of various aspects, from individual buttons to entire flows.

Clickable prototyping has become especially popular over the past few years thanks to the ease
of use of programs like InVision. It is even more valuable for mobile devices, where now every
major prototyping tool provides some avenue to see or test mobile wires directly on a test
device.

With some engineering knowhow or more powerful tools like Justinmind or Axure, it’s also
possible to build functional prototypes, which are interactive beyond simply clicking. Users can
test things like filling out forms, accomplishing simple or complex tasks, and actually using the
application as it’s meant to be used, all without actually building it. Designers with training in
human computer interaction (HCI) design, including many Toptal designers, regularly build
and test with functional prototypes.

Interactive prototypes are great for testing animations, user operations inside the app, and
higher-level functions that sometimes can’t be tested without a functional action.

Prototype with Purpose

The beauty—and challenge—of prototyping is in the process. We can say the same about almost
everything, but prototypes start and finish with purpose. Without knowing why a particular
screen needs to behave a certain way, how a feature should operate, or whether users need a
funnel or not, the prototype made isn’t developed; it’s drawn and then created ad hoc.

Yet even if every single wireframe built is done so intelligently, questions asked along the way,
with every related user story taken into consideration and the information architecture used as
a map, it’s still possible to miss things. That’s the challenge of prototype design: Clients,
managers, and even designers forget that prototypes aren’t final. They’re just a draft, an
iteration until the next version. It’s all part of the UX design process.

So when constructing your next set of prototypes, remember to ask at least one all-important
question: Does this produce the desired result? If not, then it’s another opportunity to draft a
new version.

•••

Further reading on the Toptal Design Blog:

eCommerce UX – An Overview of Best Practices (with Infographic)

The Importance of Human-Centered Design in Product Design

The Best UX Designer Portfolios – Inspiring Case Studies and Examples

Heuristic Principles for Mobile Interfaces

Anticipatory Design: How to Create Magical User Experiences


UNDERSTANDING THE BASICS
How do you make a prototype?

What is a clickable prototype?

What is a working prototype?

TAGS UX Prototyping Product Design

Judit Casacuberta
Verified Expert in Design
Located in Vic, Spain
Member since July 25, 2017

ABOUT THE AUTHOR


authors are vetted experts in their fields and write on topics in which they have demonstrated experience. All of our content is peer
reviewed and validated by Toptal experts in the same field.
EXPERTISE

Prototyping UI Visual

Hire Judit

World-class articles, delivered weekly. Enter your email Sign Me Up

Subscription implies consent to our privacy policy

Toptal Designers

Adobe Creative Suite Experts

Agile Designers

AI Designers

Art Direction Experts

Augmented Reality Designers

Axure Experts

Brand Designers

Creative Directors

Dashboard Designers

Digital Product Designers

E-Commerce Website Designers

Front End Designers

Full Stack Designers

Information Architecture Experts

Interactive Designers

Mobile App Designers

Mockup Designers

Presentation Designers

Prototype Designers

Prototyping Experts
SaaS Designers

Sketch Experts

Squarespace Designers

Usability Designers

User Flow Designers

User Research Designers

Virtual Reality Designers

Visual Designers

Wireframing Experts

View More Freelance Designers

Join the Toptal® community. Hire a Designer or Apply as a Designer

ON-DEMAND TALENT MANAGEMENT CONSULTING ABOUT CONTACT

Hire Freelance Developers Strategy Consulting Top 3% Contact Us

Hire Freelance Designers People & Organization Consulting Clients Press Center

Hire Freelance Finance Experts Innovation & Experience Consulting Freelance Jobs Careers

Hire Freelance Project Managers Specialized Services FAQ


TECHNOLOGY SERVICES
Hire Freelance Product Managers Utilities & Tools

Application Services Research & Analysis Center

Cloud Services About Us

Information Security Services

Quality Assurance Services

® The World’s Top Talent, On Demand ®

Copyright 2010 - 2023 Toptal, LLC Privacy PolicyWebsite TermsAccessibility


Tricentis Testim Mobile |
SP ECI A L OFF ER U N TIL MA RC H 31 , 20 23

BACK TO BLOG

Test Design: A Leader’s In-Depth


Guide
In this day and age, no serious manager or tech leader would
question the importance of testing. However, it's also…

By Testim, December 17, 2021 SHARE ON   

I
n this day and age, no serious manager or tech leader would question the
I
n this day and age, no serious manager or tech leader would question the
importance of testing. However, it’s also necessary to decide how to carry out
the tests in practice. This takes us to today’s topic: test design.

Test design, in short, is the process of defining how test activities will be done. Here
are some of the topics we’ll tackle in the post:

What does test design mean? Why do it?

When is test design done, and whose responsibility is it?

What are the techniques people use for test design?

Also, we know how hard it is to keep up with the gigantic—and always growing—
lexicon of the software testing world. That’s why we’ll use this post as an
opportunity to kill two birds with one stone; we’ll cover several concepts and terms
that are crucial to know, not only in the context of test design but of testing as a
whole.

Test Design Fundamentals


Let’s open the post with some fundamentals on test design.

What Is Test Design?

Test design means determining how tests will work. When you do test design, you’re
essentially defining the details of your test cases. What will their steps be? How will
they be structured?

Among other things, designing a test might involve:

Thinking about the data the test will use, including its realism, amount, and
boundaries

Expressing detailed test scenarios in a visual—e.g. a diagram—or a written way—


e.g. a table.
e.g. a table.

Trying to predict possible errors and edge cases based on one’s previous
experience and knowledge of the application.

What Is the Purpose of Test Design?

Software testing—both automated and manual—isn’t free. You should treat it as an


investment, which includes tracking its ROI. Thus, you want to make sure your
software testing strategy is as efficient as possible.

That’s where test design comes in handy. With a proper test design process in
place, your team will create tests that generate value for the organization, ensuring
you can ship high-quality code as fast as the market demands it.

How Is Test Design Done? Who Does It? When?

You already know what test design at a high level is and why it matters. Let’s talk
about how to get it done.

Who Performs Test Design?


Who actually does test design? It depends on the type of organization. In more
traditional companies with a more stark divide between roles, testers and QA staff
would be responsible for test design—and probably for all other activities regarding

tests.

However, “the times, they are a-changing.” Due to the rise of automation, agile, and
DevOps, the lines between roles inside tech organizations are becoming thinner
and thinner. Today, we dare to say that everyone performs testing. This, by
extension, means everyone does test design.

Here’s what this might look like in practice:


Engineers write unit tests, which involve designing the necessary assertions,
doing setups and teardowns for classes, and coming up with test data.

Testers with no coding skills can use record-and-playback tools to record UI or


end-to-end tests, which they or other QA staff designed.

If the organization adopts BDD (Behavior-driven development), they might have


the customer—or someone acting as their proxy—collaborating in the creation of
automated specifications.

The list above isn’t exhaustive. But you can see how test design can be the work of
many different actors.

When Is Test Design Done?


When does test design take place? Like the previous question, the answer to this
one depends on how things are done in your organization.

In organizations that still follow a more traditional, phase-based development


methodology, you’ll probably also find a more formal software testing life cycle in
which test design is a phase with a well-defined place.

However, nowadays most organizations are following an agile-based approach to


software development. Such approaches favor development in short, iterative
cycles. In such scenarios, testing is no longer a phase but an activity you carry out
as early in the process as possible. If that’s the case, test design is done several
times in the context of a single iteration.

Test Design Techniques

Having covered the “what,” “why,” “who,” and “when” of test design, the only major
question left for us to tackle is the “how.” Now we’ll cover three techniques for test
design.

Equivalence Class Testing


One of the hardest things when designing test cases is knowing when it’s enough.
How many examples do you need? How comprehensive do your test data need to
be?

Equivalence class testing—aka equivalence class partitioning—is a solution to this


dilemma. This technique tells us to partition our test data into big “buckets” we can
consider equal. Then, only a few values inside each group—and at their boundaries
—are enough to ensure our test is comprehensive.

For instance, let’s say you need to test a feature that asks for the user age and does
something different according to these age groups:

0 to 12 years

13 to 18 years

19 to 40

41 to 65

more than 65

For each of these “buckets,” you need to have a test case:

at each boundary

immediately below and above each boundary

for one value inside the group

So, for the “19 to 40” group, the values 18, 19, 20, 39, 40, 41, and 23 should be enough as
test cases.

State Transitioning

Most commercial or enterprise software features can be described as finite-state


machines. I know that computer science people are fond of scary-sounding names,
but this concept is quite simple. It refers to how a given system goes from one state
to another after some action happens.

When designing a test case, you can use a diagram or a table to reference
expected state changes in your application. FitNesse, a popular tool for automated
acceptance testing, does precisely that: it allows developers, QA, and other
stakeholders to express the behavior of their systems through tables that depict
state transitions.

Exploratory Testing

Exploratory testing is essentially testing that doesn’t follow any pre-defined script.
When performing this kind of testing, testers will use their creativity, domain
knowledge, and previous experiences to come up with novel and unexpected ways

of interacting with the system under test. In doing so, they often uncover edge
cases and unexpected problems.

But if exploratory testing is non-scripted by nature, how can it be a technique for


test design?

Easy; with the help of a test automation tool that doesn’t require code skills, testers
can convert their manual exploratory testing sessions into automated test cases
that they can execute later. That way, they preserve the insights found out during
their creative testing sessions, converting them to a more perennial form.

Test Design: The Top Concepts You Should


Be Familiar With
Before parting ways, we’ll cover some essential concepts that will be valuable in
conversations about test design and software testing as a whole.

The Test Automation Pyramid

You’re probably familiar with the concept of test automation, its benefits, and its
relationship with manual testing in a well-balanced quality strategy.

However, test automation comes in many forms. How do you tell them all apart and
decide which ones are the best ones for your organization?

The test automation pyramid is an answer. This is a simple framework that teaches
you about the main types of automated testing and how they differ in complexity,
cost, and the kind of feedback they provide.

Test Coverage and Code Coverage

People often confuse test coverage and code coverage, but the two metrics refer
to different things.

Code coverage refers to the percentage of a codebase covered by unit tests. Test
coverage, on the other hand, refers to how much of an app’s features are exercised
by at least one test case of any type. It’s less about code, and it’s not relegated to a
single type of testing.

Both metrics are important—test coverage more so—and knowing how they differ is
essential when thinking about test design.

Test Suites and Test Cases

Test suites and test cases are yet another pair of terms people often mix up. While
we have an entire post about this, here goes the TL;DR: a test suite is a collection of
tests—often run together—while test cases are the individual tests.

When doing test design, you’re typically designing the test cases that belong to a
test suite.

Test Design: Since You’re Doing It Anyway, Do It Right


In this post, we’ve offered you a brief but complete guide to test design. You’ve
learned the what-why-how-when of test design, as well as some crucial
concepts/vocabulary related to it. What should your next steps be?

How about learning more about software testing? Here are some more articles you
might enjoy:

What Is the Software Testing Life Cycle? A Complete Guide

The power of Session-Based Exploratory Testing

No Code / Codeless / Low Code testing: What’s the difference?

A good second step would be to look at available tooling that can help you improve
your testing approach, such as Testim TestOps.

Before parting ways, a word of advice: There’s no such a thing as “having no test
design.” If you have tests, someone designed them, period. The problem is if you’ve
been doing poor test design. Since you’re doing test design anyway, you might as
well invest some time and effort and do it properly. Your clients—and your pocket—
will thank you.

What to check out next

Why Test Automation Fails: Test Design and Implementation Tips

Automation Test Strategy & Design for Agile Teams

Expand Your Test Coverage

START TE ST I NG F REE
More stories we think you will like

What Is the Your Testing i


Software Complete Producti
Testing
The softwareLife
testing Guide todays
Gone are the Test Why It’s
Testing in pro
life cycle is the when enterprises relied used to have
sequence of activities solely on manual reputation. An
that happen during testing. Even though (or most?) of i
software testing. By manual testing is an probably des

QA , S E L E N I U M
AG I L E , QA February 03, 2023 QA
January 23, 2023

Testim's latest articles, right in your inbox.


From our latest feature releases, to the way it impacts the businesses of our
clients, follow the evolution of our product

Your Email Address 


P R O D U CT D E V E LO P E R S

Testim Overview

Fast Authoring Documentation

TestOps Testim Root Cause

Test Stability Recorder for Puppeteer

Root Cause Analysis Recorder for Playwright

Pricing Changelog

C O M PA N Y RESOURCES

About Upcoming Events

Careers Success Stories

Newsroom Blog

Contact Us Education

Webinars

All Resources

Community

   

Terms of Service Privacy Policy Cookie Policy Professional Service Terms

© testim 2023
Accelerator Companies Startup Jobs Startup School Library SAFE Apply
Resources

All Posts Advice

Practical Design: Pitching


by Dominika Blackappl 8/15/2016

Design doesn’t have to be complicated, intimidating, or expensive. In an


early stage startup design serves one purpose: helping startup founders
understand their users. To that end, design encompasses more than formal
product execution, logos and layouts, it also means user observation, clear
messaging, MVP specs, concise pitches, and more.
I’ve set out to create a set of free tools to demystify design and help
founders materially improve their user understanding. This is the third tool
in the series. The first two were User Observation and Messaging. Coming
up: Design Brief Creation and MVP Spec.
These tools are all designed to drive action. I hope they can lower the
barrier to entry around thoughtful design by helping you learn by doing.
Interactive versions of each tool are available on my site as they’re released.
–––
150 Second Pitch Tool
This an excerpt. The full, interactive version is available here.
A short pitch in a group setting rarely results in an investment on the spot.
Therefore, the purpose of a pitch is to gauge investor interest and secure
follow-up meetings. This 150 Second Pitch Tool helps you, the founder, plan
your pitch.
Our guided template introduces constraints to avoid common mistakes
such as lengthy language, illegible imagery, complicated infographics, and
meaningless charts. The slides you create with our tool present your
statements in a legible font, size, and with appropriate contrast so you can
focus on practicing your pitch, rather than pushing pixels.
A pitch is sometimes referred to as an elevator pitch, because it should be
easy to understand in a short period of time and without any supporting
assets. If all founders were great speakers, slides would not be necessary.
During your short pitch, think of your slides as a scenography for what
you’re saying.
A typical short pitch summarizes what your company does, how it does it,
the size of your market, who your customers are, your team, your progress,
and your growth. However, a successful short pitch elevates the three most
powerful facts about your company above the expected information. These
powerful facts are sometimes referred to as the pitch vertebrae.
They are powerful when investors remember them. These facts get you
meetings and investment.
I. List the five most powerful facts about your company.
II. With your mind set on those facts, lay out your pitch.
There are nine sections in our short pitch template that correspond with
nine facts about your company that investors expect to see. Each section
consists of explanation of its purpose and forms for filling in your narration
and the copy for the slide in support of your spoken words. The order
represents the most common short pitch flow. But we specifically designed
this tool to create standalone slides. Change this order, or even omit some
slides, to follow the arc of your story. For example, some founders open
with an impressive revenue number, statement of profitability, or a unique
insight before presenting the expected details.
1. What does your company do?
State concisely what your company does and for whom. Be as specific as
possible. The more specific you are in this statement, the less time you need
to spend on explaining the problem you are solving. Playing with our
Messaging Tool will help you tailor these statements.
2. How does your company do it?
Explain how your company delivers what it promises. Describe the process
as you would in a “how it works” section on a typical landing page.
3. Who are your customers?
Mitigate the fear many investors will have about you building a product
based on your assumptions of a need, rather than a well understood and
tested need. Sharing your story, or someone’s story close to you, about a
need that inspired your business is a meaningful way to contextualize your
product.
4. What is your unique insight?
Share a unique insight that either you’ve discovered during interactions with
your users or you know because you’re an expert on the subject matter.
5. How big is your market?
State how big your market is. There are two methods for estimating market
size – top down and bottom up. The bottom up approach is more credible,
therefore we suggest using that. First, figure out who buys products similar
to yours. These people are your potential customers. If your product is
novel, look for current solutions to your problem and determine who buys
those. Then figure out how much your potential customers would be willing
to pay for your product, i.e. the unit price. Last, multiply the number of
potential customers by the unit price to estimate your total addressable
market.
6. How much progress have you made?
Help investors understand how effective your team is. Describe when you
started, what you have built in that time, and if you have customers or LOIs
(Letters of Intent).
7. How fast are you growing?
Share an impressive growth number if you have one. If you share something
it must be true and impressive. You can show revenue, a statement of
profitability, a significant number of customers or users, or any other
number that communicates a healthy upward trend.
8. What’s impressive about your team?
Convince investors that you are the perfect team to deliver on your mission.
Focus on showcasing only the most relevant experience. For example, if you
are entering a highly regulated market or building a sophisticated
technological product, investors will look for founders with specific expertise
and a proven track record.
9. Summarize your powerful facts
This is the grand finale. Plant in the heads of the investors the three most
powerful facts about your company. These can be repeated statements
from previous sections or specific to this slide.
You can find an interactive version of this tool on my site.
Note:
When we designed the 150 Second Pitch Tool we adhered closely to the YC
advice on pitching. Here are other publicly available resources on pitching:
How to Present to Investors, YC founder Paul Graham
How to Pitch Your Company, YC partner Michael Seibel
A Guide to Demo Day Presentations, YC partner Geoff Ralston
How to Design a Better Pitch Deck, YC partner Kevin Hale
Advice on Pitching, YC partner Aaron Harris

Categories
Advice

Other Posts

Learnings of a CEO: Max Rhodes, Faire


July 20, 2022 by Lindsay Amos

Read More

How to Manage a Board


July 15, 2019 by Anu Hariharan

Read More

Learnings of a CEO: Matt Schulman, Pave, on Hiring


October 17, 2022 by Lindsay Amos

Read More

Sign up for weekly updates from Y Combinator

email address Subscribe

Author

Dominika Blackappl
Dominika Blackappl is a designer and Part-Time Partner at Y Combinator.

Programs Company Resources


YC Program YC Blog Startup Directory
Startup School Contact Startup Library
Work at a Startup Press Investors
People SAFE
Careers Hacker News
Privacy Policy Launch YC
Privacy Policy Launch YC
Security YC Deals
Terms of Use

Make something people want. Apply

© 2023 Y Combinator.

You might also like