A Framework for Problem Solving

I’ve always been obsessive about solving problems. I love to study data and user behavior and identify areas for solutions, and feel like I fixed something that was broken. But I’m also obsessed with the process of problem solving itself. I love to think about what exactly we think about when we do design thinking, and how we arrive at good solutions.

In my time leading Design Ops, I used to run a weekly office hours to help the designers on our team troubleshoot issues with patterns from our design system. For the most part, these were simple questions, like whether to use a dropdown or a radio button, or whether to use an accordion vs. a modal.

But I started to notice a pattern when designers got stuck. A lot of the time when neither pattern worked, or they felt like they needed Ops to create a new pattern, there was a solution outside their scope of focus, they just didn’t know to reach for it. I started looking at the way I was helping them troubleshoot these problems and I realized there was an unintentional method to how I framed questions so that they could look at the problem from different angles. I’d ask questions like:

“What if we asked that question on another step in the flow? Would the pattern work then?” or “What would happen if you moved that checkbox closer to the ‘Submit’ button? Would that solve the visibility issue?”

After a while I realized that most of the time when a designer was stuck thinking about an interaction, they reached for some visual solution like a container or an icon to solve their issue. Or if they needed to bring attention to a piece of information, they’d use an interrupt modal instead of adjusting the page hierarchy.

Designers often use the tools that they’re most familiar using, usually color and containers and icons, and it’s easy to forget there are other ways to solve a problem.

playing by ear

The analogy I often use is that it’s a lot like learning to play an instrument by ear. We’ve learned over time how to get it to sound good, and how to play along with a band, but sometimes we’re stuck in a rut or can’t quite find the right part. If we know enough music theory that we can move to a different key or time signature, or switch up the tempo, that might solve the problem.

This is where the framework comes in.

The framework essentially divides a user experience into levels, starting with visual design at the top, and moving down to narrative flow at the bottom. It’s in the form of a triangle to illustrate how the layers build on each other. For example, you can’t have a page hierarchy without that page existing in the context of a flow.

After workshopping this framework with designers on our team in a few design exercises, I made a few updates and improvements based on how people were applying it and understanding it, and ended up with this final version:

I’ll break down each of the layers:

Strategy

The foundation of the framework is the Strategy layer. This is where it’s really important to clearly define the problem, and the best way to do that is to ask three questions:

1. What’s the problem to solve?
   Ideally, this should be framed up as a user problem, but it can also be a business problem. Sometimes it’s also helpful to frame it up as an opportunity, for example, maybe this feature isn’t broken, but there’s an opportunity to make it even better.

2. Who is experiencing the problem?
   The goal of this question is to identify our key user. How this question is answered can dramatically change the solutions that are explored.

3. What evidence do we have for the problem?
   This question is actually the basis for answering the first two questions. What do we know about the problem? Do we have testing, or user feedback, or competitive research that tells us this is a problem? Does it tell us what specific types of users are having this problem? This question can help us reach the best possible problem statement.

I’ve found it’s really difficult for UX folks to spend time thinking about the problem, because just like nature abhors a vacuum, UX’ers feel really uncomfortable thinking about a problem without trying to solve it immediately.

But it’s really important not to frame up the problem the right way, without tacking a solution on the end (e.g. “the problem to solve is that people need a screen to enter their phone number and address”) so that it leaves the team open to a variety of solutions across all the layers.

(The best way I’ve found of reaching a really solid problem statement is asking “why?” a bunch of times)

Flow

In this layer, the goal is to lay out the current experience in a flow chart, and ask the question, can we change the flow to solve the problem statement we just outlined?

A common exercise I use is to tell people I need them to design an app to order coffee, and then we run through the framework. I’ll use that same example here to illustrate each layer:

This step essentially outlines the problem statement in the form of a flow. It seems overly pedantic to start all the way at the beginning when the user wakes up in the morning, but it’s important to capture what’s happening before our experience begins as well what happens after so that we can look for ways to insert our experience to solve the problem. It can also be helpful to layer in user emotions to understand where the pain points really are, so we can focus our influence there.

This is essentially a journey map, but it can also take the form of a task flow depending on how granular the problem to solve is.

At this point, the goal is to ask the question, “How could we change the flow to solve the problem?”

If we insert alternate routes into the flow we can start to identify potential solutions to the problem of waiting in line. This not only helps us decide if a mobile app is the right solution, but it’s also going to start to inform some of the key features and screens that we’ll design next.

Before moving on to the next layer in the framework, it’s helpful to make sure we’re breaking down each step into appropriate task flows. This makes it much easier to understand what screens need to be designed and what will happen on each of them. It’ll also help inform the order of the steps in the flow when it’s easy to move things around, instead of trying to move steps around after screens have been designed.

In this example, a flow starts to emerge where we can start to care for different tasks and decision points based on the user. This is why it’s useful to really understand what user or group of users we’re solving for. Maybe it’s not just coffee drinkers, but fans of tea as well. It might not just be commuters but people working from home who are a little more flexible, or who might not be driving but walking instead.

Hierarchy

Once the flow is starting to take shape, it’s much easier to start putting together wireframes of screens and understanding what order to put them in. The Hierarchy layer is mainly about order of operations on each screen, and making sure the flow of information is solving the right problems.