Why we start with user problem statements at Pinterest

You can’t solve a problem if you don’t know what the problem is

Does this sound familiar? You’re put on a new project at work — one with clear business use cases and the potential for huge impact on your team’s goals. Yes! You review the project brief, talk to a few cross-functional folks, take some notes and sketch out some ideas. But then, when it’s time to fire up Figma and start designing, you find yourself asking, “What I am trying to do here?” You go back to your brief. WOW! So much information. So many opinions. You think you got it. Back to designing. Wait…do you got it? Look at the brief again. Ugh! Your eyes cross. Your head spins. Hours go by….

If this is familiar to you, chances are you’re trying to design before you have a clearly articulated user problem.

Stop! Let’s try a different approach.

You can’t solve a problem using your awesome design skills if you don’t know what that problem is. You need a well documented, clearly articulated, user-focused problem statement to help you (and your collaborators) establish a path forward.

Find the user problem

A user problem is any point of confusion or frustration that a user experiences when trying to complete a task. In some cases, a user problem can completely block the user’s ability to complete a task.

If you can nail the user problem at the start of the project, your team will be better able to scope the project properly, create healthy constraints, and increase your velocity.

How it works at Pinterest

At Pinterest, I work as a design lead on the Business Growth team, whose goal is to grow the number of businesses that find success on Pinterest. More specifically, my team focuses on the small-to-medium size business (SMB) experience. A SMB usually starts off as a user who converts their personal account to a business account — meaning they gain access to Pinterest advertising products and can start promoting their Pins to a wider audience.

Today, SMBs on Pinterest use a specialized dashboard called Business Hub (Bizhub) to learn how to take core business actions (like creating ads, or installing a Pinterest tag on their websites), view analytics and leverage business insights to build greater success on Pinterest. But this was not always the case! In the dark days before Bizhub, new SMBs on Pinterest went through a sign-up process, got a little lesson on how to make a Pin, got dropped into the Consumer homefeed experience, and were then left to fend for themselves as they tried to navigate between Consumer and Business experiences. We were failing our SMBs!

In order to create a better experience for our SMBs we had to first articulate the problem(s) they were facing. Here is the story of how my team did just that.

Get the right input

In the words of Erika Hall, co-founder of Mule Design:

“The quality of your question determines the utility of the results.”

I believe this to be true of problem statements as well. I always aim to start every project off by consulting with my cross-functional stakeholders. As a designer, I work with product managers who help uncover problem areas within our product; researchers (both quantitative and qualitative) who help frame those problems and put them into context with insights from users; and engineers who lend technical expertise to the problem at hand and help us to understand what’s actually possible within our product. All of these roles are essential when it comes to asking how we might better serve our users. We need to make sure that we are asking the right questions of each other and that we’re keeping each other honest about what experience we are trying to improve for our users and what is actually doable. In doing this, I can ensure that I am using my time to explore solutions that we can actually execute.

In case you weren’t reading between the lines there, I mean to say: Gathering requirements and testing the feasibility waters will save so much time and headache later on, it will also build trust.

Converge on a useful problem statement

Here’s a quick formula I used to get the conversation going with my cross-functional friends when we started working on Bizhub:

Yeah, it’s a little vague. I hear you. Let’s blow it up together…

Who

Name the user you are trying to help. In the case of Bizhub, the users we wanted to help were our SMBs.

Problem

Name the most important problem your user is experiencing. It’s likely that your user is facing more than one problem using your product, and you can’t solve them all in one fell swoop. It’s important to focus on just one issue. Prioritize the most important problem and get alignment with this asap.

Again in the case of Bizhub, the problem was that new SMBs on Pinterest were sent through a sign-up experience and then dropped into their consumer homefeeds with little information or direction on how to get to or use the Pinterest business products they just signed up for.

Goal

Name the goal the user is trying to achieve. In our case, the SMBs need to manage their business and perform lightweight actions such as view analytics and create content. Goals can be tied to the person’s goal, a business objective, or the product’s goal.

You can use the formula above to develop a statement that now has the user, problem, and goal in mind. Here’s a tip: it helps if you state this problem from the perspective of your user.

Like this: “As a SMB on Pinterest, I don’t know where to go to create and promote my content, or see how my content is performing on Pinterest.”

Important tip: Remember earlier when I mentioned working with your cross-functional friends, and all that stuff about the quality of your questions and the utility of your results? Talk to your researchers! Very often, they can provide a perfectly stated user problem, straight from the mouths of users themselves!

In the goal above, our team wanted to focus on creating a unified space for our SMBs to manage their business, which to date had been SO scattered across our business ecosystem.

From UX research, we knew that SMBs struggle with advanced marketing actions such as creating campaigns and viewing complex charts and trends. SMBs are usually small business owners that not only make their products or content, but do all of the marketing themselves. Our advertising management platform and analytics tools are complex and are typically used by more experienced marketing teams. We built out tools that were more suited for smaller advertisers that helped them quickly promote instead of run extensive ad campaigns, but it was still scattered and difficult to find within the advertising ecosystem.

Remember: a user problem and a problem statement are not the same thing.

This is a common misconception.Getting to the root of a user problem is an important step in writing a problem statement, but is it not the end-all. We’re not quite there yet.

Avoid being too prescriptive in your problem statement

This is NOT a user problem: “As a SMB on Pinterest, I need an analytics dashboard view to create and promote my content and see how it’s performing.”

First of all, no user talks like that. That’s your own business jargon getting in the way. Second, in stating the user problem like that, you’ve already decided what the solution is. In the case of Bizhub, we did end up designing a dashboard for our SMBs, but we also explored and tested several other ideas as well. If you go into your project without considering the user problem it’ll be difficult to understand and prioritize components of that feature. If you go in with something too prescriptive you run the risk of not fully exploring design solutions.

Leverage your problem statements with “How might we…”

Using the How might we… prompt fosters a collaborative approach to solving a problem and it allows the team to naturally ideate so they can start to develop ideas around how to solve that problem. It prompts the team to solve the problem and take action.

In the case of Bizhib, we considered the following:

How might we

• Do this
• Do that
• Do something else entirely

Notice how our how might we… questions consider different types of SMB goals: personal, business, and product. In doing this, we were trying to keep in mind how multi-faceted our SMBs needs are, as well as keep an open mind about different approaches to addressing the user problem.

Pressure test as you go

If you are aligned on the problem statement as a team, it’s time to move to the next step in your process, whether it’s ideation or presenting the problem to get buy-in within your org. Problem statements should generally have data whether qualitative user pain points and/or quantitative data to back it up. And they should also be pressure tested over time to see if it still holds true.

It’s time for you to practice making your own problem statements. Go back on some of your old projects, and see if you can apply this framework! Did your problem statement change? Was it easier to explore ideas?