Unit 5 IDT
Unit 5 IDT
Unit 5 IDT
N D FO
IO U
T
N
C
DA
Join us
RA
TIO
INTE
N
Est. 20 0 2
몭,몭몭몭
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
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:
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.
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.
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:
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.
“Teenage girls need… to eat nutritious food… in order to thrive and grow in a healthy
way.“
How Might We make healthy eating something, which teenage girls aspire towards?
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" 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.
"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.
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.)
“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
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.
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:
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.
Wellframed 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.
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" .
“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
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
Problem Statements
Read
What is Design Thinking and Why Is It So Popular?
Read
Personas are fictional characters, which you create based upon your research to represent the
di몭erent user types that
Read
An integral part of the Design Thinking process is the definition of a meaningful and
actionable problem statement, whic
actionable problem statement, whic
Read
Ideation is the process where you generate ideas and solutions through sessions such as
Sketching, Prototyping, Brainsto
Read
In the Ideation stage, design thinkers spark o몭 ideas — in the form of questions and solutions
— through creative and c
Read
Read
Design Thinking cannot begin without a deeper understanding of the people you are
designing for. In order to gain those
Read
Did you know that users are more likely to choose, buy and use products that meet their
needs as opposed to products tha
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
Read
Top Articles
The 몭 Stages in the Design Thinking Process
몭.몭k shares
Top Topics
User Experience (UX) Design
Design Thinking
User Research
Usability
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.
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
Contact Us
Careers
Terms of Use / Privacy
For companies
What is UX Design?
Give as gi몭
MENU
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.
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.
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.
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!
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
• human-centered design,
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.
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.
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:
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.
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.
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.
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.
FOLLOW US
/uxpin
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
BLOGS
7 Pricing Page Examples and Design Lessons that Come with Them
WEBINARS
Privacy • © 2010 - 2023 UXPin Sp. z o.o.
® Designers Top 3% Why Clients Enterprise Community Blog About Us
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.
Judit is a UX Designer and researcher with a master’s degree in Human Computer Interaction.
EXPERTISE
Prototyping UI Visual
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.
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.
Prototyping Experts
UI Designers
They slow us down to speed us up. By taking the time Visual Designers
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
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.
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:
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.
Understanding demographics and user needs provides the context necessary to create products
geared toward providing for those particular user types and fulfilling their needs.
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).
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.
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.
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.
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.
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.
•••
Judit Casacuberta
Verified Expert in Design
Located in Vic, Spain
Member since July 25, 2017
Prototyping UI Visual
Hire Judit
Toptal Designers
Agile Designers
AI Designers
Axure Experts
Brand Designers
Creative Directors
Dashboard Designers
Interactive Designers
Mockup Designers
Presentation Designers
Prototype Designers
Prototyping Experts
SaaS Designers
Sketch Experts
Squarespace Designers
Usability Designers
Visual Designers
Wireframing Experts
Hire Freelance Designers People & Organization Consulting Clients Press Center
Hire Freelance Finance Experts Innovation & Experience Consulting Freelance Jobs Careers
BACK TO BLOG
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:
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 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?
Thinking about the data the test will use, including its realism, amount, and
boundaries
Trying to predict possible errors and edge cases based on one’s previous
experience and knowledge of the application.
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.
You already know what test design at a high level is and why it matters. Let’s talk
about how to get it done.
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.
The list above isn’t exhaustive. But you can see how test design can be the work of
many different actors.
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.
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
at each boundary
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
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.
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.
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.
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 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.
How about learning more about software testing? Here are some more articles you
might enjoy:
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.
START TE ST I NG F REE
More stories we think you will like
QA , S E L E N I U M
AG I L E , QA February 03, 2023 QA
January 23, 2023
Testim Overview
Pricing Changelog
C O M PA N Y RESOURCES
Newsroom Blog
Contact Us Education
Webinars
All Resources
Community
© testim 2023
Accelerator Companies Startup Jobs Startup School Library SAFE Apply
Resources
Categories
Advice
Other Posts
Read More
Read More
Read More
Author
Dominika Blackappl
Dominika Blackappl is a designer and Part-Time Partner at Y Combinator.
© 2023 Y Combinator.