Breaking Down the Double Diamonds
Challenge
Despite all the good intentions of product managers and UX designers, we found that even with equitable partnerships and squad trios, many teams still rushed to solutions, lacking proper problem investigation and ideation. While we were producing features, we needed true innovation. Too many low-hanging fruits with too little impact. The design process needed more structure and clear guidance.
Analyzing The Situation
Without clear structure and appropriate methods, a design process can get messy. Lacking sufficient problem discovery, teams concentrated on fixing symptoms instead of offering solutions for the underlying problems. For example, rather than providing a problem description, stakeholders and product managers submitted feature requests to their design peers. To comply, designers would execute the proposed solutions, seldom ideating to find different approaches. As a result, their creative power stayed largely stuck in adapting UI.
Introducing The Double Diamond Process
I introduced the Double Diamond method to give our teams a more structured design process. After ensuring buy-in by all discipline leaders of engineering and product management, I individually ran workshops with every product squad and the design team. We explained common misconceptions about the model and that it should serve them more as a guide rather than a strict to-do list.
The Double Diamond process is often misconceived as rigid and slow mainly because visual depictions imply that all phases need to be the same "size. "That thinking is missing the most impactful aspects. Separating understanding the problem from solutionizing and using divergent and convergent thinking are critical to the model's success. The time and effort spent on each phase should depend on factors like the size of the issue, the information at hand, and the team's capabilities. Like any design process, the double diamond cannot bring perfect solutions on the first run. Getting to a viable first version that can serve as the basis for evaluation and iteration remains critical. I emphasized these key success factors in my instructions and workshops with the teams.
Breaking Diamonds for Shared Responsibility
To ensure each squad trio member shared ownership and got all the information necessary for the success of our products, we distributed responsibility for the phases. While Problem Discovery and Problem Definition would be led by product management, UX designers would lead in Solution Discovery and Solution Delivery, and engineering would subsequently be in charge of the implementation phases. Each leader was responsible for making sure knowledge was shared, all disciplines contributed, and everyone had the same understanding of problems and solutions.
Even if some feared the changes would slow them down, we saw some excellent adaptions of the Double Diamond at first. Especially the designers were eager to expand their impact on solutions. Sharing responsibility for the process was a good step in operationalizing our equitable partnerships in the squads. But with growing adoption also came challenges. Overwhelmed by new possibilities, squads stumbled, finding the proper flow, including customers into the process early, and validating before implementation. Insufficient use of allocated budgets for research and testing remained proof of our struggles. Clearly, the teams needed more direct guidance to take the next step.
Switching Phases
One of our teams' first challenges was knowing when good was good enough. When did we have enough information about a problem? How many ideas did we need to develop to find the right one?
The leadership team and I made sure to drive home the message that there wasn't one correct answer. The teams needed to view the Double Diamond more as a guideline for thinking rather than a linear process. If they discovered they needed to be more thorough at one stage, there was no harm in going back for a second round, much like they would need once they iterated on their solution. After all, instances of finding the perfect solution on the first try are rare to none. The principles of build, measure, learn, and repeat still apply.
Introducing A Method Catalog
We made the process actionable by giving the teams more detailed approaches, tools, and deliverables for each stage while remaining flexible and fast.
Problem Discovery
This phase's essential purpose is to familiarize yourself with the problem at hand and dive deep past the superficial symptoms. Therefore, we chose only methods that helped us collect as much information as possible.
We combined early customer and stakeholder involvement through interviews, observation, market and competitor research with analytics data to create an information base with diverse perspectives.
Problem Definition
Since the discovery was solely focussed on collecting information, the definition phase is reserved for making sense of the information we had collected.This is where different mapping methods like affinity mapping, customer journeys, and empathy maps helped us understand how the problems came to be and where the symptoms were most severe.
Design Brief
At this stage, the key to the design brief is to frame the problem in a way that is clear and concise for everyone to understand and gives enough freedom to create a diverse set of creative ideas. Most importantly, all briefs needed to be solution agnostic.
We used How Might We questions, mock press releases, and user stories, among other methods, to inspire our collaborative ideation sessions.
Solution Discovery
Designers moderated the ideation phase by using co-creation workshops, analyzing market best practices, and mapping flows for a set of early solution hypotheses.
To avoid getting lost in details, we urged the teams to use wireframes, miro boards, and sketches instead of Figma prototypes. The quickest way to transport the idea is always the right choice.
Solution Delivery
To narrow down our ideas, we offered a combination of predicting effort & impact, estimating business value, and of course, user testing of early prototypes to find out our "best bet" idea. Finally, a structured process of elimination would give us an idea of the feature or service we needed to build beyond personal opinions.
Ideally, only these final bets would be designed and tested in high-fidelity prototypes and included specifications for engineering hand-over.
Learnings
The Double Diamond process is an excellent depiction of what is essential about design thinking methods. Unless you implement it correctly, the strategy will not be helpful, like any other. Teams must understand how to choose the proper method for each phase and when to move on to the next stage, which comes best from excepting that you won't find perfect on the first try and trusting in learning through iteration.