Product Design

A Design Sprint is a time-constrained process that uses design thinking with the aim of reducing the risk when bringing a new product, service or a feature to the market

• Allows the team to explore and learn without actually building

• Means the process can fail early without serious consequences

• Creates buy-in and ownership among the team

The Design Sprint process is highly customizable and can be adapted to the specifics of each challenge.

There are six phases of a Design Sprint.

1. Understand

Create a shared understanding of the problem space, the user, the competition, and why it all matters. Align as a team on a focus moving forward for the rest of the sprint

2. Define

Start by focusing on where you want to end. By setting goals you can work backwards to understand what needs to happen in order to get there.

3. Sketch

Ideate. Start diverging and exploring lots of different solutions.

4. Decide

Bring it all back together and decide on one idea to take through prototyping and validation

5. Prototype

Map out and build a prototype of your idea

6. Validate

Check to make sure that your idea is solving a real user need… and that it can be built!

Each phase has a set of tools that can be used to facilitate reaching the goal of each phase. Remember, it’s not necessary to use every tool for a given phase. Instead you should focus on picking the best tool for the problem you are trying to tackle and the composition of your sprint team. We’ll learn more about the tools you can use in the lessons for each phase.

• a working prototype for your concept

• insights and validation from users on your concept

• tons of artifacts

• list of other ideas that can be explored

• More testing and iteration

• The concept will go to Design to be more fully fleshed out

• The concept will go to Engineering to build

• Make a case with leadership to invest more resources in bringing concept to market

• The concept is abandoned because it doesn’t address a user need

• and lots more

Before the sprint starts, it’s a good practice to plan what the next steps afterward will be. But it’s also important to acknowledge and respond appropriately based on the outcome of the sprint.

The best Design Sprints occur when there’s good representation across a number of different functions.

• Want around 6 members on the team

• Members should bring different perspectives, backgrounds, and areas of expertise

• Team typically includes someone from Product, Design, and Engineering - but there’s no hard and fast rule

• Need to find the right people to bring perspective and focus to the current challenge

• Product

• Design

• Engineering

• Data Science

• Marketing

• Support

• Operations

• Sales

• Privacy

• Legal

• Leadership

• Finance

• and many more

Here’s some examples of when a Design Sprint is a good fit:

• New product

• New feature for existing product

• Improvement to existing product

• You need to solve a complex problem

• You don’t already have an answer

And some examples where a Design Sprint is unlikely to be helpful:

• There is already clear product direction, just not final designs

• There is not enough foundational research to understand user needs

• You already have an answer

The Sprint Master

• Creates the structure of the Sprint

• Selects which methodologies will be used

• Facilitates during the sprint

• Keeps the team focused and on track

Challenge Statement

Creating a challenge statement for a Design Sprint is a great way to help everyone understand the purpose of the sprint. The best challenge statements are:

• Short and easy to understand

• Something with urgency that needs to be delivered

• Contain a timeframe

• Are inspiring and get people excited

An easy format to follow is:

[ACTION] + [OUTPUT] + FOR [USER] + TO [PROBLEM] + BY [TIMEFRAME]

“How Might We” is a method to capture problems and frame them as opportunities that can be solved. Each statement should be captured on its own sticky note.

“How Might We” statements always start with the same three words, which creates a positive solution oriented framing.

• How - acknowledges that we don’t know the answer yet but believe this problem can be solved

• Might - acknowledges there can be more than one solution and that we shouldn’t stop at the first idea. “Might” also acknowledges that not every solution will work, but it’s still ok to discuss and explore ideas that might not pan out

• We - acknowledges that the team is invested in solving this problem together

Things to Remember

• Write one “How Might We” statement per sticky note

• Each statement should be open ended

• Statements should focus on open ended opportunities, rather than a specific solution. Try to avoid statements that are too narrow.

You can use the Rose, Bud, Thorn method to classify aspects of a topic and visualize good aspects, opportunities, and negative aspects.

Roses are positive things. For example roses could be things that are going well or seen as a successful. Roses can also represent things or parts of a product that people enjoy.

Buds are things that could turn into roses, if given the right attention. They represent areas of opportunity.

Thorns are negative things. For example thorns could be problems or shortcomings. They also can represent broken product experiences.

The second phase of the Design sprint is Define.

The goal of this phase is to create focus on what you want to achieve and how you will define success. Once you’ve identified that vision, it becomes much easier to understand and frame all the other steps you will need to take to realize that vision.

The HEART framework is a user-centered method to define metrics that measure the quality of the user experience. It’s simple and easy to understand and can help with decision making in later phases. There are five dimensions:

• Happiness - user attitude towards your product

• Engagement - how users are using the product in terms of frequency or number/types of features used

• Adoption - how many new users start using your product

• Retention - how many users keep coming back

• Task Success - ability for users to complete critical tasks in order to be successful with the product

Across these dimensions, you will then want to start by identifying goals, then signals, and finally metrics to measure how well your product is doing.

• A goal is something the user is trying to do or something you are trying to help them to do

• A signal is a change in user behavior that indicates that the user is achieving the goal

• A metric is a way to measure signal and quantify how much user behavior has changed

Keep in mind that it’s ok for goals to have multiple signals and metrics. It’s also not necessary to have metrics for every dimension. It’s more important to pick things that are relevant to the problem you are trying to solve.

Across these dimensions, you will then want to start by identifying goals, then signals, and finally metrics to measure how well your product is doing.

• A goal is something the user is trying to do or something you are trying to help them to do

• A signal is a change in user behavior that indicates that the user is achieving the goal

• A metric is a way to measure signal and quantify how much user behavior has changed

Keep in mind that it’s ok for goals to have multiple signals and metrics. It’s also not necessary to have metrics for every dimension. It’s more important to pick things that are relevant to the problem you are trying to solve.

Writing a future press release or review about your product is a great way to get everyone on the team aligned on the outcomes you are trying to achieve. They also can be fun to write. The main difference between a press release and a review is that a press release is being told from your point of view while a review would be written from the perspective of a third party.

When you’re writing a press release or review it will be important to include the following components

• Name of the product (although this doesn’t have to be final and can change)

• Who is the target user?

• What problem does your product solve?

• How does your product solve this problem?

• Why your team built this

• Why should users care?

• How do users react to your product?

• What sets this product apart from others?

• How can users get the product

Things to Remember

• Write this for an external audience that is not familiar with the product space

• When talking about the solution focus on what the product does rather than how it does it.

The third phase of the Design sprint is sketch.

The goal of this phase is to create and explore lots of ideas, sometimes crazy ones! And then start narrowing ideas down to just a few. Those ideas will be explored in more depth through more detailed sketches.

The fourth phase of the Design sprint is decide

Lots of ideas! And it’s now time to pick the best one. We’ll cover a couple different ways that you can start to converge on a single idea to prototype and test.

A decision matrix allows you to visualize the trade offs between different ideas when comparing across two criteria.

• Ideas generally worth pursuing will be high value & low effort or high value & high effort

• Ideas that are low value & high effort are generally not worth pursuing unless value increases or effort decreases in the future

• Ideas that may not make sense to pursue now, may be worth pursuing later if the value of the idea increase or the effort to pursue the idea decreases

The Thinking Hats exercise allows you to make sure that different perspectives are being discussed and pushes people to be open to different perspectives since everyone will have to represent multiple, differing views..

The team discussion focuses on one hat at a time. The order can vary, but you'll want to start and end with the blue hat (process). This order works well when comparing ideas:

• Blue hat - process (align on goals and order of hats)

• White hat - data

• Green hat - creativity

• Yellow hat - benefits

• Black hat - judgment

• Red hat - intuition

• Blue hat - process (summary of discussion)

• Storyboard maps out the problem facing your user and the journey they go through with your product to solve it

• A storyboard is composed of frames that depict events along the user journey

• Each frame should have a caption that explains what is happening and why

• The first frame should explain how the user found themselves in this scenario and what is the problem they are trying to solve

• The storyboard will become the blueprint for the prototype

• Write your script first, and then create images for each frame

• The first frame should articulate the problem

• The last frame should show how your product helped the user solve the problem

• The frames in between the first and last frame should show how the user gets from the problem to the solution

• Who is your target user?

• How many interviews will you have?

• What do you want to find out?

  • Background information about the user

  • Specific questions around your idea

  • Tasks to complete with a prototype

• How much time you will need to complete each interview