Framing the problem

Framing the problem is a document created at the beginning of a project to define exactly what you’re trying to solve.

It acts as a north star throughout the UX process to provide clarity and focus on what we actually need to solve.

Framing the problem has 6 steps:

1. Define the general problem you're solving from the business and user perspective
2. Create a design question (also called a "how might we..." question
3. Describe the impact of solving this problem for both the business and users
4. State your assumptions associated with the problem (true or not)
5. List out all of the questions you need to answer to properly solve the problem
6. List out all constraints that are associated with the project

Framing the problem is a living document that might change along the way as you gain a deeper understanding of the user.

Go to the Framing the problem tab in the Figma workbook.

Then, complete framing the problem for REI (brought up in the project brief).

Hey, what's up Kickass Fam? 

So what's the one thing you have to do regardless of the UX project? 

Framing the problem.

It acts as the north star throughout the UX process. It provides clarity on what needs to be solved. And without it, you would most likely solve the wrong problem.

After this lesson, you will complete the framing the problem exercise in the Figma workbook. 

So if you don't have your workbook yet, don't forget to go download at kickassux.com under the free UX course page. 

In this lesson, you'll learn how to frame the problem, a process that provides focus and clarity for your project. 

The framing of a problem is often, far more essential than its solution." Albert Einstein. Before designing anything, you need to have a solid understanding of the problem that you're solving.

To get that understanding, you need to truly define the problem.

What is it that you're solving exactly. 

Without scoping the problem and providing context for what you are after, you'll lose track of what and who you're designing for.

Imagine if you were flying from New York to Warsaw Poland. If the plane was aimed even one degree off course, you could end up in Romania getting eaten by vampires. 

In UX, the same thing happens if you don't frame the problem correctly. 

If you don't truly understand the problem, you could end up building the wrong solution. At the start of many UX projects, UX designers conduct what's called a stakeholder interview.

These are one-on-one interviews with people such as the product manager, developers, UX manager and any other stakeholder who has a vested interest in the project's outcome. 

In each interview, you record their beliefs, assumptions, and questions to help gain clarity on the direction you will take to solve the problem.

Stakeholder interviews are great and a super helpful. However, we have a faster way of accomplishing this. 

Our method gathers stakeholder opinions, assumptions, and questions with everyone in the room, instead of the time consuming one-on-ones

It's called framing the problem. Framing the problem is a document that we create at the beginning of a project. This includes a few simple steps to gain clarity on the problem we're trying to solve and what outcomes we'd like to see.

In your situation, don't worry about the fact that you're doing this on your own. That's totally fine. 

In the future, you will work with others on your team to produce a document like this. 

Framing the problem has six steps.

The first step is to define the general problem you're solving from the business and user perspective. Based on what you already know about the problem and what you learned during the industry and competitive analyses, write the general problem that you're solving from the business perspective. 

This could be lost revenue, lower user retention, or a missing feature that other competitors have.

 Then think through the problems users are facing and what they're feeling as they're going through the experience. 

You can look at product reviews, forums, or even talk to real users to learn more about how real users feel about the product experience.

Step two, you'll create a design question also called a "how might we" question?

 "How might we" is really important? " How" implies that this problem is solvable. " Might" implies there are many possible ways to solve the problem. And "we" implies that we all going to work together to solve the problem.

While you'll be completing this by yourself in the future, it's best to do this with a group to get multiple perspectives. 

Basically, you fill in the following sentence: "How might we [insert goal you're trying to have on users]."

The third step is to describe the specific impact you hope to have on the business and users. 

For example, maybe on the business side, you want to see increased engagement with this new feature or increase revenue or increased product stickiness, meaning customer retention. 

Step four, state your assumptions associated with the problem.

These are things you believe to be factually the case for your product. Stating your assumptions does two things. 

Rather than keep this information in your head, it lists out what you and other teammates believe to be certain and allows you to analyze them from a more unbiased viewpoint.

And two, it helps you decide whether or not these are things you need to validate through research.

For example, let's imagine we're working for Airbnb and we're working on a new feature that helps people plan trips with others using Airbnb. One of our assumptions may be that we believe people expect to be able to split the payments with others using Airbnb.

By listing this out, this helps us evaluate whether or not we need to do research on a specific problem. 

In our experience, most things that end up in this category on a given project, don't end up getting researched. 

That's what the next step and section is for.

Which leads us to step five: list out all of the questions you need to answer to properly solve the problem.

What don't you know about the problem? What do you need to learn to be able to move forward? This step is important because these questions form the basis for your research.

You'll need to answer all these questions to effectively design the solution to the problem. 

For example, using the same Airbnb example about planning trips with others, maybe you are uncertain whether people would actually communicate with Airbnb, or if they'd use outside communication methods like email or text.

That would become a question that we need to answer through research. 

Answering that question will help you figure out whether or not you have to build an internal chat tool specifically for communicating with people to plan a trip.

The final step is to list out all the constraints that are associated with the project. 

 For example, this could be tight project deadlines or a lack of staffing resources to accomplish the feature. In your case, your constraints could be the fact that you are working on your own and don't have a team of funding to complete the project.

And that's it.

Sometimes the insights you gain from your research will indicate that you actually framed the wrong problem. At this point, you'll come back to the document and rewrite it to reflect the problem that you are now trying to solve.

 In other words, framing the problem is a living document that might change along the way as you gain a deeper understanding of the user.

To recap, framing the problem is a document created at the beginning of a project to define exactly what you're trying to solve. 

It has six steps starting from defining the problem to listing out constraints.

Now, it's your turn to frame the problem. 

Go to the framing, the problem tab in the Figma workbook and use the worksheet to frame the problem. 

You'll see a transparent frame in Figma that has our answers to framing the problem. 

We recommend that you don't look at it until you've done it yourself. 

Then when you finish doing it on your own, you can go and see how your work compares.

Happy framing.