The double diamond is dead

and that’s a good thing

For way too long, when designers are asked to show their value, give a case study, or talk about who they are as designers, you get a process diagram, the double diamond, boxes and arrows, a workshop, or a lifecycle map. Don’t get me wrong, I love a diagram, but our reliance on process to prove our value has to stop. These tools each have their place, but they are the how, not the actual value we bring.

We’ve spent too much time as a function focusing on the process, and we’re past that now. We already are part of the process. We’re working on the product. We’re working with engineering, and we’re so focused on the perfect process that we’re forgetting we’re actually creating impact and doing the work. We’re solving problems. We’re acting as if we need a perfect process that delivers perfect results every time, but that’s not how it works. The process is important, but what’s more important is how you frame a problem, how you become opinionated about the solution to that problem, and how you execute that solution.

As Designers, we occupy an interesting space, serving as the translation layer between users and the companies we work for. It is an amorphous job, with heightened responsibility and ever-changing levels of autonomy. When customers complain about a flow, it comes to design to “fix it,” but the solutions we ship are a combination of an entire team’s input, and we all need to work together to solve these problems at the right layer, with the right level of detail. Designers should be leading the way.

When you speak to Engineering, Product, Marketing, Data or the C Suite, they don’t lead with process. In fact, when Design speaks with other functions and leadership, they often become frustrated with us when we request additional time to validate solutions with users or conduct further research. You are in the conversation for a reason, and you have to be ready to contribute right now. When you talk to Product, they don’t automatically jump to discussing its discovery process. They talk about priorities, opportunities, and outcomes. When you talk to Engineering, they don’t talk about languages, technical architectures, or APIs. They talk about reliability, performance, and speed. Each function has its own process, but when speaking with other functions, they focus on outcomes, not on how they will get there.

So what do we do now?
If you are a designer, you need to stop over-explaining the method and start over-explaining the impact. You need to treat your process as yours and don’t expect anyone else to buy it. You have to stop justifying your existence and start owning your impact. You are already doing a great job. Just get out of your own way, be opinionated, and be right more than you are wrong. You got this.