The Problem with the Double Diamond

The problem space and the solution space are not two separate things.

In 2005, the Design Council took a look at how 11 different companies handled design problems. They synthesized their findings into the first iteration of the “double diamond” (pictured above). Each diamond is made up of an initial stage of divergent thinking, in which ideas and approaches are explored, followed by a stage of convergent thinking, in which we narrow down those possibilities until we have just one to focus on.

The first diamond focuses on the problem space. Its divergent phase is labeled discover, during which we research the problem and look for all of the various ways in which we can understand it. The convergent phase is labeled define, during which we sift through our research to make meaning from our data and settle on how to precisely define the problem that we want to solve.

The second diamond then focuses on the solution space. Its divergent phase is labeled develop, meaning that we develop solutions to the problem, not necessarily writing computer code. In fact, as a design process, the develop phase usually doesn’t involve any coding; it’s more typically where we see the sort of prototyping and wireframing that we might traditionally think of when we think of design work. The convergent phase is labeled deliver, in which we test our prototypes and settle on one that we have confidence in. As a design process, “delivery” here rarely means delivering a finished product to users; rather, we more often mean delivering a set of high-fidelity mockups to the programmers who will be responsible for implementing those designs as a fully-functional product.

The double diamond has become quite popular as a design process, though it’s been adapted and refined in myriad ways since its introduction almost 20 years ago (including by the Design Council themselves, resulting most recently in their Framework for Innovation). It is indisputably workable, as shown by the fact that there are thousands of design teams using it to complete and deliver work today. But there’s an uncomfortable problem with this process, one that we try to work around and mitigate in dozens of ways, but which lies at the heart of most of the problems that plague us.

The double diamond is a prime example of the building perspective in action. Underlying it is a fundamentally dualistic assumption that would make Plato proud. There is some ideal Form of the problem definition that we can discover in the problem space through careful, rigorous thought. Once discovered, the problem definition will point the way for us to find the solution somewhere in the solution space. The problem space and the solution space are two distinct (though perhaps adjacent) regions in the hyperuranion. No, neither the Design Council nor any other designer I’ve ever read have put it in those terms exactly, but that’s the unspoken premise that this process rests upon: essence precedes existence, and therefore design work is a matter of first finding the best idea, and then faithfully bringing that idea into reality; or, design the right thing, and then design the thing right.

The problem space and the solution space are not separate things. There is no separate realm of Forms, and (just as Sartre insisted), existence precedes essence. Anyone who’s tried to follow the double diamond has faced the challenge of how work in the second diamond has raised new perspectives, challenges, and ideas that simply weren’t considered in the first. Junior designers often take this as a failure, a sign that we weren’t sufficiently thorough in discovery or definition. But when you’ve followed this process enough times and seen it happen every single time, you start to understand the truth: you will always learn new things about the problem by working on a solution. In fact, there are many things that you can only learn about the problem by working on the solution. No amount of research or consideration will surface some of these aspects of the problem; they can only be found by working through a solution.

Just as the problem space illuminates and reveals the solution space, so too does the solution space illuminate and reveal the problem space. The double diamond is a great reflection of the way we often think of innovation happening, but it’s not the way that it actually happens.

Even with that, isn’t it still a bit hasty to discard a framework as tested and proven as the double diamond? After all, we could just feed the solution of one iteration as the problem for the next to solve. We’d want to tackle smaller problems with this approach, building up iteratively to a finished product, so rather than a double diamond, it might look more like a string of pearls.

This really is a vast improvement — and it gets us close to what’s called dual track agile. This is an extremely common approach to squaring the circle between traditional UX methods and agile development. The UX team iterates on a double diamond process that’s scaled down to fit into a two-week sprint aimed at providing developers with high-fidelity mockups to work on for their next sprint. A lot of the “best practices” of modern UX are based on this model, like the advice that UX teams should be a sprint ahead of development teams.

If the UX team and the design team are working in two-week sprints, this is really a four-week sprint with a large, dysfunctional team that has trouble communicating. Scrum is all about the feedback loop. Its goal is to get something out into the world so that you can start getting feedback on it. With this approach, the interaction designer track takes a two-week sprint to develop mockups, and then the developer track takes a two-week sprint to implement it, so that feedback loop — the real sprint — is four weeks. That’s how long it takes for a new idea to get out in front of users who can start telling us if it works or not. Prototyping and user research can increase our confidence, but we won’t really know for sure until it’s out in the world. We’re still using dead-drop handoffs instead of working together. We’re still trying to strictly separate the problem space from the solution space, with separate teams dedicated to each.

This is what Jeff Patton calls “duel track agile.” While the tracks are generally depicted as two in diagrams, though, Jeff quotes Desirée Sy, who writes:

In addition to keeping in touch with the whole Agile team through the daily scrum, we work with developers very closely throughout design and development.Although the dual tracks depicted […] seem separate, in reality, interaction designers need to communicate every day with developers. This is not only to ensure that designs are being implemented correctly, but also so that we have a thorough understanding of technical constraints that affect design decisions.

Sentiments like these seem related to the value that designers bring by being active participants in mob programming. In the opposite direction, we’re starting to see the benefits of including developers directly in user interviews and other UX research activities. Stating it from the other side, the more we divide designers and developers, the less both teams accomplish. To be successful, we need cross-functional teams — and the closer we get to that goal, the more successful those teams will be.

Jeff admits that “there are two kinds of work, and there’s no way around it.” He calls these two types “discovery work” and “development work” (echoing the double diamond’s phases, you might notice). He emphasizes that these are two tracks, but not two teams:

[Y]ou shouldn’t think of it as two processes — just two parts of one process. And, I think you’re doing developers and others on the team a disservice not to involve them in discovery work.

This is as important an improvement over the common model that Jeff calls “duel-track agile” as that was over the older double diamond dead-drop approach. And yet, I’m pulled back to something he writes when discussing the fundamental difference between discovery work and development work:

If you’ve worked in Agile development before, you know teams will talk a lot about velocity. But the velocity they’re talking about is development velocity.

The primary reason why businesses adopt Scrum or undergo an agile transformation is the promise of increasing development velocity — to ship more code more quickly. But this is not what agility is about. As Allen Holub tweeted:

The first principle of the Manifesto for Agile Software Development makes its purpose quite clear:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Yes, there is a focus on delivering earlier and more continuously, but as a means to an end, not an end in itself. The end is to satisfy the customer. Delivery is the means because it’s understood that the problem space and the solution space are not separate things. There are parts of the problem space that we can only discover by working on the solution. This is a model built on the dwelling perspective. Which means there aren’t two different types of work. The reason that you need the design team to be so deeply involved in development and the development team so deeply involved in design is that the separation into two different teams is as artificial and illusory as the separation of two different kinds of work. We all already know that we can only deliver what we’ve discovered, but there are some things we can only discover by delivering.

So if diamonds aren’t our best friends, might we find some help from a superior polygon?

Stanford’s d.school has publicized a “design thinking process” that is nearly as well known as the double diamond, illustrated by a series of five colorful hexagons.

You’ll notice some overlap with the phases of the double diamond — “define” is a stage in both under the same name, while “discover” has a great deal in common with “empathize,” “develop” with “ideate,” and “deliver” seems to be broken up into separate “prototype” and “test” stages.

While arranged in this specific pattern to imply a common linear process, an important point of this model is that there is no x-axis here measuring time, as with the double diamond. The d.school design thinking process is a non-linear one.

As Rikke Friis Dam writes:

This is one of the main benefits of the five-stage model. Knowledge acquired in the latter stages of the process can inform repeats of earlier stages. Information is continually used to inform the understanding of the problem and solution spaces, and to redefine the problem itself. This creates a perpetual loop, in which the designers continue to gain new insights, develop new ways to view the product (or service) and its possible uses and develop a far more profound understanding of their real users and the problems they face.

(Bolding in the original text.)

The stages of this model provide a frame of mind and a distinct set of tools and techniques for doing particular parts of design work, but which stage will follow depends on what you find. This is a stronger foundation for a great design process precisely because it’s not much of a process. It doesn’t tell us how to solve design problems; rather, it simply reminds us of the tools that we have at our disposal, expecting us as designers to understand the challenges we face and to know which tool to pick for the job in front of us at any given moment. This is a process for those who understand that design is an argument, and are willing to embrace all of the awesome epistemic freedom that comes with that.

And yet, even this can become prescriptive. As Carissa Carter wrote for the d.school itself:

The problem with the hexagons is that they’ve created the design process, and that sounds grand and all encompassing, but in reality they are just a first recipe, a suggestion for how to get started. Behind the hexagons are a starting set of tools to experiment with in each of those modes as well as a set of mindsets and behaviors to embody and try on while doing them. While it is sometimes useful to give students a recipe experience with their first encounter with design, I see our most exceptional instructors creating the tools and experience arcs they need specific to the projects and learning goals of the moment.

The most successful digital products today are released multiple times per day. Some are released multiple times per hour. Amazon is releasing new code every 11.7 seconds. The double diamond is a process that’s oriented towards a world paced in releases per year, not releases per minute. Continuous delivery has already changed the way that digital products are made, but its real promise remains unrealized. When we have a discovery process that’s as continuous as our delivery process, we can create super-powered feedback loops. Imagine implementing a user story on Monday, shipping it before you log off for the day, and having user feedback and usability testing results to go over Tuesday morning — which, of course, would point out which user story to tackle next.

Teresa Torres has been championing the concept of continuous discovery to do something very much like that. She writes:

The best teams, however, are recognizing that digital products are never done. We can always iterate and improve. Facebook and Netflix will never be finished projects. If they stopped iterating and developing, their competitors would catch up.

Which leads us to the clear conclusion:

While there’s nothing inherently wrong with project-based research, it’s not sufficient for teams who continuously ship value to customers. The key idea is this simple: If we are continuously making decisions about what to build, we need to stay continuously connected to our customers, so that we can ensure that our product discovery decisions will work for our customers.

UX designers often say that Scrum is unrealistic, because there’s no way that a great design can be finished in a two-week sprint. Researchers claim that there’s no way that they can come to a full understanding of who the users of a product are in a two-week sprint. They are, of course, absolutely correct — just as correct as the software architects who claimed that Scrum could never work for software development, because there’s no way to build a functional database layer for the entire project in a two-week sprint.

If you’re trying to do the whole thing in one sprint, you’ve missed the point of sprints. You shouldn’t try to build the entire database layer for your application in one sprint; you build a single vertical slice. You build just one thing but a complete thing from the user’s perspective. That might be nothing more than the login, but it’s the complete login: the frontend, the backend, the database — and yes, the user flows, the design, and the usability testing, too. The art of it is figuring out what the thinnest slice is that your team can cut that’s still an entire slice.

If you’re having a hard time wrapping your brain around how that could possibly work for real UX work, don’t worry — it took your colleagues on the development team a long time, too. Many (maybe most of them, if we’re being honest) are still struggling with it. It’s not easy, but that’s not because this is an idea ill-suited to design. We were all taught to see our work from the building perspective. Switching to the dwelling perspective is a challenge for all of us. The reward for that effort is an approach that’s better aligned with the reality of the creative process that yields better results, better products, and happier users.

We’ll get into the specifics of how design can be reimagined in a continuous world in a future article, but for now I’ll leave you with one of Teresa Torres’s favorite challenges: instead of thinking about discovery as a phase in your project plan that you conduct and then move on from like the double diamond says, start talking to someone who’s actually using your product (or will use it) every single week. Invite the developers, too. See what happens.