Design Thinking

In order to create a product or service that people love to use, design thinking is essential to the process. Design is the structure of the interaction. A Design Sprint is an intense, focused series of structured activities. And Design Thinking is a set of underlying principles that push us to remember the end user in everything we build.

Expert product delivery is not dependent upon brilliant engineers and designers. It’s dependent upon a team that believes in the process of figuring out the right problem and the most appropriate solution. It’s about building upon empathy, until it leads to delight.

Design Thinking in 5 Phases

1. Empathy. We care about the user and place them front-and-center as we discover challenges and needs.
2. Problem Statement. We strive to correctly name the user’s problem, while being aware that we must keep ensuring that we’ve got it right.
3. Ideation. After restating the problem, we uncover every possible idea that will meet the need.
4. Prototyping. We experiment with a non-permanent fix to take a tangible stab at a solution.
5. Testing. We know that ruling out a solution we’ve prototyped is just as valuable as finding a workable solution.

Empathy: Identifying the Problem

At Revelry, we use Design Thinking in order to apply an active, empathetic, and relentless focus on optimizing the user and customer experience. This is how we solve complex problems and guide business decisions.

As we pursue innovation, we believe in applying human-focused solutions to technology problems.

In large organizations, innovation often comes at a price: Multiple departments are utilized, many product owners and stakeholders must weigh in, and the risk of launching a solution that fails is great.

Thankfully, whether you’re building a small startup or launching a massive consumer product, it doesn’t have to be this way. Incremental, iterative feedback can be sought in each step of the process. We use Empathy in Design Thinking to improve our Lean Agile weekly sprints. This way, we can steadily improve the product until we achieve customer delight.

While the Design Thinking process isn’t linear, just like all things, it begins with a foundation – and that foundation is rooted in empathy.

Wait… aren’t we all designing products for humans?

Yes, we are. But without empathy, it’s easy to forget that our experience isn’t the experience. So it’s important not to take for granted what you may assume is common sense.

Design Thinking means we are going to gather a wider understanding about the user we’re trying to serve, instead of relying on assumptions.

Our product teams observe real user behavior, test low fidelity solutions, and draw conclusions – again and again – about what customers want and need. They’re directly empowered to empathize with the customer by implementing these processes.

Optimizing the User Experience with Empathy: Listening and Research

We can apply design thinking to any solution, hypothesis, or idea.

If an existing product needs improvement, we’ll research the product and interact with it. We’ll make assumptions about what customers are experiencing and what problems they’re facing. And then we’ll watch customers interact with the product, asking them to share their own expectations of the product.

This user observation must be inspired directly by empathy, and not by ego: This is not a product demonstration. When gathering information about user experience, it’s important to be the listener and not the driver.

Even if we have conducted several interviews or developed several similar products, we approach every interview with a beginner’s mindset. That is to say that we suspend judgments, lead with curiosity, and drive an authentic conversation.

We ask a series of open-ended questions, leaving space to allow the end user to provide thoughtful, multiple-sentence answers. And, we ask “Why?” a lot.

The more times you’re able to ask that “Why?” follow-up question, the more opportunity you have to get a more truthful and accurate answer.

Ideas Come to Revelry to be Born

Design Thinking is what allows us to learn about which ideas deserve to be products.

What’s the struggle that your potential customer is having with existing products? We can learn by empathizing, and we do that by asking the right questions.

Want to ask the right questions? Get our User Interview guide, a COMPLETE list of discovery questions here!

By learning everything there is to know about a particular user challenge, we can start to create better solutions. Then, we develop rapid prototypes to help build confidence that a new solution might succeed in meeting the customer’s needs.

User Wants and Needs Include Things That Can’t Be Measured

Empathizing with an end-user means that you’ve tuned in to what they want to feel. And this is not a quantifiable thing. Our product teams have to be ready to notice the desires and aspirations of the intended customer.

Perhaps, the solution we build will make the customer feel smart. Or empowered to achieve something without the help of a professional. Or included. Or productive. A description of the product’s requirements and the product’s utility will feature heavily on the product brief, but so will the emotional language that demonstrates how we have deployed empathy to observe behavior and draw conclusions.   

A Culture That Values Experiments

Our product teams are working in an open-minded culture, where we really value the learnings that come from bold experiments.

We know that we have to explore different ways to solve a problem.

Because we work right alongside the product owner as we test solutions, we like to say that we “work in public.” Working in public also means learning in public. Our first drafts are public. Our first assumptions are public. We share our rough prototypes.

Empathy in Design Thinking: How a Revelry Project Takes Shape

When we onboard customers, we set out to learn how we can add customization to their project that will delight their customers and help their business grow.

Applying Design Thinking, we deploy a set of tasks to be sure that we know the answers to these questions:

• How is this piece of the problem solved?
• Who uses it?
• What is the result? 

The product owner participates in our project process.

• Our product manager drafts the stories that describe the desired outcome.
• Our engineers and designers create solutions that bring us to that outcome.
• The product owner helps define the problem and confirms assumptions, each step of the way.

This participative approach helps us practice empathy not only for the end user, but also for the product owner, our partner in innovation. After agreeing on the problem statement and the desired outcome, the product owner reviews and approves each drafted story so we can keep moving forward.

Empathetic Product Development is Scalable

When empathy is valued as our guiding value in Design Thinking, our solutions can adjust for different applications: The people who will use the product, the environment where they’ll use it, even the different cultural contexts that must be understood about the application of the product must be completely understood.

The value that a good customer experience brings to a product often can’t be measured.

An empathetic foundation to product development works to de-risk business processes. Therefore, it’s fundamental to the success of a business to apply Design Thinking to products, services, and innovation.

Multiple, Small Steps – Not Large, Life-Changing Processes

A brilliant product design should not be – and today, likely can not be – the result of one person’s astute ideas.

Even the most truly awesome and talented team – and the folks at Revelry are exactly that – is not all you need to design the most successful products.

It’s the willingness of the product team to be open and empathetic to the end user, and the patience of a product owner to participate in these small, incremental steps that leads to true customer delight and a successful product.

But, no matter how deep anyone’s understanding of a problem or market need is at the outset, we still cannot accurately predict users’ reactions to the final product.

This is why each half-baked idea, each roughly-sketched prototype, and each basic implementation of a function must be tested with real users.

Without prototyping, we can’t achieve the innovation we set out to build. We know that it’s pretty difficult to come to the right solution the first time around. So we create very simple prototypes in order to validate assumptions.

We’re solving specific problems for specific people facing those problems, and this information serves as our guiding focus throughout the product build.

Problem Statement: Defining the Problem We’ll Solve

Creating solutions without defining the problem is a form of malpractice: you can’t write a prescription without a diagnosis.

When we apply Design Thinking to our product delivery processes, we start with empathy so that we can truly connect with the customer or end user. 

It’s important to define the problem statement in order to move through to product creation. We remain agile throughout this process, because it’s very possible to get the problem statement wrong. 

Humans often think and say one thing, while actually doing and feeling yet another thing. As we addressed in Empathy: It’s How to Deliver Human-Focused Solutions, going beyond active listening is how we work to really get to the core of the problem.

“What is this person’s intent? What are they feeling? What are they hoping they can communicate to me in this moment?”

Creating a good problem statement requires extreme active listening. This is how we uncover that nugget of truth, that underlying pattern.

Defining the Problem Statement in Design Thinking

We listen, observe, ask, and really empathize.

When we create our problem statement, we know that we will have to check back in and challenge these assumptions often. That’s why we’re able to deliver the most agile, human-centered software solutions.

Figuring Out What to Solve, and Writing a Good Problem Statement

While defining the problem statement, we’re essentially making sense of our entire purpose.

We observe what our users are feeling, and we ask what they would like to be feeling when interacting with this type of product or experience.

Driving to have as many conversations as possible, we look to ask open-ended questions, and not describe any solutions. We let the user explain a problem, and ask them to explain how they’re currently getting around this problem.

As we do this, we take notes on each bit of friction they encounter. We listen to pain points and find out about other problems they’ve faced when trying to accomplish this task. 

Taking Good Notes – and Comparing Them

Gathering notes from this observation is a group effort. It takes many points of view to perform observation, and we really want to get the problem right so that we can get the solution right.

The notes we take might be physical: we’ll write observations on Post-It notes and stick them up on a board.

Or, our notes might be threaded: we’ll start a Problem Statement thread in Slack for the current project and drop notes into the thread.

A problem statement contains both a clear description of a problem and a potential method to go about solving the problem. So, our problem statement is written in the form of a “How Might We” question.

Moving to Take Action with “How Might We” Questions

From the notes on the challenges, our team will come up with these How Might We (HMW) questions that address the potential of the challenges that surface. And again, we can utilize Post-Its or Slack threads or just about any medium to collect these questions.

How to write a quality “How Might We” statement:

• It’s not too broad: “How might we build a better house?” generates too many unhelfpul ideas.
• It’s not too narrow: “How might we build a door that swings inward and outward?” produces a solution within the question.
• It’s just right: “How might we improve traffic flow in high-use areas of the house?” targets a segment and makes room for possibilities.

Narrowing It Down: Targeted “How Might We” Questions

Here’s the mechanism we use to surface the most promising HMW questions to address. The team takes 5 minutes to perform voting. By the way, this is a silent process. There is no discussion involved.

Each team member gets 3 votes. They can use those votes in any way they like: spread across three great questions, load up on one terrific question, or divide in another way. Sure, you can vote on your own submission! 

If this is happening in Slack, your vote is an emoji. If this is happening on paper, your vote is a dot placed on a Post-It. There are all sorts of ways to facilitate voting in any setting.

The top 2 or 3 vote getters are the best How Might We questions to address the problem at hand.

“How Might We” is the Start of a Beautiful Question

Phrasing our problem statement in the form of a HMW question opens us up for idea exploration, so that we can ideate, prototype, and test solutions. We’ve opened ourselves up to really learn about what will delight our users, so that our product or business idea is sufficiently de-risked and on its way to success.

Remembering that we are creating human-centered solutions, our HMW question must also be human-focused. What does the user want to feel? What will an interaction with our product cause them to feel? The ability to delight a customer is directly tied to how they feel when using the solution you’ve built.

And your customers usually can’t tell you exactly what it is they need. So, you’ve got to come up with multiple possibilities. And you’ve got to test them.

Where are all these possibilities going to come from?

Ideation: Uncovering a Range of Solutions

You may be thinking, “There are plenty of bad ideas,” but the point is that at this phase, we haven’t proven it yet. So, it’s time to ideate.

Ideation in Design Thinking enables us to surface a range of possibilities and uncover innovation in unexpected places.

In the Problem Statement phase, we targeted some How Might We questions. It’s time now to offer as many answers to those questions as possible. That’s why in this moment, as we set out to gather answers to “How might we…”, no idea is a bad idea.

There are multiple approaches to any particular problem. 

Any one of these approaches might be valid. Our goal is to be able to surface as many possibilities that exist, and then to force ourselves to make a decision about which one we want to pursue at this time.

In Ideation, We Practice Divergence and Convergence

So, we start from this shared understanding of the problem statement. From there, we diverge in order to create all these possibilities for ideas and solutions. Then, we re-converge around those possibilities and try to make our best judgments about what we want to take forward to prototype and test.

Ideation in Design Thinking: Parallel Ideation Exercises Surface Multiple Possibilities

It’s time to have fun: ideation exercises are some of the most exciting exercises in Design Thinking.

Ideation can be performed using any method that’s appropriate. We prefer to add artificial constraints by time-boxing specific activities. This gets our team pumping out ideas quickly.

The team gets together to create ideas – together, but separately. That’s why we say these exercises are done in parallel. Focusing on our main How Might We questions, the team performs drawing, sketching, and mind mapping exercises.

Each activity is performed independently, but synchronously. It’s important that these exercises are individual and that they’re time boxed. 

Ideate Step One: Messy Mind Maps

Before each participant can get into drawing up rough sketches of their ideas, they need to generate and gather those ideas. So we use a timed period of mind mapping.

Repeating the mantra that no idea is a bad idea, each individual takes 5 minutes to get some loose ideas on paper. These messy mind maps won’t be shared, but this activity gets the creativity kicked off.

Mind mapping allows everyone to pull as many ideas as possible out of their head and onto a visual medium.

We use timed exercises to force all ideas to come rushing forward.

Ideate Step Two: Crazy for Those 8s

The buzzer sounds, and it’s time to drop those mind mapping pencils and swap them out for Sharpies. After looking over all the wild ideas we jotted down, we must pick one of our own to get sketched out.

OK, it’s not important to use Sharpies, but the idea here is that we aren’t going to sketch happy trees with correct shadows.

We’re going to outline eight different solutions – getting the general idea across, not going deep into details – for that one single problem.

Taking a single sheet of paper, we fold it in half three times. When we open the paper, we’ve given ourselves eight panels on which to unleash these solutions.

Ideate Step Three: Storyboards

After reviewing the eight options we provided for ourselves, we come up with the strongest among them and turn it into a 3-panel storyboard.

If each panel on the crazy 8s sketch represented a single user interface, the storyboard brings that interface to life by taking into account everything else that is happening for the user when they encounter this product.

Drawing on empathy, we’ll picture what the user is needing and feeling, and represent this by telling their story. The depiction will demonstrate everything that’s happening from the point of pain, to the encounter with our proposed solution, and on to the reward or payoff that our solution has brought.

This storyboard is an interface sketch that will speak for itself. It has a title, and it’s shared with the group.

Note: we share the storyboard. We don’t present it. Without narrating or selling what we’ve drawn, the group should be able to understand the scenario or have their curiosity piqued about the user.

Heat-Mapped Voting: The Group Responds to the Storyboards

Spending two minutes on each storyboard, the team performs heat-mapped voting to select the section of the storyboard that most speaks to each team member.

Silently, and individually, the team examines each storyboard. Each person is equipped with small dot stickers that they use to place anywhere on the storyboards where they find something of interest.

Heat mapping is a great way to perform this exercise, because it helps us identify commonalities among the team. Areas that show clusters of stickers, or heat, might be related to a single button or interface element, an implied transition, or some other piece of the user flow.

The heat maps can also identify ideas that are different, and worth exploring.

This may sound like an exercise that has to be done in person, but that’s certainly not the case. You can perform remote design thinking exercises by using Zoom and some creativity.

With the Heat Map Complete, It’s Time for a Verbal Critique

Set a timer for 3 minutes per storyboard. Have the team talk through each storyboard for 2 minutes (the creator stays silent, actively listening). The purpose is to highlight what the team finds interesting, challenging, or even confusing. Then, in the final minute of each, ask each storyboard creator if the team missed anything important.

Once this review is complete, the team is ready for decision making.

We conduct another super vote, as we did during the How Might We exercises described in the Problem Statement phase. The stickers we use this time will be a bit larger, and we can use all our votes in one place if we feel strongly.

The team members have 3 votes each. We place our votes on the storyboard – or across the storyboards – to identify the experiences and actions that should be pursued in prototyping.

Vote for your own storyboard, or put all your votes on a single storyboard. All voting is fair game in a super vote.

With the super vote in hand, there should be a standout storyboard to carry forward into prototyping. Don’t forget the heat map as you move forward, though; often small ideas from each of the storyboards make their way into the prototype as valuable additions.

After analyzing the heat maps, it’s time for a final round of voting.

Prototyping: Bringing Our Ideas to Life

Prototyping is a learning activity: it’s useless without testing. When we use rapid prototyping and targeted testing, we can de-risk business ideas and make better decisions about growth objectives.

When crafting innovative solutions, it’s very tempting to come up with the most unique, the flashiest, the most attention-grabbing product ideas. Ideating many varieties of solutions is helpful, but when it comes to prototyping that really gets the job done, simpler is better.

Creating low-fidelity prototypes helps us to de-risk the entire process.

We create low-fidelity prototypes in order to learn as much as we can during design thinking. They are not designed to be visually appealing. These quick prototypes are designed to specifically address the needs that we surfaced during ideation.

Prototyping in Design Thinking Ensures We’re Learning About the Customer

Teams that run lean agile sprints are always working with a bias toward “build”.

Prioritizing a bias toward “learn” helps us slow down the thinking just enough to be sure we are considering the user throughout each step.

We apply a level of empathetic listening that goes beyond active listening. We structure ideation activities that address the right problem to solve.

This helps us identify opportunities for improvement while still performing necessary builds. We believe in the value of design thinking principles, and our innovation partners benefit from the quick wins that come out of this practice.

Build-Measure-Learn: The Lean Startup Principles

Eric Ries pioneered “The Lean Startup” approach to building companies from startups to businesses that have proven their revenue model. This approach is useful across all types of experiments, including design thinking for enterprise and corporate innovation. 

Building something small, challenging a hypothesis, learning from customer interaction, and building upon those results is exactly how we achieve customer delight through the entire design thinking process.

We instill a prototyping mindset – along with an entrepreneurial mindset – across the Revelry team in order to empower them to experiment often.

Communicating Ideas

Prototyping puts ideas in a tangible form.

The goal for this phase is to simply bring the ideas to life. A prototype doesn’t have to be fully elaborate, fancy, or perfect. Taking the idea from conceptual to tangible allows us to test it.

We turn our ideas into tangible prototypes in the hopes of validating those “How Might We?” questions that we zeroed in on during ideation exercises.

Our research will be proven – or disproven – but most importantly, we’re approaching this phase with empathy on the mind.

Ultimately, the prototype that we move on to build and deliver to the market must prove that with the user in mind, we are truly solving the problem that we surfaced earlier in our product development.

The Possibilities are Endless

We can’t build on every idea. We must have a proven method to decide which ideas we will pursue.

Rapid prototyping allows us to fail quickly, fail cheaply, and de-risk business ideas without taking a chance with the brand reputation. And when rapid prototyping delivers quick wins, it helps us break down complex problems into smaller elements.

Armed with some form of interaction or clickable prototype, we can set out to get real user feedback before investing heavily on a new product build.

Our prototypes offer some form of an interface for users to explore.

We observe and record all of their expectations, feelings, and actions as they interact with the physical embodiment of our idea.

We are working towards solving the problem statement and always remembering the user experience: Empathy for the problems and challenges the user is facing. 

Design Thinking isn’t meant to happen in a sequential order. We recognize that each phase has its own item of importance and should continually be cross-checked as we continue to work through the methodology. 

Creating prototypes allows us to test and refine the functionality of our designs.

The Difference Between an MVP and a Prototype

A prototype is not viable. That’s the simplest explanation.

An MVP – the Minimum Viable Product – is the simplest form of a solution that can actually be put on the market and get traction. It still has room for improvement, of course. It is not perfect, no.

But it is good enough.

A prototype is not good enough.

It cannot be launched to the market. It’s useful only for answering our product development questions.

And, it’s very useful in that way.

The Science of Prototyping in Design Thinking

At Revelry, prototyping typically looks like either:

1. A clickable UI prototype, usually designed in Sketch and imported into Invision
2. A code prototype used to prove our ability to solve a particular problem with a particular technology

The audience for each of these prototypes is different.

The UI prototype is typically aimed at the end user of the potential feature/product. It may serve one or more of the following learning goals:

• usability: can the end user effectively accomplish the task(s) they are being presented with?
• conversion: if given a funnel, does the end user “convert” in the way we are hoping?
• understanding: can the end user re-articulate what the product is doing, what purpose it is serving, what problem it is solving, and why it is valuable?

Vary your prototypes – Create various prototypes and iterations from the ideas created throughout the ideation. This will help the user also test variations when you get there.

Identify a variable(s) – Your prototype should answer a question you are trying to solve for. Be open to the feedback identified throughout the testing of the variable.

Capture Feedback  – Identifying what it is we want to learn with this prototype sets us up to organize and interpret feedback and user responses.

Plan Tests Ahead of Time

These prototypes will garner a lot of feedback. The only way to learn from the feedback is to know exactly what we want feedback on, and be disciplined about our testing methods.

Testing: Validating and De-risking Our Proposed Solution

Design thinking in product development is all for nothing if you aren’t learning. For successful product development using Design Thinking, you must plan careful tests, identify what you want to learn, and organize feedback accordingly.

Empathy places the user at the center of our focus, and testing gives us the opportunity to prove the theory our solution proposes.

Testing is useless without a learning mindset and requires the resolve to abandon ideas when the evidence is clear.

There is never only one single way to solve a problem.

Each prototype that we create represents a theory:

• Perhaps this is how we will ease this pain?
• Perhaps this solution is the most efficient?

And so, placing a prototype in the hands of real users allows us to learn whether we are addressing user needs by solving the right problem.

Testing in Design Thinking Provides Low Risk, Incremental Value

There is no need to envision the entire customer journey or product roadmap. We make small, intentional, incremental improvements to a product or experience by testing each significant function.

When we conduct user research prior to ideating solutions, we listen to what our customers say they want to achieve and how they want to feel.

Engaging with customers during testing helps us prove (or disprove) our assumptions.

Perhaps our theory was wrong. Perhaps the customer’s description of their problem or need was wrong.

Testing a prototype, rather than releasing a fully fledged product to the open market, is the most risk-free way to scale businesses and product offerings.

Gathering Useful Feedback

Just as we remember that user research is not a prescriptive process where we suggest a solution and get opinions, we know that testing is not a product demo.

When we conduct user research prior to ideating solutions, we listen to what our customers say they want to achieve and how they want to feel.

Engaging with customers during testing helps us prove (or disprove) our assumptions.

Allow the user to interact with and experience the solution. Ask them to walk through what they’re doing and why.

We aren’t asking to be graded or evaluated – we want to know how they are reacting, not how they are judging the experience.

Before launching a test session, we identify what it is we’d like to learn about the user experience, so that we know what to ask the user. We are not going to defend or be too attached to our solution while the user kicks the tires.

Empathy is constantly our guiding force: how does this user feel as they move through our proposed solution? We ask open-ended, open-minded questions and receive feedback in the same way.

How We Go Back and Iterate

We are not going to solve this problem with our first swing. We don’t expect to, anyway. Product development is an iterative cycle of building and learning, so every chance to tweak some bit of the process is an essential opportunity.

During observation, the comments that users make will form new “How Might We” statements and hypotheses.

“I wish I could do this right here.”

“I was expecting that this button would lead to some other information.”

When the feedback becomes seemingly inconsequential, such as the choice of color, it’s time to realize that we are getting close to the actual solution. Yes, color is an important part of the customer experience, but if we’ve presented someone with the most direct way to solve the most pressing problem, we can move on to colors and button shapes later.

This is when we know we have validated the idea to the point where it can be built and launched.

Now, product implementation can begin.

We follow a “release early, release often” philosophy. Rapid iteration is the name of the game. We believe that projects succeed more often with continuous communication, evaluation, and response.

At Revelry, we’ve optimized our workflows over a decade and have developed a handful of tools that automate repetitive tasks and produce software that can be delivered in usable, testable pieces every week. Want to learn more? Let’s connect.