Double Diamond

The Double Diamond is a design process model developed by the British Design Council in 2005. It visualizes the design thinking process as two connected diamonds: the first diamond helps you find the right problem, the second helps you find the right solution. Each diamond has a divergent phase (exploring broadly) and a convergent phase (narrowing down).

The process has four phases forming two diamonds:

1. Discover (Diverge) — Explore the problem space broadly. Research, observe, interview users, gather data. Don't jump to solutions. Try to understand the full picture.

• User interviews, ethnography, desk research, data analysis

1. Define (Converge) — Synthesize your findings. Narrow down to the core problem worth solving. Create a clear problem statement.

• Affinity mapping, "How might we..." statements, problem prioritization

1. Develop (Diverge) — Generate many possible solutions. Brainstorm without judgment. Explore different approaches.

• Ideation workshops, sketching, prototyping, concept testing

1. Deliver (Converge) — Test, refine, and implement the best solution. Validate with real users. Ship it.

• User testing, iteration, MVP launch, measurement

• Be willing to explore before committing
• Separate problem-finding from solution-finding
• Diverge before you converge in each phase
• Involve users throughout the process

• Discover: Interview 15 recent hires, shadow their first week, survey managers, analyze time-to-productivity data. Finding: new hires feel overwhelmed and isolated.
• Define: The core problem isn't "bad onboarding materials" — it's "new hires lack a support system during their first 90 days."
• Develop: Brainstorm solutions: buddy system, onboarding cohorts, structured 30-60-90 day plans, weekly check-ins with managers, self-service knowledge base, gamified learning path.
• Deliver: Pilot a buddy system + 30-60-90 day plan with the next cohort. Measure time-to-productivity and satisfaction. Iterate based on feedback.

The Double Diamond ensures you solve the right problem before solving it right. By separating exploration from execution, you avoid the common trap of jumping to solutions before understanding the real problem.