Improving The Double Diamond Design Process

About The Author

Andy is a design founder turned startup investor and coach. He loves speaking at conferences like Smashing Conf and is a founding member of the Adobe Design …
More about
Andy ↬

Email Newsletter

As a designer, you’re no doubt familiar with the concept of the Double Diamond, that super simple graphical representation of the ideal design process.

Typically you’ll see two squares rotated 45 degrees: the first square will say something like “discover” and “define,” while the second one will encourage you to “explore” and “create.” Each diamond will have a heading, such as “problem” and “solution,” or the more punchy “design the right thing” and “design the thing right.” Along the side of each diamond, there will be a label explaining how you must first diverge, i.e., come up with lots of options before you can converge into a single answer.

It’s one of the simplest articulations of the design process out there. It’s also why many designers hate their jobs. Let me explain…

Note: If you’re curious as to who and when nailed down the Double Diamond concept in its present modern form — which we see being referenced practically everywhere nowadays — check the Appendix at the end of the article (“How do We Describe Design Process?”).

Designers Are Problem-Finders And Problem-Solvers

As designers, we like to think of ourselves as problem-finders as well as problem-solvers. Give us a user challenge, and we’ll use our research skills to uncover what’s really going on below the surface! We’ll take this information, reframe the problem, and come up with an even better solution — one that’s never been considered before. That’s what the double diamond is all about. It’s about avoiding the obvious, shallow solutions and instead freeing us up to be truly creative.

I think the best example of this can be found in the UK TV program , a British children’s television entertainment program created by John Hunter Blair, which is the longest-running children’s TV show in the world.

A few years back, Blue Peter got to interview design legend Jony Ive. They explained to Jony how they’d set a challenge for their young viewers to design a lunchbox, pencil case, and school bag, all in one. He responded by saying that you needed to be really careful not to have the word “box” in the brief because it might determine the path you went down. You could imagine if Jony had set the challenge, he might have asked the kids to “design a means of storing and transporting your lunch to school.” A nice reframing of the problem which didn’t contain the proposed solution!

I’ve been in countless meetings where stakeholders have effectively made the same “mistake” as the Blue Peter presenters when they defined what the outcome should be. And I have seen an equal number of annoyed designers, questioning the point of them even being there if they’re just going to be told what to design and how to design it. (And, of course, they rarely say this to the stakeholders’ faces. Instead, they simply moan about it behind their backs.)

Meet Smashing Workshops on front-end, design & UX, with practical takeaways, live sessions, video recordings and a friendly Q&A. With Brad Frost, Stéph Walter and so many others.

Exploring The Context

Designers understandably feel frustrated when asked to “design a lunchbox” because it immediately limits the potential outcome. This goes against what they’ve been taught design is all about and what design workflow models, such as the Double Diamond claim.

In an ideal world, designers would much prefer to spend time “bathing” in the problem space. This would include wanting to understand the variety of food items kids take to school with them and the level of protection they need. It would also involve following kids’ journeys over a couple of weeks to see how the products are used and talking to kids, to understand what they think is cool, and to their parents, to understand what’s practical. Of course, there’s a good chance that after all this, you might decide that a lunch box is exactly the sort of thing you should be designing! However, rather than this being only a hypothesis, you’ll now have confidence that you’re on the right path.

The architect Eliel Saarinen talks eloquently about the importance of designing a thing by considering it in its context:

As such, it’s natural for designers to want to diverge, even if they end up converging on exactly the same thing. However, for our business partners, this sort of behavior can be very frustrating.

What If You Actually Just Want A Lunch Box?

While designers like to believe they’ve been hired to “think outside the lunch box” (sorry for the pun), the truth of the matter is that most business stakeholders don’t see design this way.

Instead, when most business stakeholders are tasked with creating a way for kids to take food to school, they immediately think of “lunchbox.” They will then ask their industrial designers and graphic designers to come up with something interesting that parents and children will buy; ideally, something which can be made cost-effectively using their existing factories, equipment, and supply chain. Oh, and they need it ready for when the kids go back to school in three months’ time, as that’s peak lunchbox-buying season.

In this context, the organization has already decided that the lunchbox is a perfectly reasonable, logical, and obvious solution, so when the design team starts pushing back and asking for time to do additional research, it sounds like a waste of time. Or worse, it might sound like the design team is actively trying to derail the project. As such, much as I hate to say this, sometimes you’ve just got to grit your teeth and design the darn lunchbox.

How Design Actually Gets Done (Outside Apple And Airbnb)

While the double diamond concept is a wonderful model, it’s also largely a fantasy. Instead, most organizations will have a few meetings which generally won’t involve design (sorry). If you’re lucky, they might look at some external survey data or market data and come to the conclusion that we, too, need a lunchbox.

Getting anything done inside even a relatively small organization takes effort, as anybody who has ever been tasked to organize a team lunch or a short company retreat will know. As such, it usually requires a senior stakeholder to galvanize support. Because of this, “customer discovery” is often more about finding evidence to back up the assertion that this is the right thing to build rather than potentially discovering that it’s the wrong thing to build.

By the time the idea gets to design, the decision has usually been made, resources have usually already been allocated, a launch date may have been set (often arbitrarily and without really understanding how long designing the thing will actually take), and there’s little or no interest in doing anything which might slow this decision train down or derail it altogether. I call this process the reverse double diamond.

While this way of working may seem crazy to designers, in most organizations, this is exactly how things work, and fighting against that process is truly an uphill battle. However, there is an opportunity here if you want to grab it, which lies in the second half of the “reverse double diamond” concept.

The Reverse Double Diamond (Or Making It Work Better)

Now, let me start with this: I’m not claiming that the reverse double diamond is ideal. Far from it. However, it is a realistic model for how work actually gets done.

I also believe there is a way for design teams to slowly — and I really do mean slowly — pivot away from this and towards the traditional double diamond. But you’re not going to get there by adding a couple of slides about it to the design deck your boss asks you to present at the next leadership away day. Instead, it’s all about what you do post-launch.

If you take a close look at the model above, you’ll see that the first part of the reverse double diamond is essentially accepting the status quo, letting your boss tell you to deliver the metaphorical equivalent of a “lunchbox feature,” and creating the best version possible with the time and information available. However, the trick to making the reverse double diamond work is to actively monitor how this new feature performs and — wait for it — make suggestions about how it can be improved post-launch.

Once the lunchbox feature has been delivered and is out in the wild, the stakeholder who sponsored it no longer needs to be protective of it. The problem switches from being a delivery problem (“Can we actually get this thing launched?”) to being a value extraction problem (“How can we make this existing thing work better?”). This is the exact point in time where you put your business hat on, look at the stats, and say something like this, “This feature currently has relatively low utilization of only 5%. However, we believe that with some tweaks, we can get this up to 20%.”

In ye olde days, this used to be called “making a business case,” and it’s frankly much easier to make a business case for something that already exists and you believe can be made better than it is doing research on something that doesn’t yet exist and might be just fine as it is.

In essence, you’re still doing research work, and you’re still going to be exploring a range of potential solutions — you’re just doing this once the feature is already out in the market and you know exactly how it’s performing. Of course, this all depends on a number of things, including how well or poorly the feature performs, how good your design and product leaders are at making a business case, and how much work the design team has on. Unless you’re able to make a solid release plan, it’s likely that the second half of the reverse double diamond will actually be uncoupled from the first.

For companies that have featured teams and growth teams, it’s even possible that your feature teams will deliver the first half of the reverse double diamond before handing it over to the growth team to do the second half. As a result, this process is less than ideal. However, it’s much more pragmatic and goes fine “with the grain” of most organizations.

Iterating Towards The Traditional Double Diamond

Earlier, I hinted that this process might, over time, allow you to get to the “design nirvana” represented by the traditional double diamond. The logic here is that by constantly improving products post-launch, the organization learns to trust the design team’s ability and, more importantly, their vision.

As you garner more trust and evidence, over time, you can start making the case that it would be quicker and more cost-effective if you spent a few weeks upfront trying to avoid the mistakes, which can often take months or even years to address. Mistakes that will also often result in some lost revenue. In fact, this is effectively the same argument many designers make for adopting the traditional double diamond workflow in the first place — you’re just doing so by using evidence rather than belief and theory.

Conclusion

The Double Diamond concept is great, but it’s just not the way most organizations function. If, as a designer, you set your expectations around this theoretical model, you’re going to be continually disappointed! However, designers are meant to be great at understanding how things actually work rather than how we think they should work.

If we want to initiate change, we need to ask for more accurate models of how design actually works inside our organizations and target the areas where we have the most leverage. I believe this means adopting some variant of the “reverse double diamond” idea, accepting that we’re going to be told to deliver “lunch box features” 90% of the time, and shifting our attention away from pre-launch solutions to post-launch solutions.

We can design and then release a good first version of a product out into the world as quickly as possible and then use our business and communication skills to petition for and make measurable improvements to it. And if we can do this consistently, there’s a slim — but tangible! — chance that we can switch the “double diamond” back around.

Further Reading

Appendix: “How Do We Describe The Design Process?”

A short bit of history. In 2003, the Design Council promoted the positive impact of adopting a strategic approach to design and the value of “design management” as a practice. However, they had no standard way of describing the supporting process. Richard Eisermann, Design Council’s then Director of Design and Innovation, thought this was incompatible with their broader message, so he asked his team, “How do we describe the design process?”

Of course, kite-shaped (diamond-shaped) process models have been referenced as far back as the 1960s, but models of the design process were not widely shared at this point. Part of the Design Council’s reason for creating the Double Diamond concept was to address this lack of visibility. Today the Double Diamond is considered a universally accessible description of the design process, has become an accepted part of design language, and is used and referenced worldwide.