Improving The Double Diamond Design Process
Email Newsletter
Weekly tips on front-end & UX.
Trusted by 200,000+ folks.
Flexible CMS. Headless & API 1st
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.
“The formulation of a problem is often more essential than its solution, which may be merely a matter of mathematical or experimental skill. To raise new questions, new possibilities, to regard old problems from a new angle, requires creative imagination and marks real advance in science.”
— Albert Einstein & Leopold Infeld (via: “Using the Problem Reframing Method”
I think the best example of this can be found in the UK TV program Blue Peter, 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.)
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:
“Always design a thing by considering it in its next larger context — a chair in a room, a room in a house, a house in an environment, an environment in a city plan.”
— Eliel Saarinen
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.
Question: How many UX Designers does it take to screw in a lightbulb?
Answer: First, we need to undertake a six months long project understanding the role of light in society!
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
- “Should You Create An MVP Before Creating An App?,” by Suzanne Scacca (Smashing Magazine)
Apps are neither small undertaking nor cheap to build and maintain. So, before you move ahead with creating a new mobile app or SaaS for your client, perhaps you should consider launching a minimum viable product (MVP) instead. With an MVP, you have a low-risk and lower-cost way of testing your concept on the market. What’s not to love about that? - “Getting Back Into The (Right) Deliverables Business,” by Rian van der Merwe (Smashing Magazine)
“Get out of the deliverables business” has become quite a mantra in the lean startup and UX movements. There’s much to love in that sentiment. After all, for every wireframe you make, you’re not shipping code to customers. But just like with the concept of a minimum viable product (MVP), it’s likely that we’ve taken this sound advice to an extreme which actually is hurtful to the creation of good products. What follows is the author’s account of navigating these stormy design seas together with the community. - “Design Thinking & Minimum Viable Product: Is This the Right Approach?,” by Masha Panchenko (Eleken Blog)
Design thinking has become a highly popular approach during the last forty years. It is used in IT, business, education, design — literally everywhere. There is even a book about applying design thinking for personal use called Designing Your Life. We don’t know if design thinking will help to change your life for the better, but what we know is that design thinking is a great approach when it comes to building a Minimum Viable Product. - Designing Your Life, a book by Bill Burnett & Dave Evans
A book that shows you how to build — to design — a life you can thrive in at any age or stage. Designers create worlds and solve problems using design thinking. Everything in our lives was designed by someone, and every design starts with a problem that a designer or team of designers seeks to solve. In this book, the authors show us how design thinking can help us create a life that is both meaningful and fulfilling, regardless of who or where we are, what we do or have done for a living, or how young or old we are.
(Editor’s Note: This book was, in fact, also recommended to me by Joshua Mauldin a while ago, and I cannot but highly recommend it to everyone! It’s a fantastic, very useful read. — M.B.) - “Using the Problem Reframing Method,” by Sebastian Straube (product management & discovery coach at Accenture Business Agility)
Avoid jumping directly into solution thinking and not empathizing with the problem itself; looking at a problem from different angles helps to build more innovative, sustainable solutions, and you need to try different reframing practices and methods as there is not a one-size-fits-all approach. - “Is UX Research About ‘De-risking’ Design?,” by Jonathan Baker-Bates (UX architect at LBi, VP of UX at TES Global)
Is UX research centered on helping designers predict eventual outcomes of design interventions, or is its role to “de-risk” UX and business ideas? Research is often framed as a way of lowering the risk to the business (this applies both to design validation as well as to exploratory research), but research should be checking whether what we said about a given intervention actually tends to happen. - “Modern Double Diamond design: Rethinking a classic design process,” by Victory Brown
To accomplish your tasks, you’ll need to set up a process that will allow you to complete them quickly and also give the best results. Sometimes the design process can be a jungle of trends and patterns; it involves a lot of back and forth to produce the best design solutions. No design is the final design, and every procedure can be iterated on. This is why the Design Council came together in 2005 to develop a new approach to designing solutions with creative thinking, systems design, and design management in mind: the Double Diamond design process. - “History of the Double Diamond”
This article describes the history behind the Double Diamond concept, created by the Design Council (established in 1944 by Winston Churchill’s wartime government). Over the course of several sessions, the group came up with a simplified way to describe any design and innovation process. It is based on four distinct phases that the design team, deliberately seeking a memorable device, named Discover, Define, Develop, and Deliver.
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?”
“The team put in the work trying to define design, process, methods, etc. What we did with the Double Diamond was codify it, rename the steps, and popularize it. It was important work, but we were certainly standing on the shoulders of giants.”
— Richard Eisermann
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.
→ History of the Double Diamond, The Design Council
(mb, yk)
