Learn / Guides / Design thinking guide
How to create a design thinking problem statement to keep your product on track
We’ve all had days when we can’t decide what music mood we’re in, so we repeatedly hit 'skip' until the car ride is over. When we don’t know what we want, we can’t make a decision.
For product teams, writing a design thinking problem statement isn’t all that different.
If you don’t set a direction early in the design thinking process, you and your team will work in circles without any satisfaction or progress. But when you set the tone of your process early on, your team gets into the groove to create a user-first product.
Your design thinking problem statement needs to strike the right balance between focused and flexible to be effective.
This chapter of the design thinking guide reviews design thinking problem statement examples and strategies that will help your team work effectively to create products your users will love.
Seeing is understanding
Stop guessing: let users show and tell you what they need with insights from Heatmaps, Recordings, and Feedback.
What is a design thinking problem statement?
A design thinking problem statement is a concise and actionable sentence or question that defines your UX purpose and direction. Product teams using design thinking develop problem statements to simplify complex problems and identify the gap between what your product has and what your users need.
Since the design thinking process is non-linear, a consolidated problem statement is essential to improve team collaboration and stay on task. Your problem statement is also helpful in getting stakeholder buy-in for new initiatives or for planning human-centered design products.
5 examples of design thinking problem statements
Finding design thinking problem statement examples can be tricky since they're not always made public—but that won’t stop us! Let’s review five product design examples and case studies to break down their hypothetical problem statements.
The following examples will use this problem statement formula: (User) needs a way to (outcome) because (driver). Since UX opportunities come in all shapes and sizes, we have more problem statement formulas further down on the page.
1. Audiense
Problem: the Audiense team noticed a sudden uptick in people exiting the sign-up process without completing it.
Example problem statement: New customers need an easier way to complete the sign-up process because they’re getting frustrated during the account setup.
Solution: Juan Fernandez, Head of Product, used Hotjar Session Recordings to review failed sign-ups and saw that the password validator feature was broken. After they fixed the validator, sign-up rates increased.
Read Audiense's full story here.
2. Zenprint
Problem: the Zenprint team used Google Analytics to compare bounce rates across pages to discover which steps in the ordering process were underperforming.
Example problem statement: Potential customers need a clearer understanding of next steps because the current page has a high bounce rate.
Solution: the team used Hotjar Heatmaps to see where people spent most of their time on a page, and assessed whether they should spend time there or not. They witnessed users lingering on the pricing page, so they A/B tested the page's UX design. Ultimately, they chose a design that provides clear steps on how to proceed when users hover over a price. As a result, Zenprint's team decreased the drop-off rate of the problematic page by 7% and increased conversions by 2%.
Read Zenprint's full story here.
3. Razorpay
Problem: Razorpay redesigned their dashboard and incrementally released it to small user segments. When users rated the design as 6.2/10, they knew they needed to improve it.
Example problem statement: Users want an updated dashboard because they’re unhappy with the current version.
Solution: traditional analytics showed the Razorpay team that engagement with the new dashboard was dropping, but they didn’t know why. They asked users who provided a low rating on the dashboard to explain their feelings in an open-ended survey. Based on user feedback, they improved the dashboard design, which resulted in a 40% increase in satisfaction.
Read Razorpay's full story here.
4. Spotahome
Problem: Spotahome heard from a segment of users that updating the in-app calendar was difficult, but the team wasn’t sure what the problem was.
Example problem statement: The landlord user segment needs a simpler way to use the calendar function, but the cause of frustration is unclear.
Solution: the team watched Hotjar Recordings to spot the features users struggled with, which convinced the product team to rework a solution and make the calendar easier for landlords to use.
Read Spotahome's full story here.
5. Yatter
Problem: Yatter is a lead generation agency that wanted to increase conversions on a client’s stem cell therapy website. Recordings revealed that visitors would diligently read the text describing the therapy but then exit the page, leading the agency to believe visitors didn’t trust the company.
Example problem statement: Users need to see social proof because they don’t believe our information is trustworthy.
Solution: the team used Hotjar Heatmaps to identify their most popular case studies, and placed them at the top of the sales page. After adding the case studies, the page’s conversion rate increased by 10%.
Read Yatter's full story here.
3 steps to create a design thinking problem statement
Writing an effective design thinking problem statement requires research and brainstorming before you begin.
Let's go through the three steps to create a problem statement with a mock project management software company to make the process easier to grasp.
1. Identify
Ongoing product discovery is the basis for design thinking problem statements.
Establishing a product experimentation culture or sending out surveys about a particular job-to-be-done (JTBD) gives you a starting point. Ask yourself: what problems are users facing, and which are most important to them? How can we create customer delight?
For our mock project management company, identifying user problems could look like this:
A product manager (PM) regularly reviews recordings of new users going through product onboarding. The PM notices that a particular user segment drops off more than others at Step 3 of onboarding, which is to migrate tasks from their current project management software into the new dashboard.
The product team sends a survey to this user segment with open-ended questions to learn about their goals and challenges.
💡 Pro tip: use the JTBD framework to stop assuming and start asking.
Kyle Luther Anderson, a product management leader and coach, explained that product teams use the jobs-to-be-done framework to identify, then confirm or deny, user assumptions. He says:
“Your organization has assumptions about what the customer wants, about their unmet needs, and what your customer considers a successful outcome. Oftentimes an org doesn't state assumptions explicitly, and many companies are pretty bad about putting those assumptions to the test. The value of using the JTBD framework is what comes from those questions you ask, what you learn in unbiased research, and really focusing on the customer problem or opportunity.”
2. Frame
After identifying an opportunity, you need to investigate further to understand potential causes or paths forward. Nasko Terziev, a Senior Product Designer at Hotjar, recommends teams think of the product narrative and end-to-end user journey to home in on critical moments.
Where are the moments we are doing well? Where are the moments we are not doing well? We can build those moments into a framework that the whole company can contribute to with this storytelling approach. Get the storyboards and feed data from analytics, sales, customer success, and support.
Here’s how our mock project management app could approach this step:
Reference their previous onboarding flow plans
Look for UX trends in session recordings
Gather user feedback on the frustrating points
✍️ Class is in session!
Hotjar has free courses for product managers and UX designers.
Learn how to find insights in Recordings or reveal patterns in Heatmaps, then use what you’ve learned to conduct research for your design thinking problem statement.
3. Outline
Now it’s time to consolidate everything into a design thinking problem statement. Here are five formulas you can use as a starting point:
(User) needs a way to (outcome) because (driver). For example: new users need a way to quickly migrate tasks because they'll cancel their trial if onboarding takes too long.
(Audience) wants (outcome), so we will deliver (product) to achieve (result). For example: new users want to add existing projects to their new account quickly, so we’ll create a way to import data so they spend less time onboarding.
‘How might we’ statement. For example: how might we make adding existing project information faster?
Our users want to (task). How can our product achieve (result)? For example: new users want to add current projects to the app. How can our product make setup easy and enjoyable?
Who, what, where, why. For example: new users want to migrate projects, but they’re dropping off at the current step because input options are limited.
Be open to adjusting your problem statement as you learn
Before we send you off to write the next great design thinking problem statement, we leave you with a few words of advice: be flexible and stay curious—your problem statement should leave room for imagination, experimentation, and change.
Seeing is understanding
Stop guessing: let users show and tell you what they need with insights from Heatmaps, Recordings, and Feedback.
