Design is not a formula, it’s an odyssey: replacing the Double Diamond

Double-Diamond and Design Thinking are inaccurate. There’s a better way to think about process.

Much has been written about the practice of Design, largely in service to the idea that it’s a process.

Many books have been written about the subject, for example, each spending multiple chapters elucidating to the reader via tales of well-planned structures that help Design run like clockwork. “This is the way the Design process was meant to work,” they’ll say.

Meanwhile, Medium itself is a haven for “Design Process” articles, listicles, and opinion pieces. Any person who’s been in the industry of Design for a few years will no doubt have been asked to adhere to some Process that’s been informed by a viral Medium post shared by Kevin Rose. “This is the way the Design process was meant to work,” they’ll say.

Here’s the truth of the matter, from somebody who has been doing Design for well over 25 years: Design is not a Process, it’s an Odyssey. It is not a rigid structure with steps to follow, but a path you discover along the way with dangers, villains, and wisdom to be gained, and you often wind up right back where you started.

Allow me to explain.

The most popular Process applied to Design is “Double Diamond.” You’ll find Medium, as always, is ripe with articles championing the original Double Diamond methodology, as well as updates to Double Diamond. Here’s a thought-provoking Medium article entitled The New Double Diamond Design Process is Here. Please feel free to read and absorb it. But, of course, I’ll summarize:

  1. The original Double Diamond model, proposed in 1996, attempted to define how Designers worked.
  2. It was an attempt to resolve the notion that there was no actual Design process, that Design was a chaotic mess.
  3. A new model has been illustrated to reflect how modern Design, born of a computer-driven technology age, ought to work.
  4. The only part that is fundamentally agreeable is this line: Design is not a linear process.

Double Diamond

Illustration from Dennis Hambeukers’ article, reflecting the original Double Diamond

In the original Double Diamond model, we see that a linear process is directly and concretely implied. Any Design project, born from any request or opportunity, must flow through this model which suggests:

  1. A Problem is identified, and the Designer is in Discovery Mode
  2. Work is done to generate insights into the Problem: why is it a problem? Where’d it come from?
  3. The Problem Statement leads into Definition Mode: defining the Problem in clear terms, identifying how the Designer will attempt to tackle the Problem, and also defining intended outcomes.
  4. Now we move into Development Mode, where potential solutions are explored.
  5. While in Development Mode, a process of filtering is applied in order to identify the most successful solutions.
  6. Those successful solutions move into Delivery Mode, where the solutions are finalized, filtered down even more, and ultimately the singular Solution is found.

This sounds great, but it exists in an imaginary plane of existence. Design does not happen in this manner, and of course, Design is not linear.

Design Thinking

Another framework for Design is the broadly-applied term “Design Thinking,” which refers less to a step-by-step process of execution and more to a way in which Designers are meant to think (hence the name, I suppose).

In spirit, Design Thinking is actually pretty great.

Illustration from Interaction Design Foundation

This model suggests:

  1. Design Thinking is non-linear. Agreed!
  2. In order to succeed in a Design project, Empathy is the foundation. Agreed!
  3. Empathy helps define the problem. Tests can inform empathy by teaching us about users. Tests can also create new ideas.
  4. Empathy is also connected to Prototypes, which are born from ideas, but all of this is somewhat indirect. Prototypes can spark new ideas, and Prototypes can be tested as well, which can connect back to Empathy and Problem Definition.
  5. Wait, this is starting to feel complicated.

Again, in spirit, Design Thinking is a wonderful framework, but not only is it complicated, it also isn’t a reflection of the reality of Design work.

The ultimate reason why these methods of Design Process, Design Thinking, and Design Doing have been so over-defined is rooted in a need to help legitimize Design amongst other functions, departments, and domains within Companies. Design so often sits at the intersection of Business Goals and Customer Impact, and so it has a need to provide others with a sense that it knows exactly what it’s doing, it has predictable output, and it can meet deadlines. All of this influences those who fundamentally do not understand Design.

In truth, Double Diamond is not a process that given Design projects can regularly follow, but is instead a delightful illustration to put in a slide deck to tell external stakeholders “here’s how the Design department runs.” It is as influential as a Live, Laugh, Love plaque in a home where yes Living, Laughing, and Loving do sometimes happen but not necessarily in that order and not always in a planned, intentional way.

In truth, Design Thinking is spiritually a great idea but also not a methodology that can be universally applied to all Design Projects. It’s a great metaphor that, much like Double Diamond, is great to put in a slide deck to external stakeholders to imply a fundamental method to your madness.

All of this is done in service to those who do not understand Design. So, I propose a new method of thinking. One which can still be used to inform non-Designers and create an air of legitimacy while simultaneously reflecting the reality of the work. One which is not a rigid process to follow but represents how much of an adventure the whole thing can really be.

The classic tale of Odysseus, immortalized in The Odyssey, has inspired and excited humanity for ages. It weaves a tapestry of a story about an adventurer who sets out on a journey but gets delayed by angry gods and dangerous complications for years, all in an attempt to get back home. It sounds like Design.

The reality of so much Design is just like The Odyssey. You start off on a project with a goal in mind, you explore a bit, you get side-tracked or interrupted time and time again, requirements change along the way, you meet new people and learn new things, and you wind up back where you started at the beginning but have to convince everyone you belong there.

Below is a new proposal to reflect the way Design really works, both in a realistic sense, but also an aspirational one.

The Design Odyssey Framework creates a sense of structure without ignoring the reality of Design work. Click the image to zoom in. Circle scale implies impact.

Structure at a Glance

In a framework, structure is important. But as has been stated, Design is not a linear process. In essence, each phase of the Design Odyssey overlaps and cycles back on itself, and each phase also has its own events which are self-referential. Although one would like to imagine everything goes perfectly linearly, from left to right, it rarely does.

Part 1: The Beginning

Every good journey starts somewhere. Beginning a Design journey often starts with some blob of elements: a Problem/Goal is identified, Space is Created, and an Understanding is developed. Not necessarily in that order.

Influential components and activities of The Beginning stage include User Empathy, a knowledge of Customer Needs and/or Business Needs, Data & Research collection, Timeboxing, and general Planning. All of this should, of course, be informed by a native Design Philosophy.

In the Beginning, the point is to ask “What are we doing and why?”

Part 2: Exploration

Great Design is the result of playfulness — the willingness to try ideas and fail. The same is true of any journey. You might be walking down a well-established trail and discover something new, pulling you off the beaten path. Still, you have a destination in mind, and so you use a set of tools and methods to try to reach it:

Wireframes, Flowcharts, High-Fidelity Design, Prototypes, Collaboration with fellow designers or non-designers, and Having a Long Think…as in just sitting and allowing your mind to wander. Maybe even take a nap (yes, really). All of these are useful parts of exploration and play, and all tools at your disposal should be utilized if appropriate.

In the Exploration phase, the point is to ask “How might we get to where we want to go?”

Part 3: The Bridge

Without fail, intrepid adventurers come upon a bridge crossing a deep chasm. Below lies the unimaginable. But across the bridge lies the promised land: a successful, finished project. You must cross this bridge, but there are barriers in the way: Evaluation of your work thus far (via Design critique or stakeholder feedback), Negotiation of reasonable expectations and/or new requirements, and Rethinking aspects of the project that you may have thought you were sure about.

Some ingredients and events in this phase are Changed Expectations, Misunderstandings, User Testing coming back with surprising results, Design Critique guiding you in a new direction, and of course, the CEO interjecting (or some executive popping in).

In the Bridge phase, the point is to ask “Are we doing this right?”

Part 4: Construction

Along this journey, you will come to the point where taking stock of how far you’ve come, settling in, and building something becomes the necessary next step. Think of all you’ve done, all you’ve seen, all you’ve explored. The bridges you’ve crossed! The chasms you’ve overcome! But, the journey is not over.

This is the moment where you have a pretty good idea of what’s necessary to reach your end goal. The only problem is it hasn’t been built yet, and this is where collaboration is key. This is where you leverage the tools of the final form, like code or print. This is where you sit down with developers or production staff to review the work in progress. This is where you estimate your time, estimate your impact, and…play around?

Yes, once again, even with focused finality in sight, play remains a critical part of Design. Through collaborative play, you will realize the most thoroughly-explored version of whatever it is you’re making. Your partners in engineering, production, or whatever else is helping you build this thing—will be empowered to help you think about how far this thing could go.

In the Construction phase, the point is to ask “How can we push ahead, together?”

Part 5: Conclusion

The finish line is right upon you. You can smell it. You can taste it. You came so far and now it’s time to put a bow on this project and wrap it up. The only thing in your way is actually being finished. Turns out, the finish line might not be the end, and perhaps it shouldn’t be.

In the process of finishing, you may realize you’ve bitten off more than you can chew. Finishing might need to happen sooner than you realized, so you trim the plans back.

You may also realize that you don’t know the true impact of your work, so you take some time to measure. Maybe you measure performance, maybe you measure feedback, and based on what you learn you may need to trim or go all the way back to Construction.

And maybe, just maybe, you never reach the end. The project might not ship at all. The client might put things on hold, or the business strategy may change once again. Technically this is a Conclusion, so you move on, dust yourself off, and begin the cycle anew with yet another project.

What’s important, here, is knowing that you’ve reached an end stage and how to proceed, even if things didn’t necessarily go exactly as planned. More often than not, they don’t.

In the Conclusion phase, the point is to ask “What does ‘done’ look like?”

Read the full article here

Leave a Reply

Your email address will not be published.

How to Hide Participant Names in Zoom Recordings

How to Hide Participant Names in Zoom Recordings

Table of Contents Hide First: Why should you hide PII in video recordings?

Flood Rescue | A Cross Platform Tool for Flood-Affected Communities

Flood Rescue | A Cross Platform Tool for Flood-Affected Communities

In 2005, Mumbai was inundated by water in a deluge that nobody expected, causing

You May Also Like