• 8 hours
  • Easy

Free online content available in this course.

course.header.alt.is_video

course.header.alt.is_certifying

Got it!

Last updated on 1/10/20

Define the Problem

Log in or subscribe for free to enjoy all this course has to offer!

When approaching any design challenge, it's crucial to know you're working to solve the right problem. Otherwise, you waste time, money, and energy designing and building something that your users neither want or need. This chapter addresses a few different ways to approach getting to the root of the problem in order to define it.

Double diamond

The double diamond is one way of exploring the design process. It was first suggested by the British Council, but has been developed over time and re-imagined by various designers. It's broken down into four phases: discover, define, develop, and deliver. It's crucial to do enough research to ensure that you both arrive at, and work to solve the right problem. 

Double Diamond visualized by the British Design Council.

The first phase is considered divergent thinking, where research and observations uncover insights into the problem. This phase focuses on discovery and casting a wide net of possibilities. In the convergent thinking phase, ideas are refined in order to define the problem. Divergent thinking occurs again once the problem is defined. This phase helps to develop lots of ideas and concepts (possible solutions). Finally, during the converging state, everyone works towards building and delivering the product, service or desired outcome.

In the double diamond approach, the first diamond is focused on finding and defining the right problem, while the second diamond focuses on finding the right solution. After researching your target users, create a statement which clearly defines the problem. The design team needs to keep problem statements in mind as they imagine solutions.

Are you solving the right problem?

An article in the Harvard Business Review asks, "Are you solving the right problem?"  This question applies to both business and design. In UX, you need to question what you're working on, and why. Defining the problem is a way to make sure you're not only solving the right problem but that everyone on your team is working towards a common goal. Taking the time to clarify the problem up front is going to make the entire process run smoother because you know you're working towards solving the right problem. (This will become even more apparent in the course on design research!). 

For instance, a client may come to you saying they need you to design an app because "everyone is doing it!" You interview users and find out that the majority of their base only use the service from their home computer. This is a good insight to have early in the process! It doesn't mean the project is off - it just means you may have to think about it differently. You may still end up building an app, but it also means you may need to pay extra attention to onboarding new users. First, you want to get to the root of the problem. You'll do that through research, which we'll explore more in another course.

Often we are presented with a scenario that we take as fact. Remember, in the design process it's OK to question everything. The way a problem is framed can impact the solutions. You also want to make sure you're solving a problem as it relates to users

If you approach the problem as "we need to build an app," you've already arrived at an outcome of sorts. However, if you ask the question "how can we get more users over the age of 60 to use our product?" you'll arrive at more possible solutions.

One of the best ways to ensure you're solving the right problem is to figure out the right questions to ask. One simple way to do this is by asking the "5 WHYS?" This just means that you don't take the first answer at face value. You dig deeper and keep asking why to help gain more insights.  (It's totally acceptable to ask questions that don't start with why, but it's a good framework to make you think.)

Here's a scenario where you want to learn more about the habits of someone who makes online purchases:

What was the last thing you purchased online?

- A book

Why did you buy it online?

- It was a specialty book.

Why didn't you have your bookstore order it for you?

- I like to support local businesses, but this time I need it for an event, and last time I ordered a book through them, it took over a month.

Why do you like to support local businesses?

- It makes me feel good to support the local economy. I also like seeing independent boutiques, rather than only big box stores.

Why don't you like big box stores?

- They're void of personality and make it hard for small businesses to survive.

"How might we...." is a popular question to ensure that you're keeping your topic open-ended and envisioning many solutions.

Writing a problem statement

The problem statement is the one phrase you return to throughout the design process to ensure you're staying focused on the context and end goal. You'll minimize "feature creep" (adding more elements that were never part of the initial goal), and you'll have a point of reference to ensure you've achieved you're desired outcome.

The catch in writing problem statements is that you don't know what the solution is yet. You want problem statements to be succinct and to the point, since the designer must work through the data, research, and information at hand to pinpoint and prioritize issues.

When writing problem statements, here are a few considerations, and how they can be improved:

DON'T SAY: Emily wants an app to chart the amount of time she works. (It's too soon to find solutions!)

BETTER: Emily is a freelancer and enjoys working from home, but she finds she easily gets distracted.

DON'T SAY: Lucien wants a newsletter to learn design. (This is an assumption without context, and need to be refined.)

BETTER: Lucien is a programmer who enjoys design, but he doesn't have time to devote to it.

Once you have done your research and analyzed your findings, the problem statements will become clearer. Keep referring back to your problem statement throughout any project! It will help keep you on task.

Example of certificate of achievement
Example of certificate of achievement