Design process: Double diamond
The beauty of design is that no matter the design challenge you’re confronted with, the process of moving from a concept to a solution follows the same path. As you spend time in each part of the process, the better your outcome will be!
There are many different ways to break up this process, and in this article we’ll cover the Double Diamond.
The double diamond is elegant because it describes 3 things: phases, delivery points, and the convergence and divergence of ideas.
The Four Phases
The four phases are how I frame case studies, UX backlog stories, and communicate to stakeholders how flushed out a design is.
1. Discover
Discover is arguably one of the most important phases because what you put in determines what comes out. In other words, it gives insight to the quality of your solution.
The discover phase is about the why. What problem are you trying to solve for? If you dig deeper, can you find a systemic problem? Who is saying it’s a problem, and why is it important to solve?
Asking the right questions, staying curious and open-minded here will lead you to create a good user research study, find the right quality metrics, and most importantly, empathize with the users you’re solving the problem for.
2. Define
The define phase articulates the what. Once you know what the motivation is for tackling a design problem, you need to be able to sum it up. What will and won’t you address when solving this problem? What assumptions are you making? What expectations do you need to set?
When you’re working with stakeholders or making sure you have alignment with product managers or developers on what the problem is, you’ll know early on if you’re on the right track or not.
Clarity is key and helps you understand how complex or simple a problem is, and how long it will take to solve.
3. (Design and) Develop
Yes, I snuck design in here :) In my version of the phases, this is where design happens. With a convergence of what the problem to solve for is, you can begin to explore different pathways or layouts, alternative options, and more. You start to test truths and poke at what might be one of those, “maybe there’s a better way than this” moments. You bring awareness to what could be by questioning what is. And you get to take others along for the ride.
The first idea won’t ever be the best, and typically the best designs get to be that way through iteration. Maybe a stakeholder has a suggestion, or a user tester provides some feedback you haven’t considered. Either way, no great design has ever been built in a silo. Get out there. Show your work in progress.
4. Deliver
Once you, your team, and the powers that be give the green light on a solution, it’s ready to bring it to life.
As you or your development team reckon with existing platforms or realize something might take more time than initially scoped, you make new calls. Maybe it’s important to build the full design. Maybe in this case, it can move to version 2. Either way, it’s a conversation that needs to happen.
Sometimes, someone will discover an edge case that was overlooked. As you revisit what you’ve learned in the Discover and Define phases, maybe there’s a logical answer. And when there isn’t, you go back to those phases and find out.
Delivery points
The circles in the diagram show when check-ins should happen. At least, that’s how I view them.
Problem
No design problem just manifests without someone somewhere realizing the gap. So, the problem must stem from somewhere! Understanding the problem and testing your assumptions becomes that push into the Discover phase.
Design briefs & Problem definition
I love design briefs, hands down. This is where you, the designer, capture the answers you’ve been finding, then document your “hypothesis” of what the true problem is and what you’ll measure or track to see if your design was successful. I typically do a formal brief for large projects, though being able to mentally check the boxes of a design brief format for any design problem will ensure you have enough to go on.
Solution
Not all solutions are a full end-to-end high-fidelity prototype handed off to developers. Sometimes, a quick wireframe sketch is all a Product Manager or Developer needs to get unblocked, or maybe a high-fidelity mock of one screen. Set this expectation if you’re working with stakeholders.
Convergence and Divergence
Your first solution will never be the solution you go with, and the problem you hear about will never be about just that problem. In the divergence points, go broad. Ask questions, explore, do a competitive analysis and see how others have solved for it.
Then converge. This is an art, but being able to articulate the problem in a design brief format, or going from 50 design solutions to 2 or 3 without throwing away the really good stuff takes time. You’ll learn to hang on to the facts that are the most meaningful to your users and stakeholders. Those become your guide, or mini mission statements of what your solution must do. You’ll realize some facts are out of scope for the solution you need to deliver. And finally, some facts you’ve heard are less important or not significant, and it really is up to you whether you take it into consideration. This is why getting feedback is key. You’re validating the choices you make.
Conclusion
To reiterate, the double diamond design process is just one of many documented design processes to move through a concept to a fully-baked design solution. Its 3 layers cover phases, deliverables, and the divergence and convergence of ideas. The only thing it doesn’t explicitly show is sometimes needing to go backwards through the phases. As you adapt design thinking, remembering that this process is not linear will give you room to come back to the drawing board as needed.
