The Art and Science of UX Design: A step-by-

step guide to designing amazing user

experiences
By Anthony Conta
Chapter 3
Defining the User’s Problems

Design thinking is about solving other people’s problems. It’s a process

that gets us out of our heads and helps us see things from another
person’s perspective so we can understand their wants and needs.

To do this, we need a baseline. We need to define the current state of

things—to come up with a clear understanding of who we are designing
for, what their experiences are like, and what problems we want to solve
for them. Only when we have a well-structured foundation can we build
on top of it in a meaningful way.

To define this baseline, we need to create a representation of users that

we can refer to when talking about the current state. We need to portray
how these users live today so we can create a better tomorrow. We also
need to define the overarching problem to solve so we have clear
alignment and understanding of where to look for that tomorrow.

Defining the problem is an art. We create design artifacts that tell stories
based on the stories we’ve heard throughout the research. We look to
other examples of comparable products to experience how users solve
their problems today. We carefully craft the language of the problem to
solve, choosing words carefully and artfully.

Defining the problem is also a science. We make statements based on

thorough research and data. We gather additional data from comparable
products. We rely on a formula to write the problem to solve, working
systematically toward the structure of the problem statement.

The second step in design thinking is all about definitions, and it begins by
defining the people we are designing for—our users.

Where Are You in the Design Thinking Process?

As you wrap up the user research, you transition from the empathize step
to the define step (FIGURE 3.1).1

FIGURE 3.1 The NN/g design thinking model. The second step of the model is define. It is part of the
understand phase of design thinking, where you take the information you’ve learned from users
and put it together to form a better understanding of the problem to solve.
1 www.nngroup.com/articles/design-thinking/

During the define step, the goal is to take all research and understanding
about the users and apply it to the initial problem you want to explore. At
the end of this step, you should have an excellent understanding of the
target users, a great sense of their experiences, and a more clearly defined
problem to solve.

What are their motivations? Their frustrations? What do they want to

accomplish, and what gets in the way for them? These are all things that
you need to understand so you can design experiences that allow them to
achieve their goals despite their blockers.

But who are the users, and what do they want? You can create a process
artifact that allows you to represent the target user—a tool called a
persona.

Personas

Designing for someone else is challenging when you don’t know who they
are—what they like, what they struggle with, what they want to achieve.
Realistically, you won’t be able to fully understand every single person
who uses your product—you can’t be everywhere at once, so you
probably won’t be with them as they use your product. However, design
thinking has a technique that allows you to approximate the
characteristics of the people who will use your product—the persona.

What Is a Persona?

A persona is a functional yet realistic description of a typical or target

user. It’s not a living human, but rather an abstraction of one. You create
them based on what you observe in the research with users. You call them
personas but refer to them by a real name rather than call them “users.”
Empathizing with a person is easier than empathizing with a user.

FIGURE 3.2 is a persona I created while working on a project for a

cryptocurrency platform that functioned similarly to an NFT marketplace.
This persona, Matt, embodies all the research that went into the project
before we created our designs.
FIGURE 3.2 A persona for a non-fungible tokens (NFT) marketplace.

Author’s Note

There are a lot of ways to organize the information in a persona, with

many templates and iterations available to use. We’ll be working from an
example persona, but feel free to visually lay out your persona in
whatever way you like—provided it contains all the information in the
following subsections.

When you create a persona, you take the observed goals, wants, needs,
motivations, and frustrations of users from your research and map them
into trends that the user population experiences. You take those trends
and create a persona based on those trends so that you have something to
point to while designing. Give the persona a name—“Jane” or “John”—and
when you design, point to those personas to influence your thinking. Ask
questions like “How does this feature help Jane?” or “Would John be able
to use this product?” Personas help align teams around who the design is
for.

What’s the anatomy of a persona, and how can you create a persona for
your projects? Generally, personas contain certain elements that you
looked for during your research:

• Name/photo
• Overview
• Background/bio
 Likes/goals
•
• Dislikes/frustrations
Name/Photo

Every persona consists of identifying pieces of information that allow you

to refer to that persona during conversations about your product. Your
persona needs a name and photo, so everyone on the project can call it by
its name and use its photo in other design deliverables.

Looking at the example persona in FIGURE 3.3, you see two immediately
identifying pieces of information that help center and contextualize the
target users—the name and the photo. A face and name help you
empathize with the target user and make it easier to care more about
them. You may even start to associate the name and photo with people
you know.

FIGURE 3.3 Several of the interviewees for this project were named Matt, which felt appropriate to
use for the target persona for the project. The stock photo represents the target user—generally a
younger, male audience, set with darker lighting to reflect the environment in which we thought
they’d participate in the platform.

Later, when you design, you can make decisions from the perspective of
“Matt” and even use his likeness in the design deliverables—such as,
profile pictures in the product or in user journeys discussing how Matt
experiences the product.

For the name and photo, you don’t have to use a real name or a clear
photo if you don’t want to; you can be more abstract so as to avoid
creating any identity bias in your design, such as gender bias. If you
choose, you could come up with a name that isn’t based on a real-world
name and use an icon to represent the photo of your persona. Perhaps
instead of “Matt,” we could have gone with “the Techie Investor” for our
cryptocurrency project and shown a picture of an NFT, to avoid implying
a gender for our target user.

The Debate to Use a Name and Photo for a Persona

Using a person’s name and photo in a persona is a hotly debated topic in

the design industry. Including this information can cause your solution to
be biased toward a specific population. Some companies I worked for
specifically avoided including photos and used names like “the on-trend
authentic” to describe a target user without including any demographic
information or photo. Others preferred a name and photo to better
identify the target audience. It’s up to you to determine the best path
forward for personas in your projects.

Overview

After choosing a name and photo, you need to start painting the high-level
picture of your persona. What is their profession? How old are they?
What brands do they like? Think of this information as the summary
statistics of your persona.

FIGURE 3.4 shows that Matt is a software developer—this makes sense

given that this persona applies to a technology project that predates the
popularity of NFTs. Cryptocurrency is a complicated marketplace, and
someone working in technology was more likely at the time to understand
it. Also, several software developers participated in the user interview
process.
FIGURE 3.4 Profession, age, and favorite games, which stood in for the brands he had the most
affinity with, are included in the persona.

Matt is 25 years old, which also makes sense given the subject area—a
gaming platform powered by cryptocurrency transactions. Additionally,
that age also represented the median age of the interviewed people.

Author’s Note

A common point to include in personas is the favorite brands of a target

audience, which influences marketing strategy and design aesthetic.
Instead of using brands for this project, games are used.

He has favorite games as well—this was a gaming marketplace designed

to attract fans of video games and sports. Therefore, the high-level
summary in Figure 3.4 includes some of the games that the interviewed
users were passionate about, and the persona includes them as areas of
interest to the target user.

Background/Bio

After choosing your high-level overview, you need to tell the story of who
your persona is. What are their hobbies? What do they do, as it relates to
the problem you’re working on? Think of this information as the elevator
pitch for who your persona is and how they spend their time—the bio
(FIGURE 3.5).
FIGURE 3.5 We cover the games he likes, how he spends his free time, and how he engages with
others online. The platform was heavily focused on esports, so the persona highlights how our
Matt participates in esports.

For this section, you should also include any behaviors or actions your
persona takes. Are there things they do on a regular basis? Is there
something they are particularly passionate about, something you heard in
your research? Include it! This could be its own separate section in your
persona as well.

The research in this NFT marketplace example project revealed that our
target audience played all sorts of games—from digital ones to tabletop
ones to sports. Our interview participants also mentioned they loved
fantasy sports—they formed leagues with their friends and competed to
win prizes and bragging rights as they compared the performance of the
teams they put together as if they were coaches or managers of sports
teams. We wanted our persona to do the same—be focused on gaming,
competition, and socialization with others.

Matt spends his time engaging with games—digital ones online, but also
real-world games like football. He loves esports, since they are the
intersection of all his passions—competition, games, and teamwork. He
also spends his spare time watching leagues and rooting for his favorite
teams as he analyzes and predicts their performance, commonly in
fantasy sports leagues.

Likes/Goals
To ensure your eventual design solution matches the needs of your users,
you need to understand their goals. What do the users want to
accomplish? What do they like? What are they looking for? This
information can help you determine the features to focus on and think of
any areas of delight you could add to the product.

Author’s Note

To help build out goals, think about intrinsic versus extrinsic motivation.
What things are internally motivating, such as personal satisfaction or
enjoyment? What things are externally motivating, like an asset or
reward?

In our research, we learned that our target users loved playing games, not
only because they loved games, but because games connected them to
their friends. They also loved competing in games to display dominance
and showcase their capabilities—even more so with their friends. It was a
mix between camaraderie and competition.

For Matt (FIGURE 3.6), he loves connecting with others, discussing games,
and competing where he can. That means that for any features we want to
design, we should focus on these elements—perhaps we make a message
board, or a leaderboard, to allow Matt to express himself, connect, and
compete.

FIGURE 3.6 Goals included connecting with others, talking about games, and competing.
Dislikes/Frustrations

As with their goals, you need to know what gets in the way of your users.
You need to know what they struggle with, what’s complicated for them,
and where they currently fall short. This is where the design solution you
create can really help users—by knowing their frustrations (FIGURE 3.7),
you can design a solution that directly addresses those pain points.

FIGURE 3.7 Our persona loved competing and playing games; their pain points were things that
got in the way of that, like an off-season, or being limited to fantasy sports only. A design solution
that solved for these would be more enjoyable for our users.

Author’s Note

For this project, we decided to create a single persona based on our

research. However, it is very common to have multiple personas for a
product, especially as that product’s complexity grows and looks to serve
different user interests. Additionally, you may end up with conflicting
insights from your research, which will lead you to create multiple
personas. To start, I recommend focusing on a single persona if you can.

In our NFT marketplace research, we noticed that our users wanted more
options. They wanted to play more frequently—fantasy sports lasted for
only a part of the year, not all of it. Additionally, information was
scattered and hard to evaluate—users needed to comb through statistics
and news articles to understand how successful a player might be for
their fantasy team.
Therefore, we designed our persona to reflect that. Matt really wants
recognition and the means by which to compete. Since he loves
competition (directly and indirectly), he’s frustrated that his current
products lack the ability that allows him to compete. He wants to engage
on his terms with fantasy sports all year long, and he wants to be
rewarded for that, ideally as it relates to his main interest—esports.

All Together

Putting all these things together—the goals, the frustrations, and the other
elements of the persona—starts getting you closer to a possible solution.
In the NFT marketplace example, perhaps Matt would benefit from an
esports marketplace? Or one that allows him to bet on esports in addition
to physical sports? Perhaps it has social elements, like a leaderboard, or
leagues he can play in with his friends. Maybe even a news aggregator
that collects news articles and game statistics from the players Matt wants
to add to his team.

These are just some of the features that could make it into a product
experience for Matt. The ideas start flowing easily once we have a sense of
who we are designing for, and why.

Note that for both goals and frustrations, we didn’t include any of these
feature ideas in the persona. This is because features aren’t things that
people feel—they are things that attempt to satisfy people’s emotions. A
leaderboard isn’t one of Matt’s goals—the ability to showcase his skills is.
We avoided including features at this stage because we cared about the
root behavior or desire of our audience, not something that could satisfy
that desire. That comes later, when we start to think of solutions to the
problem to solve.

How Do You Make Personas?

Hopefully this paints a clearer picture of how to put together a persona

for your projects. Ideally, talk to users through user interviews. Affinity
map the user interviews, then generate I statements from that research.
With those I statements, you can fill in the persona’s goals and
frustrations more easily, to create a greater understanding of who you are
designing for. Statements like “I am frustrated that I can’t compete when I
want” or “I enjoy competing with my friends” would directly map to the
persona Matt and influence our design.
Personas Help You Define Who You’re Designing For

A persona is a critical component of the design thinking process. It serves

as an ideal user to design for—someone you can point to and ask
questions about to inform product decisions. “What would Matt think?”
“Would Carrie like that?” “Could Miles be able to use that?” Imagining
things from the perspective of a persona allows you to make better design
decisions.

Personas aren’t based solely on opinions, either. They are backed by

research, performed by talking with real users. By having these
conversations and hearing real-world stories about what people
experienced, you can understand an audience’s goals and frustrations
and form a general opinion about who the users are.

After all, if you don’t know the users you’re designing for, then how can
you make a user experience for them?

Let’s Do It!

Now that you’ve seen how to make a persona, let’s make one for your
project. Hopefully you have completed both your user interviews and
your affinity map, which will allow you to make a persona based on that
data.

If you haven’t, that’s OK—you could pause on the persona for now and
work on those elements of your project, then make the persona
afterward. Alternatively, you can use the I statements from a practice
affinity map exercise I created, which is available
here: https://tinyurl.com/asuxd-affinity.

If you need a place to start, I put together an example you can use to make
a persona, which is available here: https://tinyurl.com/asuxd-persona-
template

Remember, the persona is designed to help you understand the target

user. What do they like? What blocks them? How do they spend their
time? What are their favorite brands or experiences?

You don’t have to include a name, age, gender, or photo if you feel that
makes your project less inclusive. Instead, think of ways you can identify
or refer to your persona without using those characteristics. A nickname
or phrase that helps identify the type of person you are designing for can
help.

Remember to keep the tenets of good personas in mind:

• A persona is not a real person. It is a representation of a real

person, and one that you use to help you design the solution.
• A persona should “feel” like a real person. Things like quotes,
descriptive biographies, and preferences based on real-user
interview data help flesh out a persona.
• A persona has goals to accomplish. Just like a real person, a
persona has goals, but things get in the way. The identification of
what those goals are, and how blockers affect those goals, is key
to developing a great persona and should influence the solution
you design.
Author’s Note

Refer to the “Persona” section Chapter 3 in the appendix for

examples to compare your persona with.

• Don’t include solutions in a persona. A feature is not a goal or

frustration. For example, a person doesn’t want a search bar;
they want the ability to find information. It might seem subtle,
but an important part of personas is not to include solutions in
them. You’re still exploring the problem; you’re not ready for
solutions yet.
User Journey Mapping

Once you understand who the target users are—the persona—you need to
understand their experiences as well. A clearer understanding of the
users will help you design better. You need to know more than their
wants and needs. How do they move through an experience? What is the
current state that they go through? How do they prepare for an
experience, and reflect on it? Knowing the before, during, and after of a
user experience provides a holistic view that allows you to think of better
solutions.

Is someone struggling with something in the middle of an experience?

Maybe that’s something you can solve beforehand. Do people want to be
able to reflect on an experience more easily? Perhaps a way to record
information during that experience will allow them to look back on it
more easily.

It’s not enough to know about the users. You need to imagine them in an
experience so that you can empathize with their goals and frustrations,
and you need to understand how they experience something so that you
can create an even better experience for them.

To understand more about how a user experiences something, create a

story that explains how they experience that thing—a user journey map.

What Is a User Journey Map?

During the define step of the design thinking process, the goal is to better
understand the state of things. Who are our users? What do they like or
dislike? And what do their experiences look like? Journey maps play a
crucial part in this process.

A journey map is a visualization of the process a person goes through to

accomplish a goal. Quite literally, it is a map of the user’s journey through
an experience, and it includes all the aspects of that journey—their
motivations for starting the journey, their actions as they move through
their journey, and their feelings as they experience elements of that
journey.

FIGURE 3.8 is the real-life journey map I created for the persona named
Matt in the cryptocurrency marketplace project example. I used an
excellent template created by Geunbae Lee.2 The project involved early-
stage NFTs, and the onboarding process was confusing—users didn’t
understand what the platform was, how long an order took to clear, and
the actual value of their portfolio as they made trades.
FIGURE 3.8 A journey map shows the highs and lows of a user experience so that you can
understand and communicate the points that are working well and the areas that need
improvement.

2 https://dribbble.com/shots/4232985--Free-Template-Journey-Map-Bundle

To better understand where the confusion was, I interviewed users,

synthesized those interviews via an affinity map, created a persona
named Matt, and then mapped Matt’s journey before, during, and after
first using the product. I used the user journey map to advocate for
revisions to the existing product experience and focus ideation around
what we could do for Matt on his product journey.

Author’s Note

Depending on how many personas you have and how many goals those
personas have, your project may require multiple user journey maps.
Make sure you represent all the key journeys of each of your personas.

A journey map’s main function is as a storytelling tool used to align the

team. It uses your persona and takes them on a journey through a
scenario. The scenario is of your own design—you can choose what
journey your user is taking. The content of that journey is ideally based on
your research—what you’ve observed as you talked with users or looked
at data that indicates their behaviors and opinions regarding an
experience. Most commonly, user journeys are based on user interviews.

So what goes into a journey map? Usually, every journey map consists of
several key elements that help communicate the user’s experience:

Persona/background
•
• Phases
• Actions
• Thoughts/feelings
• Insights
Persona/Background

To create a user journey map, you need a user! Commonly, this is your
persona, since journey maps go hand in hand with persona work. Since
the journey is told from the perspective of the user, it’s good to have that
user own the journey. To facilitate this idea of ownership further, nearly
everything in this deliverable should come from the perspective of the
persona, as if you were inside their mind, experiencing the things they
experience on their journey.

To align the NFT project team further, it’s helpful to have a background in
the map as well (FIGURE 3.9). Who is this person? What is this journey?
What is this person trying to accomplish on this journey? Setting the stage
helps everyone get on the same page.

FIGURE 3.9 Instead of a long biography (stakeholders could review the persona itself), we included
a quote that summed up why Matt was going on this journey. He’s interested in the product and
wants to learn how to use it so that he can start making trades and compete with his friends.

For the user journey with Matt, we kept the background simple—
stakeholders were familiar with the problem, and we used this
“background” space to communicate Matt’s core user need: learn, then
use the platform to play with his friends and try to beat them.

Phases
Since a user journey map is a journey, it can be broken down into parts or
phases. These phases are the high-level steps taken in the user’s journey
and help organize the rest of the journey map. Think of them as the high-
level flow for a persona’s experience—what are each of the milestones in
the user’s journey? If you had to communicate the steps a user takes
through a product, without going into too much detail, what would those
steps be?

For Matt, I created five phases (FIGURE 3.10). First is Arrival. Matt comes
to the platform, either by advertisements, word of mouth, or an invitation
from his friends. Then comes Understanding. He begins to comprehend
what the platform is and what it offers him. After that comes Purchase. To
participate in the platform, he needs to make a trade and buy some assets
for his portfolio by making his first purchase. Afterward, he needs to
Wait. His trade needs to clear (which can take a long time via the
blockchain), so he waits not only for confirmation, but also to see if the
assets he bought change in value (think of it as an investment). Finally, he
reaches the last step in his initial product journey, Continue Playing. After
some time, he keeps “playing” the game via the platform, competing with
his friends, and investing in more and more assets to grow his portfolio.

FIGURE 3.10 The phases of Matt’s journey through the product. These phases help explain, at a
high level, each step in the user’s journey.

Author’s Note

A person’s journey in a user experience exists outside the product itself.

As a result, user journeys should include out-of-product experiences. For
Matt, that can include conversations with friends to learn about the
platform, or the time it takes for a trade confirmation.

Actions

Now that you have phases that broadly discuss the user’s journey, you can
go deeper and talk about the specific actions the persona takes along the
way. Phases are like chapter headings; actions are more like the
subchapters within each of those chapters.

Actions are still somewhat high level—you don’t need to get as granular as
every step in a user flow from screen to screen, for example. This is more
like what the persona is doing in the story. These actions aren’t exclusive
to the product, either—they can include the product itself but can also
extend to devices (like turning on a phone or computer) or even physical
places.

For Matt, I mapped out all his steps through the five phases of getting used
to the platform (FIGURE 3.11). I also split each step into two
categories. Actions which represent choices Matt makes,
and problems which represent issues Matt has along the journey. In this
case, these problems usually come from the platform itself and are
opportunities for improvement later in the design process.

FIGURE 3.11 Actions lead to an emotional response, represented on the graph as things that make
matt happy or sad. As matt progresses on the journey, he encounters problems, which lead to a
change in his emotional response and additional actions he chooses to take.

But how did I know that Matt takes all these actions and encounters these
problems? Well, the data comes from research. This story we’ve created is
based on talking with users and hearing their experiences. The actions
and problems users encountered in research directly translate to this
map.

Author’s Note

Going through this exercise leads to potential design opportunities. For

example, can we make it easier for Matt to understand faster? It’s a fair
assumption that he is happier once he’s playing—if we make it easier to
play sooner, he’ll be happier sooner as a result.

I also added an extra element—a general satisfaction score for Matt. As he

takes more actions and encounters more problems, his happiness with the
product changes. A visual representation of that satisfaction using this
curve helps us empathize with Matt even more. For example, the
understand phase of this journey map is Matt’s saddest point in his
journey—he just wants to start using the platform and understand it.
Once he gets past that step and starts investing (which was his original
reason for coming to the platform), he is a lot happier.

Thoughts/Feelings

Along your user’s journey, the persona has thoughts that influence how
they feel during the journey. Knowing how users feel as they go through a
user experience is an excellent insight into their goals and frustrations,
and this influences how you design a solution for their needs.

These thoughts could be abstractions of what you observed in user

interviews, like user insights or I statements, or they could quote what
users said during interviews.

Author’s Note

Quotes serve as “evidence.” Your evidence could be photos, videos,

anecdotes, or some other form of “proof” of people saying and doing the
things that your journey map depicts.

For Matt, I chose to include specific quotes (FIGURE 3.12) over high-level
observations. I find that in general, quotes are more powerful at
communicating how a user experiences something—it’s their words, after
all—and these quotes help drive additional empathy for the team.
Interpreting what a user says and extrapolating an insight is an extra step
that dilutes how the user feels—why not just have them say it, in their
words? If I say “Matt found the leaderboard confusing,” it doesn’t have
the same weight as his words. One user told us how confused they were
by the product: “I would say it’s a leaderboard for cryptos, but it’s just a
bunch of random names.” Hearing it in this way adds empathy and
weight to the journey map, which is a main reason why we make them in
the first place.

FIGURE 3.12 The thoughts and feelings of the persona, sometimes represented as user insights and
other times represented as actual quotes from user interviews.

Insights
As an optional step, you can include an analysis of the action items or
areas of improvement in the user’s journey during each phase (FIGURE
3.13). These action items are framed as insights from research,
opportunities for design solutions, or even tasks for the team to complete
later in the process.

FIGURE 3.13 Since the goal of this project was to improve a product, the opportunities in this user
journey are platform enhancements that address the points at which matt is less happy during his
user experience.

For Matt, I included interpretations of the core problems that he had

during the onboarding experience. This pairs well with quotes, for
example—the quotes allow Matt to express his unfiltered thoughts, and
the opportunities allow me to express my interpretation of those thoughts,
which could turn into ideation topics. Since Matt said he didn’t recognize
the names on the platform, I suggested that we provide more context
around those names as a product enhancement.

How Do You Make a User Journey Map?

Hopefully this helps paint a clearer picture of how to put together a

persona for your projects. Ideally, you talk to users through user
interviews. You affinity map the user interviews, then generate I
statements from that research. With those I statements, you can fill in the
goals and frustrations of the persona more easily to create a greater
understanding of who you are designing for. Statements like “I am
frustrated that I can’t compete when I want” or “I enjoy competing with
my friends” would directly map to the persona Matt and influence the
design.

User Journeys Help You Understand

User journey maps help you better understand users. Once you have the
research into the users’ wants and needs, you can take that information
and make a persona. With a persona and the stories from the user
interviews you can go one step further and create a narrative for that
persona.
Humans are driven by stories. Stories are memorable and help you relate
to others. By creating a story for users, you can make it so much easier to
empathize with them, define their problems, and understand the
problems that you are trying to solve.

Let’s Do It!

By now, you hopefully have a good understanding of where to start when

making a user journey map. Let’s practice that skill by making one for our
solo traveler project, using the persona you’ve created from your research
or the data that I’ve provided over the last few exercises.

To get started, search Figma’s community resources, which have several

templates for you to explore: https://tinyurl.com/asuxd-journeymaps

If you are stalled as you try to create a journey map, you might try to
create a simple one for a familiar topic. I’ve had students map out simple
user journey maps to get started, such as a trip to the grocery store or how
to figure out what to eat for dinner.

Feel free to use a persona you may have from one of your projects, or
alternatively, think of your own journey with either of the following
scenarios:

• Imagine you just got home and are starving! You go to the fridge
and find you have no food. What would be your journey?
• Imagine you are going to buy groceries for a week. What would
be your journey?
To accomplish either of these scenarios, take the following steps:

1. Write down your goal.

2. Write down the actions you’ll take.
3. Keep track of your thoughts and feelings as you take those
actions.
4. Categorize your actions into phases.
Author’s Note

Although you can make a journey map that communicates the future
state, that won’t be the purpose of this exercise (especially since we don’t
have a product in mind yet).
The purpose of a user journey map is to communicate the user’s current
state. What is the persona’s experience before, during, and after
interacting with a product? What are their actions? How does the system
respond? How does that make the user feel? Use quotes, insights, and
other supporting evidence to explain this journey and each of the steps
along the user’s journey.

Here’s some tips for making your user journey map. I recommend
working on your journey map, in the following order, to create a strong
narrative for how your users experience their current state.

1. Who is the persona going on this journey? Include a name,

photo, and a high-level synopsis of your persona.
2. What are the high-level steps they take in their experience?
These are the phases of the user journey.
3. What actions do they take along the way? These are the
individual steps that make up each phase in the journey.
4. How do they feel after each action? How does the system
respond? This is the emotions that your persona experiences in
the user journey map.
5. What opportunities exist based on the user journey? These are
the potential design solutions and areas of exploration for your
project once the journey map is complete.
Author’s Note

Refer to the “User Journey Map” section Chapter 3 in the appendix for
examples to compare your user journey map with.

The Problem to Solve

The purpose of the first few steps of design thinking is to understand.

Understand an initial problem, our users, and the context around how
that problem affects them. When all this research is complete, we reach a
clearer picture of the true problem we wish to solve with our designs.

This is where problem statements come in. A problem statement,

or problem to solve, is the focal point of the rest of our project. It’s the goal
we strive for when conducting the rest of our design thinking process—
it’s what we ideate around, what we design a solution toward, and what
we reference as we deliver our product. Thus, problem statements are the
pivotal point of our project. It’s where we move from research to
exploration.
How Do You Use a Problem Statement?

Looking at the Nielsen Norman Group’s design thinking model (FIGURE

3.14), we can visually express the exact point where problem statements
should be formed.

FIGURE 3.14 NN/g’s design thinking model. Problem statements occur in between the define and
ideate steps in the process.

The problem statement is the last piece of the define step in design
thinking. It is the result of research. It is essentially the definition of what
we are trying to accomplish. From that definition, you finally fully
understand what you are going to do with the project, and you are in a
great position to start exploring solutions through ideation and the rest of
the process.

Problem statements aren’t exclusive to this specific design thinking

model. Looking at other models, you can see that the problem statement is
crucial to the process and that some models specifically include it as a
part of their process.
Looking at FIGURE 3.15, the Double Diamond from the British Design
Council,3 you can see that the entire project converges on a single point:
the problem definition, or problem statement, that powers the rest of the
process. The problem definition is an integral component of design
thinking—without it, you lack a compass to design with, a North Star to
follow, a direction to head for ideation. The problem statement is
effectively the prompt around which the rest of the project is framed.

FIGURE 3.15 The problem definition is a key element of the Double Diamond design thinking
process and occurs right in the middle of it, where all the research and the definition of that
research converges on a single point.

3 www.designcouncil.org.uk/our-resources/framework-for-innovation/

It’s clear that problem statements are an important part of the design
thinking process. But how do they help you design? Well, the primary
purpose of a problem statement is to align teams on where to focus their
attention and bring consensus on what they’re going to solve. It’s a
concise way to communicate the user, their need, and the impact of the
problem so that everyone can agree on what solutions to pursue to
address the need for those users.

Author’s Note

In an ideal world, you would focus on a single problem at a time, solve

that problem, and shift to another. In the real world, it’s common to have
multiple problems to solve based on a wide-ranging amount of research
and a deep set of user needs and goals. As a creator of user experiences,
you will have to balance these elements and advocate for which problems
you are focusing on and how your designs solve those problems.

The problem statement is so important that some of the world’s most

famous inventors would rather spend most of their time on defining the
problem rather than thinking of a solution. Albert Einstein said it best:

If I had an hour to solve a problem, I’d spend 55 minutes thinking about the
problem and 5 minutes thinking about solutions.

Let’s take some time to dive into a simple formula for problem statements
and see how you can apply them to a project.

How Do You Make a Problem Statement?

Writing effective problem statements can be challenging. They can

succeed or fail depending on the words chosen. Small changes to language
can drastically alter the effectiveness.

Fortunately, keeping a few guidelines in mind will help you craft the best
problem statements that you can.

Start with a Formula

A problem statement should follow a simple formula:

User + Need = Goal

If you express this formula as a written statement, it becomes:

As a [user], I need/want [need] so that [goal].

This will help you structure the first pass at the problem statement.

Let’s say you’re working on a food delivery service project. For this
project, let’s assume that you did the research and interviewed a lot of
customers who order food delivered to their homes. You found that the
interview participants usually order food when they feel overwhelmed or
don’t have enough time in their day to cook. Ordering a prepared meal
allows them to eat quickly without having to spend the time to shop for
groceries, cook a meal, or do dishes afterward.
Seeing this problem, you want to write a problem statement that will help
you design for these users. Let’s give it a shot:

As a [person], I want [to be given food] so that [I have more time].

This problem statement could help you design something for users. But it
lacks substance. It doesn’t have a lot of context around the user—a
“person” lacks definition, empathy, and focus.

The user’s needs are quite broad as well. What type of food does the user
want? Is the food uncooked or prepared and ready to eat?

And the goal is too ambiguous. People want more time—to do what? Why
do they need that time? This goal lacks empathy, which reduces the
human-centered nature of designing for this cohort of people.

Let’s focus on how you can make this problem statement better.

Be Specific

Your problem statement should be specific. The previous problem

statement was too broad. You need some constraints to design a better,
more impactful solution that is a little more targeted. Let’s try again:

As a [25-year-old single adult], I want [to call a restaurant] so that [I don’t

have to cook meals].

This problem statement is a lot more targeted. It focuses on 25-year-old

single adults, and you can guess that they don’t need to provide for
anyone else because they are single. An ordering experience that caters to
younger adults is a great place to start.

The need is also clear—let them call a restaurant. Something like a

database of restaurants the user can contact would probably satisfy this
need.

Finally, the goal is also clear—the users don’t want to cook meals. You
don’t really know why, but by referencing the research, you can dig into
that user goal and get a deeper understanding.
At the surface, this could look like an excellent problem statement—after
all, everything is clear and the solution basically designs itself. But that’s
the problem—there’s no room to apply design thinking, because this
problem statement is so specific that it includes the solution within the
problem.

Allow Room to Explore

The last problem statement included some information that would have
constrained the design. Users were specifically single, 25-year-old adults—
in reality, you would want to design for a wider range of users so that the
product could scale to satisfy many different types of people.

Additionally, the need is very specific—it is a need to call a restaurant.

What about people who don’t want to talk over the phone? Perhaps
people want to contact a restaurant via text or email instead. Maybe they
don’t even want to contact the restaurant at all; they just want the food.
Or even more broadly, it’s not that people want to get food from a
restaurant, it’s that they want to eat—a restaurant doesn’t even need to be
involved in the solution—but with the problem statement written this
way, it’s assumed that there needs to be one.

As for the goal, although it’s clear, it lacks the true motivator behind that
behavior. Users might not want to cook meals, sure, but why don’t they
want to cook? Do they lack the skills to cook and are insecure about the
food they would make? Or do they like to cook but simply lack the time to
do so or the access to the ingredients they want to use? With this problem
statement, you are left wondering why.

Let’s try again:

As a [working adult], I want [to order prepared food] so [I have time for
other things].

This is getting closer to a well-crafted problem statement. The user is

broader, yet still someone you can design for: the working adult. There’s
room to allow for multiple types of users, such as an adult with a large
family, an adult who works late hours, or an adult who is exhausted after
a long day. Ideally, the persona fits into one of these categories.

As for the user need, it’s broader than calling a restaurant. Now, it has
expanded to ordering prepared food. The users need to eat and want to
order food that’s already been made for them so that they don’t have to
prepare it themselves.

Lastly, for the goal, the users want more time to do other activities. You
don’t assume that they lack the time or interest to cook; rather, the
conversation shifts to say that the users want to spend their time in places
other than the kitchen.

This problem statement is much better. It has specificity to provide focus

during ideation, yet enough room to allow for multiple solutions to satisfy
the users. This problem statement could be used to continue the design
thinking process, but some modifications can make it even better.

Don’t Assume a Solution

Let’s take another look at the last problem statement:

As a [working adult], I want [to order prepared food] so [I have time for
other things].

Author’s Note

One good way to tell whether your problem statement assumes a solution
is if your user need is a noun or a verb. A noun is usually a solution, while
a need is more commonly expressed as a verb.

This statement includes an assumption about the solution. We broaden

our user and our goal, but in doing so we assumed a product solution as a
user need. Prepared food isn’t a need; it’s an idea. We need to define the
underlying need that’s driving that possible solution. Our problem
statements should be problem focused, not solution focused.

Let’s try again:

As a [working adult], I want [to spend less time thinking about my food] so
that [I have time for other things].

This one is getting closer! It doesn’t assume a solution in the users’ needs.
Rather, it focuses on the needs discovered in the research. User
interviewees expressed that they didn’t want to spend their time on
cooking. Rather, they wanted to spend their time on other activities. You
can craft the problem statement to reflect this need and this goal in a way
that gives you even more room to design a solution that addresses the
users’ needs directly.

This is a pretty good problem statement. With just a few more

adjustments, it will be a great one.

Write with Empathy

The goal of a problem statement is to align teams around what problem

you are trying to solve. It’s an alignment tool but also a tool to generate
empathy. Being empathetic in the problem statement will help carry
forward the users’ needs through the project and gives them a higher
chance of surfacing in your design solution. Let’s try one more adjustment
to the problem statement.

As a [busy, working adult], I want [to spend less time thinking about my
food] so that [I can spend my time on other things instead].

Here, the statement has a slightly adjusted user and goal. The last
iteration had a good sense of the users’ needs, but for this one, let’s really
amp up what good looks like for the user. This is the vision you have
when making your product—this is how you can succeed, by delivering
on this promise. If you can enable busy users to have more time to spend
on the things they’d rather do instead of focusing on what they will eat,
then you will have made a product that addresses their core need—more
time to do things other than figure out what to eat.

Keep in mind that this problem statement hasn’t assumed a solution. This
statement allows for plenty of possible solutions to explore during
ideation, such as a food delivery service that sends requests to restaurants
and delivers complete meals, ready to go. Another solution could be a
recipe app for a customer who likes to cook but doesn’t have a great way
to discover new meals to make. A solution to this problem statement
might not even be a digital product, such as a meal kit service that
delivers an entire week of meals for users to heat up when they are ready
to eat.

This problem statement gives you a lot of room to ideate and could be
enough for you to design. However, you can combine this with another
technique to really form a powerful prompt to guide you during the
ideation step of the design thinking process.
“How Might We?”

The problem statement is one piece of the prompt used when headed into
ideation. Another element that’s commonly used with it is a How Might
We statement—a statement that frames ideation further and allows you
to focus on areas of exploration more specifically. This How Might We
statement helps uncover opportunities for design and adds more empathy
to the ideation process. It’s more actionable than having just the problem
statement, and it helps push the process along.

Let’s take the problem statement and try a How Might We statement to
see the combination of the two in an ideation session:

As a [busy, working adult], I want [to spend less time thinking about my
food] so that [I can spend my time on other things instead].

How might we provide a way for our users to spend less time figuring out
what they want to eat?

Here, the problem statement is applied to a design prompt by asking How

Might We. With these combined statements, the team will want the users
to save time when thinking about their meals.

Author’s Note

To add additional focus and empathy, you can replace “our users” in the
second statement with any personas you have generated during this
process. That will link it back to your research, develop more focus on
your specific users, and help to generate additional empathy for your
users.

You could try again with a different area of focus of the ideation by
switching up the How Might We statement, like so:

How might we allow our users to find something to eat more easily?

Now, you can focus the ideation on a different topic. You will generate
new ideas, yet those ideas will still be linked to the original problem you
are trying to solve.

A Great Problem Statement Is Challenging but Powerful

Writing stellar problem statements is extremely challenging. It requires a
lot of research, clear synthesis of that research, and a great deal of
wordsmithing to arrive at a clear enough problem to solve that is specific
enough to be rooted in your research, yet broad enough to avoid
assuming a solution.

Author’s Note

Problem statement generation is iterative. You might not like your first,
second, or tenth try at writing one for your project. That’s OK. You can
keep refining and iterating on the statement as you craft it to get it just
right.

With practice, however, having a great problem statement (and pairing it

with a good How Might We statement) will make it a lot easier to create a
solution that’s rooted in your users’ problems.

Let’s Do It!

With a better understanding of how to make problem statements, let’s

make one for your project. You’ll need your user-interview insights and
your persona.

A great problem statement is crucial for the next step of design thinking.
It helps frame ideation and guide the rest of the project to completion.

You can be iterative here—start with a sentence that combines the user,
the need, and the goal into a single area of focus. Use the problem
statement formula:

As a [user], I need/want [need] so that [goal].

Remember, keep the tenets of good problem statements in mind:

• Be specific. Include a clear understanding of the user, the need,

and the goal in the problem statement.
• Allow room to explore. You should be specific, but not so
specific that there is no room to ideate.
• Don’t include a solution. Problem statements state problems,
not solutions.
 • Include empathy. You’re designing for people, in a human-
centered way, so the problem should include the empathy that
you want to include in a solution.
Author’s Note

Refer to the “Problem Statements” section Chapter 3 in the

appendix for examples to compare your work with.

• Combine with a How Might We statement. These statements

further guide ideation sessions and explore possible solutions.
Competitive Research

Up until this point, we have been focused on our users. Who are they?
What are their needs? What problem are we trying to solve for them?

Now that we have a good understanding of those questions, we can shift

our focus. We can ask ourselves questions about the current state of the
market and the options our users can currently turn to.

What products exist in this space? What companies are working on this
problem? How do users solve their problems today? These are the
questions we seek to answer when conducting competitive research for
our projects.

What Is Competitive Research?

As you prepare to design a solution for the users, it is beneficial to gain an

understanding of what already exists for them. You should develop a
sense of the marketplace, and what other products or services they have
available to use. There are several things to learn from this.

Author’s Note

I’d like to draw the distinction between two concepts: competitive

research and competitive analysis. All the methods discussed here,
including competitive analysis, fall under the umbrella of competitive
research. The terms may be used interchangeably in your place of work,
but for our purposes, I’m referring to competitive analysis as a specific
method you can use when conducting competitive research.
What works? Is there a current solution that satisfies users’ needs that
you can draw inspiration from? Will you have to compete with that
solution once you design your product? What works about those
products? Can you borrow ideas from them for your users?

What doesn’t work? Are there solutions available, but users don’t know
about them? Do they fail to truly satisfy their needs? How can you
improve upon it to make something that does work?

This is where competitive research comes in. Competitive research is the

process of drawing inspiration from other companies to inform the way
you build your product.

FIGURE 3.16 is an example of competitive research I performed for an

education platform—a competitive analysis of features across different
products. I analyzed our product and each competitor to audit which
platforms had what features. This helped us analyze our product and
determine what features we wanted to release and when.

FIGURE 3.16 A feature comparison across competing products.

Author’s Note

These situations happen when applying design thinking. While there is a

general flow you will follow for a project, there will also be times you
need to determine what techniques you want to use, when, and why.
Applying the right technique at the right moment is an art.

We performed this competitive research right at the end of the define

stage of the design thinking process—where we are now. In reality, you
can perform competitive research at any point in the design thinking
process. Some designers prefer to design first, then come back and look at
the market to see what exists and how they may be influenced by it.
Others prefer to do this analysis up front, to inform which features they
want to work on or to use the research as inspiration for the ideation
phase. It’s up to you to decide where you want it in your process.

To do competitive research, we follow several steps:

1. Develop a rubric based on what you want to know.

2. Gather solutions from existing companies.
3. Compare solutions and identify what user needs are met and
what needs are underserved.
4. Explore opportunities for innovation.
Several different types of competitive research exist, but they all follow
these steps: develop your comparison metrics, find your companies, and
analyze their products.

Let’s look at several forms of competitive research you could use in your
process.

SWOT—Strengths, Weaknesses, Opportunities, Threats

A SWOT analysis is a popular technique for analyzing how a business

performs across four categories:

• Strengths
• Weaknesses
• Opportunities
• Threats
SWOT analysis is a comparison tool that helps you analyze yourself, other
businesses, and various opportunities you may want to pursue (FIGURE
3.17).
FIGURE 3.17 Each element of SWOT is mapped to a spot in the grid, where you write observations.

To perform a SWOT analysis, you must consider four different areas of a

company, split into two categories: internal factors and external factors.
You take the elements of each of these factors, put them in a matrix, and
use that matrix to guide the product strategy.

Internal Factors

A company’s internal factors are ones that they directly control. These are
the things the company produces, has agency around, and can influence
directly. They are broken down into two subsections.

Strengths

Strengths are the things that a company does well. What is a company’s
competitive advantage? What does it succeed at? What is that company
known for?

Let’s consider Netflix (FIGURE 3.18). What are some of its strengths? Well,
it has a very large content library, which it can leverage for subscriptions.
It has content you can get only there. It has a lot of different types of users
all across the world. It also collects a lot of data about those users to
influence future content and its own content recognition software.
Finally, it has a very strong brand presence—millions of people are
familiar with the company.

FIGURE 3.18 The landing page for Netflix.com.

Weaknesses

Weaknesses are the things that the company does not do well. What needs
to be overcome? How could the company be even better? What internal
elements can the company control to increase its position or strength in
the market?

Let’s keep analyzing Netflix. One weakness is how it determines what

content to invest in. Content has a small window of opportunity to
succeed—basically, in its first 30 days. With all the content that its
customers can consume, this may not be a fair way to gauge quality
shows. Sometimes, it takes a show a long time to develop a following. As a
result, Netflix has gained a reputation for canceling shows shortly after
they release—much to the annoyance of fans who liked the content.4

4 https://collider.com/cancelled-netflix-shows-get-down-julie-and-the-
phantoms/#the-get-down-2016-2017
Additionally, finding something to watch on Netflix is a challenge. While a
strength of Netflix is that it has so much content to appeal to a broad
audience, a weakness is determining something to watch. Because it has
so much content, sifting through it all is a chore.

Lastly, Netflix has no social engagement features. What if I want to watch

with someone else? It’s hard to use one or multiple accounts to engage
through Netflix itself, like with a social watch feature or a friends list.

External Factors

A company’s external factors are ones that they indirectly influence but
that are market oriented and cannot be controlled directly. These often
deal with market position, competitor influence, or other things related to
the industry a company operates in. External factors are also broken
down into two subsections.

Opportunities

Opportunities are the things a company can take advantage of in the

market. What options exist? What could be capitalized on? What external
market conditions are present that a company could leverage?

For Netflix, some of its weaknesses come into play here. For example,
improving its social features could increase engagement and retention—
streaming services don’t have many social features at large, and as a
result, Netflix could innovate and be a leader in this space.

Additionally, Netflix could take advantage of one of its strengths and

release more exclusive content. Since the streaming wars are fueled by
the content they offer, Netflix could continue to build out its robust
content library. Perhaps even release more interactive content (FIGURE
3.19), which is something unique to Netflix.
FIGURE 3.19 Netflix is known for interactive video content, where viewers take actions while the
story unfolds.

Finally, Netflix could explore different ways to monetize. It has

monetization options based on the number of users in an account, but are
there other ways to incentivize users to pay more? Some other streaming
services do this, with things like premium day 1 exclusives timed to
theatrical releases. Historically, Netflix avoided an ad-based subscription
tier, but after pressure to deliver better financial results, it has since
released an ad-supported version of its service at a lower price to capture
more market share.

Threats

Threats are the things in the market a company needs to avoid, or be

aware of, that could negatively impact the company. What obstacles exist
for a company? For Netflix, there is the threat of market consolidation. As
cable channels both launch their own services and acquire each other, the
streaming service market will become oversaturated and large streaming
service hubs will develop. This could threaten Netflix’s hold on the
market. Already, some streaming services have consolidated, like Disney+
bundling with Hulu, or HBO Max and Discovery+ combining their
services.
Additionally, Netflix is losing big licenses and exclusives for streaming
content. They’ve lost Marvel movies, popular TV shows like The Office, and
more. These shows moving to competing streaming services threatens
Netflix’s position in the market.

Lastly, Netflix must be aware of its prices. As it continues to raise prices,

other streaming services start to become more appealing, especially those
that cost significantly less. Releasing its ad-based subscription tier shows
that Netflix takes this threat seriously.

Putting everything we’ve discussed together for Netflix, the SWOT

analysis would look like FIGURE 3.20.

FIGURE 3.20 A SWOT analysis of Netflix.

We now have a good picture of where Netflix stands. To use this in your
design thinking process, you could observe the opportunities Netflix has,
for example, and ideate possibilities as it relates to your problem to solve.
Here are a few ways this analysis could help you think of new product
features for Netflix:

• Seeing that interactive specials, exclusives, and social features

are all opportunities for Netflix, you could make an exclusive
interactive video that users play together.
• Since finding something to watch is challenging, you could use
Netflix’s strong recommendations (based on its user data) to
create much more personalized content recommendations for
users.
• To promote watching specific content from Netflix, perhaps
Netflix creates a “remix” feature allowing a user to take a short
clip from a moment in a show and share it to social media with
that user’s reaction to that moment.
• As pricing and market consolidation threaten Netflix’s market
position, perhaps they introduce some form of micro-
transactions or additional ways to monetize on their product
library.
A SWOT analysis can lead to a lot of potential options for a product—it
gives you more information on the companies in an industry and allows
you to create ideas for opportunity by being aware of the current state of
things.

Admittedly, SWOT analysis is more common to consider for business

strategy rather than UX strategy, though like the previous analysis, it can
be used to help influence the direction of your product and, thus, the
user’s experience.

Lightning Demo

Suppose you aren’t as concerned with analyzing your competitors and

instead want to focus on the best internal experience you can create.
Instead of a SWOT analysis, you could conduct competitive research to
specifically help drive your ideation. One of the best techniques you could
use for that purpose would be the lightning demo.

A lightning demo is a show-and-tell group session geared toward

inspiration. Lightning demos usually take place when you need rapid
ideation and are working toward a design solution in a short amount of
time, like for a design sprint.
To conduct a lightning demo, participants from your team gather
examples from real products and create a “mood board” of ideas for your
product. Examples can range from competing products to completely
unrelated products—the point is to inspire and motivate a team toward
finding a design direction.

FIGURE 3.21 is a sample output from a lightning demo about a car rental
service. In this demo, I searched for various examples that inspired me
when thinking about the problem of designing a car rental website. I
wanted to find examples of how other companies talk about cars so that I
could gain inspiration for how to position the user experience of the
product I was working on.

FIGURE 3.21 This lightning demo includes product screenshots related to the project, such as those
from competing car rental services. It also includes screenshots from products that wouldn’t
compete with this one, like travel sites and car manufacturers.

You’ll notice that not all of these are car rental related. Airbnb, for
example, is not directly related to renting a car (though it is related to
travel). That’s OK—the purpose of a lightning demo is to gather what
inspires us, and that inspiration can come from anything. Here, I choose
to include Airbnb because I am inspired by how it sells the vision of
travel, as that concept relates to a car rental.

How Do You Do It?

Lightning demos are meant to be short, fast exercises that gather a bunch
of examples for you to draw inspiration from. You could approach a
lightning demo in a lot of ways, but this is the way I most prefer to do it:
 1. Open a whiteboarding tool like Miro, Whimsical, or FigJam.
2. Open an internet browser to look for product examples.
3. Search for products to draw inspiration from.
1. Products that your idea would compete against
2. Products that relate to your idea
3. Products that don’t relate to your idea but that you find
inspiring
4. If you find a product you like, take a screenshot.
5. Put the screenshot in your whiteboarding tool with a very short
description of what it is and why you like it.
6. Repeat until you have 8 to 10 examples.
Let’s go through an example where we do a lightning demo together. Let’s
say we are working on a streaming service and want to make our own
streaming product. Let’s see if we can find some examples for a lightning
demo.

We’ll open a whiteboarding tool and an internet browser and look for
sources of inspiration—first, direct competitors like Netflix, Hulu, and
Disney+. For Netflix, we’re feeling inspired by their landing page—how
they have a video front and center, already playing, as if we’ve already
started watching without having to even press a button. If we like the
content, we can keep watching easily with a single click (FIGURE 3.22).
FIGURE 3.22 The home screen for Netflix.com.

We’ll take a screenshot and add it to our list of inspiration (FIGURE 3.23).
FIGURE 3.23 The first image for our lightning demo.

Next, we’ll look at another competitor for inspiration. Looking at Apple TV

(FIGURE 3.24), we’ll play with the product for a minute or so and look to
see what we like. Navigating to their show detail page, we see a really nice
layout that clearly communicates what episode we’re on, what’s up next,
and what to expect from the tone of the show.
FIGURE 3.24 Apple TV’s UI for a show detail page.

Let’s add it to the list with a note (FIGURE 3.25).

FIGURE 3.25 Updated lighting demo based on the second example.

We could keep looking at competing products, but let’s branch out to

some comparator products—ones that are like our product but that
wouldn’t be competing with us directly. Our product is a streaming
provider that makes its own original content. We make money from
subscriptions to our service and from ad revenue.

When I think about streaming movies and TV, I think about video. Let’s
look at video streaming products that don’t monetize solely through
consumer subscriptions.

A popular video streaming product, Vimeo, makes its money by selling

subscriptions to businesses for its enterprise video tools. Perhaps Vimeo
has some interesting designs we can leverage. Going to their site (FIGURE
3.26), it looks like they have a tool that lets people create their own video
offerings, and that tool has interactive components.
FIGURE 3.26 The video player at Vimeo.com. They offer interactive options on streaming video,
which could be interesting for our project.

I feel inspired by allowing viewers to interact with the content they are
streaming. This is a great example of how it could be done for our
product, so we’ll add it to our list (FIGURE 3.27).

FIGURE 3.27 Updates to our lightning demo examples.

Lastly, let’s see if we can find any other sources of inspiration from
products that we like. I know we’ll need a search function for our
streaming product, so I’ll look at a website (FIGURE 3.28) that has a really
good search feature but is completely unrelated to video streaming.

FIGURE 3.28 The Awwwards website, a website dedicated to finding the most striking and
compelling designs on the internet.

Awwwards.com has an excellent search feature that helps filter things

easily without allowing those filters to get in the way of the content. I feel
inspired just looking at their site’s motion and interaction design, in
addition to its layout, so I’ll include them in our board (FIGURE 3.29).
FIGURE 3.29 Our mood board with several examples of what we find inspiring.

We would keep going to try to find a few more examples—somewhere

around 8 to 10 is a good for a mood board like this and would kickstart
the conversation for how we could design our product.

This process can be modified to your own liking. It can be done in groups
for a group ideation session, or it can be done by yourself on your own
project. As a technique for you to use in your own process, it’s completely
up to you.

If you do it with a team, have everyone spend some time researching

examples on their own and finding their own inspiration (ideally 25
minutes). After everyone has had time to look, come back as a group to
present your ideas. Give each person three to five minutes to present their
findings. As people are presenting, have a facilitator organize the findings
by sketching on a whiteboard what people are saying or by collecting
screenshots from participants. A group brainstorming tool like Miro or
FigJam can help facilitate this.

At the end of this process, you’ll have a set of examples that inspire the
team and generate ideas during ideation.

How Do You Do It Well?

Though lightning demos sound straightforward, there are some strategies
you can use to ensure a successful experience.

• Inspiration can come from anywhere. Let it!

• Ideas can be visual or written. You don’t have to visualize
everything for your idea board.
• Sometimes lightning demos work better as homework than as a
workshop. Experiment with what works for you.
• Always use a timer. This will keep everyone on track, since it’s
easy to lose focus and veer off track with this method.
• Keep your ideas concise. Shorter ideas are easier to scan and
digest.
Competitive Analysis

Competitive analysis is an alternative to both SWOT and lightning demos.

Where SWOT is a product strategy tool and lightning demos are an
ideation technique, competitive analysis is more like an audit. It is a mix
of qualitative and quantitative cross-comparisons of different products or
businesses. It examines the qualitative aspects of those products, such as
purpose, brand, and competitive advantage. It also examines the
quantitative aspects of those products, like revenue, subscribers, and
ratings.

Competitive analysis can focus on the business aspects of various

products, choosing to home in on financials, ratings, platforms, and upsell
opportunities (FIGURE 3.30).
FIGURE 3.30 A competitive analysis of the pricing structure of different companies.

This example competitive analysis examines various companies and the

difference between their free and premium offerings. This analysis was
done in the context of launching a premium service and finding the ways
to optimize the user experience of that service—in this case, that service’s
pricing structure.

Alternatively, competitive analysis could focus on the functionality of

various products, choosing to highlight features, interaction patterns, or
options a user can take in a product, as shown in FIGURE 3.31.

FIGURE 3.31 A competitive analysis of different features across different products.

This competitive analysis was done in the context of enhancing a learning

product, and we compared our service to other services to see where our
roadmap stacked up. This analysis allowed us to advocate for which
features to include at launch, which to include immediately after, and
which to ignore altogether.

There is no right way to choose between these two styles of competitive

analysis. Instead, consider what you need to know about the companies
you look at as you build out your analysis.

How do we get started? As with the other forms of competitive research,

there’s a process you can follow to conduct competitive analysis.

Define the Goal

First, define the goal of your analysis. Are you seeing who offers what
features? Are you gathering company information for a marketing
analysis? What are you assessing?
In the context of the streaming service example, let’s say you were trying
to figure out what to charge and what to call the service. That means you
would turn to competitive analysis to analyze the pricing structure of
other products so that you can determine a better one for yours. Let’s
define your goal as understand the market landscape of how companies
communicate a subscription to customers and what they charge for it.

Set Your Criteria

Next, set the criteria for your competitive analysis. Establish each piece of
data you want to capture from your competitors. Consider the types of
things you want to look at relative to the analysis you want to perform.

Is your analysis about product market fit—as in, is your product

something that people want and that could compete in the marketplace?
If so, then your analysis should be more financial, showing the viability of
the business.

Is your analysis more executional—as in, centered on succeeding in the

market, since you know your product’s idea will satisfy customers? Then
your analysis should be more feature oriented, showing how other
products solve the same problems and how you can innovate within that.

Choosing the key observation points helps focus your analysis. Let’s
assume you know people want your streaming service and that you need
to execute on its user experience and quality rather than prove there’s a
market for it.

To do your analysis, you’ll want to at least capture the name of the

company, the name of the streaming service, the name of paid tiers, and
their costs.

You might want more information than this, but this is a good start for
you to work from.

Gather Your Companies

After your metrics are set, you need to gather a list of the companies you
want to look at. Consider both direct and indirect competitors.
For example, for the streaming service, you could look at direct
competitors like Disney+, Hulu, and Amazon Prime. The indirect
competitors could include Twitch, movie theaters, and cable TV.

You could also consider comparator sources of inspiration you can draw
parallels from.

Author’s Note

At one point, Netflix’s CEO even said that some of their biggest
competition is not a TV company, like HBO, but rather a video game called
Fortnite.6

6 www.vanityfair.com/hollywood/2019/01/netflix-competition-disney-
hulu-fortnite

Continuing with the streaming service, assuming you were trying to reach
a younger audience, you could analyze Snapchat, TikTok, or video games.
Comparator companies can be a great source of inspiration for your
analysis.

For the streaming service project, let’s look at direct competitors like
Netflix, Disney+, and Hulu. For indirect competitors, you could look at
YouTube to start.

Gather Logistics

Next, you will want to gather your logistical materials for conducting the
analysis. What is the location of each product? Is it a website link, an app
store link, or somewhere else?

What’s required to access the product? Does someone need a login and
password? If so, call that out so the team is aware they will need profiles
and so that they can get the required credentials to individually access the
product. Creating a repository of this information, in your spreadsheet,
will help the project team significantly during the process.

If you were working on the streaming service and wanted to gather this
information for the team, it could look something like FIGURE 3.32.
FIGURE 3.32 The names and URls for different companies in our competitive analysis, which helps
the team access the products they need for the analysis.

This spreadsheet includes the name of the company, the location, and if a
login is required so that anyone on the team can more easily navigate to
the product.

Collect the Data

After your spreadsheet is all set up, you can finally begin to collect the
data for your analysis. Start by going through your list one thing at a time.
You could begin by analyzing either a single competitor across all
categories or a single category across all competitors. There’s no specific
right way to approach this, and both methods have their own benefits.

No matter how you choose to fill out your spreadsheet, make sure you
capture visual examples for your analysis. Take screenshots and record
video of each product, as these will help you reference specifics and have
examples to share when you summarize your insights.

You can save this information in a common place for everyone to access,
such as Figma, Google Drive, Dropbox, or some other storage solution.

For our streaming product, we can collect information about the pricing
tiers of each product—what tiers are there, what they are called, and how
they are communicated to users. In FIGURE 3.33 is a collection of
company names and tier names for their products, which can help you
determine what you want to call your tiers. Most companies call their
most expensive, ad-free option “premium,” so you may want to adopt that
convention, so as not to confuse new users who want to sign up for your
service.
FIGURE 3.33 A comparison of pricing plan names for different products.

Summarize Your Results

After your analysis is complete, you will have to summarize your results.
You can create a presentation or share-out summary that highlights the
high-level takeaways of your analysis. Be sure to use visual examples to
illustrate concrete examples of your takeaways—this will help align the
team further and provide additional context around what you observed.

Visual examples for your streaming service project can help influence
how you want to structure your design solution. In FIGURE 3.34, you can
see that the pricing plans from your competitors are presented in a way
that compares pricing options. You would probably want to do the same.
However, you can have a debate about how you execute this plan—some
of the services, like HBO Max and Disney+, show only the high-level prices
and names of tiers. Others, like Netflix and Hulu, go into more detail,
showing exactly what you get for each of those tiers.
FIGURE 3.34 From left to right, top to bottom: screenshots of pricing plans from HBO Max,
Disney+, Netflix, and Hulu.

Is it better for your streaming service to include more details or fewer? Do

you want to be upfront with customers and communicate everything
before the transaction, perhaps showing them the breadth of your
service? Or do you want them to get through the sign-up process as fast as
possible, and share the details later? That’s a conversation you would
have as a team to determine the user experience of your customers
signing up for your service. You might not think to have that conversation
if you don’t do a competitive analysis comparing pricing features across
different products.

Apply the Right Technique for the Right Question

There are many ways to conduct competitive research—including

techniques we have not discussed. There’s no single correct way to
understand the market and analyze companies in the space you are
targeting. Rather, you must define the purpose of your competitive
research and then choose the appropriate technique for conducting that
research.
Additionally, competitive research isn’t something you do once in a
project—rather, you may do it multiple times as you get further and
further along in your process. You may learn of new competitors as you
go and add them to your analysis. Or you may shift the focus of your
research and explore a new question you have, using a different
technique than you did previously.

As leaders applying design thinking to projects, we must know what

techniques exist, when to use them, and to what end.

Let’s Do It!

Any of the competitive analysis techniques covered in this section can be

helpful for the solo traveler project.

Do you want to understand the strengths and weaknesses of travel

competitors to develop a sense of our position in the market? You can do a
SWOT of different companies.

Do you want some inspiration about travel products as you head into
ideation? You can do a lightning demo to get started.

Do you want to audit different travel companies and experience them as a

customer to understand their features or user experiences? You can do a
competitive analysis and create a list of facts and features of your
competitors.

Each of these is a valid option for you to move forward in this project. It
helps to get a sense of what’s out there before you head to the next step in
the design thinking process: ideation.

No matter which competitive analysis technique you try, keep a few

things in mind:

• Define the goal of your research. What do you want to learn?

Choose the appropriate technique that will maximize that
amount of knowledge for you.
• Look at your competitors. Who is a leader in the space you are
exploring? Why are they so successful? Study them and learn
from their successes while analyzing what they could be doing
better.
 • Look at some comparators. Who is related to the space you are
exploring? You won’t compete with these companies, but you
can still draw inspiration from looking a step or two away from
your target market.
Author’s Note

You could save this step in the design thinking process for after ideation.
As you progress through design thinking, you’ll learn which techniques to
apply, when, and why. For our studies, let’s stick with the things that I’ve
laid out in this book.

After You Define, You Ideate

This chapter started at the beginning of the define step of the design
thinking process. You did a great deal of work defining the target
audience via a persona, explaining how they experience their current
state with a journey map, and exploring what already exists for them via
competitive research. At this point in the process, you have converged on
the research and now understand what it is you are trying to accomplish
and for whom.

Author’s Note

Refer to the “Competitive Research” section for Chapter 3 in the appendix

for examples to compare your research with.

In the next step in the design thinking process, you will build off your
understanding of the problem to solve and start thinking of ideas to help
users. You will ideate, diverging around the possibilities for users and
thinking of many solutions to address the problem to solve. From those,
you’ll narrow down your choices and pick a few ideas to carry through
the rest of the process.