While the design process is different for each project, we can start with some common goals – like exploring the problem space and clarifying project goals. Knowing what’s next requires collaboration, communication, and a little curiosity.
The Risks of Oversimplifying the Design Process
Most designers and project teams have probably encountered a variation of the graphic known as the “double diamond,” which explains how we explore options, and then narrow them for each problem and solution. A well defined understanding of the problem and its constraints begets smarter, more creative solutions.
I’ve often used it to explain the design process at a high level. Starting from the initial problem, we use design methodologies to understand the landscape better and prioritize what problems we can reasonably solve, given time and resources. Then, we explore our hypotheses about what could solve our problems and test them against qualitative and quantitative measures, until we have an initial set of features. I’ve used this diagram to explain design to clients, co-workers, and friends who want to understand what I do. But just like any effort to simplify a complex process, the double diamond is an incomplete picture of reality.
At its best, the double diamond is useful for describing a path forward given a set of problems. It can be useful for giving everyone a high-level view of the design process, and ideally will enable conversations about how we de-risk a product going to market by fully understanding the problems, constraints, solutions, and trade-offs.
At its worst, oversimplification of the design process can confuse and frustrate, leaving too many details open for interpretation. Additionally, clients often have an idea of the problems and solutions in mind that we can use as hypotheses to validate using design methodology. I’ve worked on several projects that require bespoke methodologies that are hard to map against the double diamond.
If I try to map out a more realistic process, it looks a lot more confusing and less confidence-inspiring than the initial double diamond. The design process is a human process: diamonds are not the same size in terms of effort or time, nor do they flow from one to another cleanly. Different teams care for different parts of the system and have different experiences or understandings. It takes clear, consistent communication and documentation to ensure we’re building the right thing, for the right people, with the right setup.
The double diamond shines best when initiating the conversation around design and how it fits into the overall product timeline. I find it helpful to revisit the initial intentions behind the graphic to adapt it to my practices more intentionally.
The History of the Double Diamond
Originally described by Béla H. Bánáthy and presented in the book “Designing Social Systems in a Changing World” published in 1996. Since then, it has been revised and reframed by agile thinking and the advancement of technology.
We constantly integrate information, knowledge, insights gained, and the findings of testing into emerging design solutions. This process is not linear, sequential, or systematic. Design manifests dynamic interaction between feedback and feedforward, reflection and creation, and divergence and convergence. This dynamic process goes on until we develop confidence in the viability of one of the solution alternatives. —Béla H. Bánáthy, Designing Social Systems in a Changing World (p. 17)
A more modern version is called the “Framework for Innovation” presented by the Design Council in the UK.
I prefer this visualization because:
- The design process is iterative, and we revisit, reframe, recycle through problems and solutions all the time. The arrows help illustrate this step.
- Design principles help guide and recenter us to what’s important: A human-centered design process, communicative and collaborative teams, and iteration.
- A methods bank can include multiple methodologies to help a team get unstuck and prioritize activities so they can move forward.
Recentering Ourselves to Shape Next Steps
Regardless of the design process used, solving human problems is messy and imperfect. We might be design process experts, but it takes a team of individuals communicating and collaborating to solve the different intersections of problems facing a given project.
Collaborators will be out of sync at times, and unexpected problems will arise, but there are several questions anyone can ask at any time to recenter the group on the goals of the process.
9 key questions to ask at your next retro or team meeting:
- Identify: What problems are we focusing on today? What decisions have we made regarding previous problems and what do we predict will happen next?
- Prioritize: Given time constraints and staffing, what are our priority problem areas?
- Reframe: Who are our users? Is this still true?
- Recalculate Technical Feasibility: What are the technical limitations and how complex are these features?
- Measure: Who is responsible for the QA process and are they well aligned with intentions and goals? How are we collecting feedback and addressing issues?
- Recalculate Organizational Feasibility: What are the organizational limitations? Are people staffed in the right place to support the scalability and sustainability of the product or service?
- Practice Self-awareness: Are the right people in the room? Are we limiting our understanding of the problems or potential solutions by not including certain experts or fresh perspectives?
- Explore Methodology: What are activities that best support designers, developers, and the organizational project owners, so everyone’s on the same page in terms of where we’re headed?
- Get Inspired: Where can we draw inspiration from analogous solutions for these types of problems?
Anyone can ask these questions, not just designers. The entire team makes microdecisions every day that shape the overall product, and the more informed everyone is, the more adaptive the team can be when project conditions change and decisions need to be made on the fly.
I hope you’ve learned something that you can apply to your own practice, whether you’re a designer or not. Thanks for reading!