Understanding the concepts of problem space and solution space is crucial for achieving exceptional product outcomes. While these two realms are intricately intertwined, designers often underutilize their potential.

# ☕ Problem space, solution space

Problem space and solution space are two terms every designer seems to just get. While in practice these two are closely intertwined, to get great product outcomes, it’s crucial to keep in mind both sides of the coin.

To be very simplistic, problem space defines the set of possible problems the team is working with. Problem space would most prominently contain the user needs the user is not even aware of. Its borders are usually quite uncertain, but most of the work happens in the parts which are better known.

Solution space defines the set of possible solutions the team could go after. This includes the user needs that are already known, understood and should be solved.

Both of these are usually defined and constrained by what the company does and some other factors, like how some solutions are not viable because of regulatory or ethical reasons.

Double diamond is one of the more well-known representations of these two concepts. The first diamond represents the problem space and the second diamond the solution space. Since a lot of teams are working with the double diamond, this gives a framework for how to work differently with the problems and solutions.

Even if a team is not using the double diamond, it’s worth thinking about these two spaces when setting up their approach.

The design process should start with defining the problem space, clearly articulating what are the set of problems to focus on. These would be the core challenges and constraints that need to be understood to solve the problem. This provides a shared understanding within the product team.

Working in the problem space would involve user research (most prominently user interviews), journey maps, and personas - these drive the exploration and further ideation. Both wide (uncover further sets of problems) and deep (uncover more details about problems) exploration should be done.

The solution space can be explored based on the understanding of the problem space. This would usually mean generating diverging ideas and concepts, up until the concept becomes clearer, and the design can converge to the final solution. The problem space is explored mostly with prototypes, trying out different ways of solving the problem.

If this all sounds a bit idealistic, and maybe a bit waterfall-y, it’s because in practice the process is rarely this clean.

The problem with double diamonds and with the above description is that it hides how deeply these two spaces are intertwined. The problems and solutions are not completely separate things. A problem can be solved in a variety of ways, while a solution can solve multiple, often not closely connected problems at the same time.

Iterations are a way to resolve it, going through problems and solutions multiple times in quick succession (remember all those back arrows in most process illustrations?). While this sounds good in theory, and usually nobody would say iterations are bad, establishing a good cadence to achieve thorough iterations is difficult.

In a real design process, things get even more murky. Exploring the problem space often uncovers new regions in the solution space. On the other hand, working with the solutions helps a better understanding of the problem space. The two spaces should be explored in parallel, rather than serial.

When we talk about product discovery, so what’s the right product to build, this is what it means. The team will discover both the problem and the solution holistically at the same time, exploring how the shape and the topography of these spaces. The plan for this exploration is the strategy for the project.

The holistic view comes from cross-functional collaboration (within and beyond the product team). Working within the two spaces not only defines the methods to use but also the flavor of collaboration. While product trios need to work together closely through product development, the amount of effort spent will differ depending on the current activity.

Problem space exploration would be more driven by the designer and the product manager, while solution space exploration would be driven more by the designer and the engineer. This gives the product trio a rhythm to work with.

Keeping in mind both spaces, while exploring them at the same time is where things get challenging. Product teams, and especially designers will need help and direction from the design leaders to make sure the exploration is exhaustive and a holistic view of both spaces is maintained.

### 🥤 To recap

- Considering the problem space and solution space together to guide the design process is integral for better product outcomes.
- The problem space defines the set of problems to focus on, including user needs that may not be consciously recognized. User research, journey maps, and personas drive exploration in the problem space.
- The solution space is explored based on the understanding of the problem space. Diverging ideas and concepts are generated, leading to converging on a final solution through prototyping and testing.
- The double diamond model represents the problem space and solution space. While it provides a framework for working with problems and solutions, it’s important to recognize that these spaces are deeply intertwined.
- Iterations and parallel exploration of the problem space and solution space are essential. Cross-functional collaboration helps maintain a holistic view. Design leaders play a vital role in guiding and supporting teams to ensure exhaustive exploration and a holistic perspective.

This is a post from my newsletter,

9am26, subscribe here:

# 🍪 Things to snack on

**Daniel Mescheder** describes the problem and the solution spaces in a simple, although a bit technical way in **Problem Space and Solution Space**. Both have points that represent the problems and the solutions respectively, and each point might be grouped with other points, related problems, and solutions. The difficult part is how to connect the solutions and problems, and how connected problems might not have a connected solution and vice versa.

🁃

**Teresa Torres**’s opportunity solution trees are a great way to give structure to the problem and solution spaces and provide a map to explore it, also guiding product discovery. **Why This Opportunity Solution Tree is Changing the Way Product Teams Work** describes this method.

🁃

One of the innate challenges in thinking about the problem and the solution space is how closely the two are connected. **Jason Godesky** writes about this challenge in **The Problem with the Double Diamond**. Even when working on the solutions, one can learn new things about the problem space. This is where the dual-track view of agile becomes useful, both types of work need to happen at the same time.

🁃

**User Research Only Covers Users** is a thoughtful critique of how most user research focuses on the solution space by **Indi Young**. Since by definition talking to users puts the existing solution in front and center, only the borders of the solution space will be explorable. To explore the problem space, the person needs to be in the middle, which is an approach from future research. This keeps organizations from figuring out new directions.

🁃

While **Jared Spool**’s **Exploring the Problem Space Through Prototyping** is more about prototyping, it highlights how solution space and problem space might be explored at the same time with the right tools. The article has some good ideas on how prototypes explore the three dimensions of problem space: technology, business, and users.

🁃

I liked **Problem space. Shipping space.** by **Mark Boulton**, describing how some organizations might be more focused on problem space not only because it seems larger and more interesting, but also by the very nature of the field they are in. Design leaders need to balance and guide the teams and projects to have an equal focus on both spaces.

## Comments