The Double Diamond framework, with its four phases of Discover, Define, Develop, and Deliver, has been the gold standard for user-centered design since the British Design Council introduced it in 2005. Yet many teams struggle to implement it effectively within sprint cycles.
Doing research methods often creates bottlenecks within the process, forcing teams into an uncomfortable choice: either skip testing and validation entirely and risk building the wrong thing, or slow down product velocity and miss market windows.
The framework itself isn’t the problem. The evolution from the original 2005 model to today’s iterative, continuous approach reflects the reality of digital product development. We’re no longer in an era where research happens once at the beginning and once at the end.
Modern tools have solved the historical barriers that made the Double Diamond feel like an aspirational ideal rather than a practical methodology. Teams can now maintain the rigour of proper discovery and validation while achieving the speed demanded by agile methodologies.
This article explores how continuous customer research platforms bridge the gap between thorough research and rapid iteration, transforming the Double Diamond from a theoretical framework into a sprint-compatible practice that prevents costly mistakes without sacrificing momentum.
The Double Diamond was formalised by the British Design Council in 2005, following a study of eleven leading global companies, including LEGO, Sony, Microsoft, and Starbucks.
Across every organisation studied, designers naturally moved through the same stages when solving problems, even if each company had its own name for the process. The Council mapped this shared behaviour into the framework we know today.
Design Council. Eleven Lessons: Managing Design in Eleven Global Companies. British Design Council, 2005.
https://www.designcouncil.org.uk/resources/the-double-diamond/
Rather than creating another proprietary methodology, the Council sought to develop a universal language that could describe the design process regardless of industry, whether you’re designing services, physical products, or digital experiences.
At its core, the framework is a visual representation of divergent and convergent thinking. It’s more than a workflow; it’s a structured approach to problem-solving that prevents teams from jumping to solutions prematurely.
The two diamonds represent two distinct challenges: “doing the right thing” (problem validation) and “doing the thing right” (solution execution). This separation is necessary because solving the wrong problem efficiently is still a failure.
The framework operates on a simple but powerful principle: you must diverge before you can converge. Divergent thinking opens up possibilities, gathering information broadly without judgment. Convergent thinking narrows focus, synthesising insights and making decisions. Each diamond contains one divergent phase followed by one convergent phase, creating a rhythm of exploration and focus.
Since its introduction, the model has evolved into the “Framework for Innovation” to reflect the non-linear, iterative nature of modern design. Today’s digital products are rarely “finished”. They’re living entities that require continuous refinement.
The updated framework acknowledges that testing a solution might reveal fundamental misunderstandings about the problem, sending teams back to the first diamond. This isn’t failure; it’s learning.
“The Double Diamond is not a rigid process, but a way of thinking about design that can be adapted to any project or challenge.”
British Design Council
The Double Diamond’s universal applicability spans industries:
The framework serves as a communication tool for stakeholders who need to understand why design takes time. It sets expectations and explains why teams aren’t “drawing icons” in week one.
The critical importance of the first diamond cannot be overstated: it validates that you’re solving the actual user problem, not the assumed one. This is where most projects fail before they even begin.
Stakeholders often arrive with solutions already in mind (“we need an app,” “we need a chatbot”), but these are answers to questions nobody has properly asked. The first diamond forces teams to resist the urge to jump to solutions and instead invest time in understanding the problem space.
The Discover phase is characterised by divergent exploration. The goal is to gather maximum information without bias toward preconceived solutions. This means setting aside what you think you know and approaching the problem with genuine curiosity.
Research methods during this phase include:
The key is spending time in the user’s environment to understand both emotional and practical challenges. You’re not just collecting data points; you’re building empathy by experiencing the context in which your product or service will exist.
Why does breadth matter so much? Because the “obvious” problem is often just a symptom. A request to “make the checkout faster” might actually stem from users feeling anxious about payment security, not from the process taking too long. Looking for outliers, adjacent problems, and root causes beyond the initial brief prevents teams from optimising the wrong thing.
Traditionally, this phase took weeks or months, creating pressure to skip it entirely. Teams felt they couldn’t afford the time for proper discovery when stakeholders demanded visible progress. This is where modern approaches change the equation: continuous access to customers in a Customer Lab means discovery can happen in days rather than months, removing the excuse for skipping this critical phase.
Once you’ve gathered a wealth of data from Discovery, the Define phase is about making sense of it. This convergent phase involves analysing research data to identify patterns, recurring pain points, and opportunities for innovation.
Synthesis techniques include:
The goal is to move from hundreds of individual observations to a handful of key insights that reveal the true nature of the problem.
This phase often involves reframing the original brief based on what was learned. A project that started as “redesign the mobile app” might be redefined as “help users feel confident making complex decisions on small screens.” This reframing is captured in “How Might We” statements that provide clear direction without prescribing specific solutions.
Prioritisation is essential during Define. Not every insight can be acted upon immediately, so teams must align user needs with business goals and technical feasibility. This is the “waist” of the Double Diamond—the moment of maximum clarity before solution exploration begins.
The risk here is “permanent discovery”. Teams that never converge on a defined challenge because they keep finding new things to research. Rapid validation tools help teams recognise when they’ve reached saturation (new research yields no new insights) and confidently move forward with a validated problem statement.
With a clearly defined problem in hand, the team enters the second diamond. This shift from problem exploration to solution exploration is necessary. You’re now armed with a validated challenge statement that ensures any solution you develop addresses a real user need.
The second diamond maintains the same diverge-converge rhythm, but is applied to creating and refining solutions rather than understanding problems.
The Develop phase applies divergent thinking to solutions, generating a wide variety of answers to the defined problem. This is where creativity flourishes, but it’s creativity with purpose—every idea is evaluated against the validated problem statement from the first diamond.
Cross-functional collaboration is essential during this phase. Involving developers, marketers, and customers in co-design sessions ensures that solutions are technically feasible, commercially viable, and genuinely desirable.
Some of the best ideas come from seeking inspiration outside your immediate industry. Healthcare organisations have learned from Formula 1 pit stop efficiency to improve emergency room handover processes.
Rapid prototyping is the hallmark of this phase. Low-fidelity sketches, wireframes, and paper models allow teams to “make to think”: visualising concepts to identify potential flaws before significant investment is made. The goal is to fail fast and fail cheaply by exploring multiple paths simultaneously.
Testing early concepts with customers gauges direction before high-fidelity design begins. Traditionally, manual recruitment and scheduling of prototype testing sessions created bottlenecks that could take weeks.
Modern approaches provide continuous access to customer communities, enabling teams to test multiple concepts in parallel within sprint timeframes. This acceleration doesn’t sacrifice quality—it simply removes the administrative friction that historically slowed down validation.
The Deliver phase is the second period of convergence, where the team narrows the solution pool through rigorous user testing and validation. Prototypes are put in front of real users to see if they perform as intended. This isn’t about confirming what you hope is true; it’s about discovering what actually works.
Validation methods include:
Features that don’t work are discarded without regret—better to learn this now than after full development. Those that show promise are refined iteratively, improving what works and fixing what doesn’t.
The MVP (Minimum Viable Product) approach is common during Deliver. Soft launches gather real-world usage data, allowing for final adjustments before full-scale rollout. This phase also ensures that solutions meet technical requirements, brand guidelines, and compliance standards—especially critical in regulated industries like finance and insurance.
“Deliver” is not the end. In digital product development, post-launch data becomes discovery research for the next iteration. This creates a continuous improvement cycle where the framework loops back on itself.
The challenge with traditional testing methods is that they create weeks-long delays between prototype and validation, breaking sprint momentum. Real-time feedback tools that deliver insights in 24-48 hours maintain velocity while preserving rigor, allowing teams to stay in the diamonds without slowing down.
The perceived tension between thorough design thinking and agile velocity is one of the biggest barriers to implementing the Double Diamond. Teams feel they must choose between doing research properly or shipping on time. Under sprint pressure, diamonds often get skipped entirely, leading to expensive rework when teams discover they’ve built the wrong thing.
The solution isn’t to abandon the framework, it’s to adapt it. Think of “mini Double Diamonds” for individual features or sprint cycles. Instead of running one massive Double Diamond for an entire product, run smaller ones for specific user stories or feature sets. This makes the framework sprint-compatible without sacrificing its core principles.
Condensing discovery is key. Rather than months of ethnography, teams can:
The goal is to gather information faster. Continuous validation replaces the traditional model of one massive annual study with multiple small research projects running throughout the year.
The “Research-Design-Test” loop common in agile is essentially a compressed Double Diamond:
Time compression is real and measurable. Organisations using continuous customer collaboration platforms report reducing feedback cycles from weeks to 24 hours. This enables teams to test concepts on Monday, gather insights by Tuesday, and incorporate learnings into designs by Wednesday. All within a single sprint.
The quantified outcomes can be compelling:
Leanlab’s approach specifically addresses each diamond phase with built-in tools. For Discover, user diaries and online discussions provide contextual insights. For Define, ideation rooms and preference tests help prioritise concepts. For Develop, Figma prototype testing and unmoderated usability tests validate designs at scale. For Deliver, beta groups and validation tools confirm direction before launch.
This integrated approach means teams don’t need to cobble together multiple platforms or manually coordinate research activities. Everything happens in one continuous collaboration space.
The real-world impact is significant. Organisations conduct research that would have been impossible with traditional methods. This bridges UX and CX, making sure marketing campaigns and customer touchpoints are rooted in validated insights rather than assumptions.
The result is higher confidence in decisions, reduced development risk, and better alignment between user needs and final products.
Understanding critiques of the Double Diamond helps teams use it more effectively. The framework isn’t perfect, and recognising common failure modes prevents them from derailing your implementation.
This is the most frequent and costly mistake. Stakeholders arrive convinced they “already know” what users need, pressuring teams to jump straight to solutions. This results in solving the wrong problem expensively.
The fix: Use the Double Diamond itself as a communication tool to set expectations with leadership about why discovery matters. Show them the cost of rework when teams skip validation.
Corporate pressure for efficiency truncates exploration phases. Teams feel they must get to “the answer” quickly, leading to obvious but ineffective solutions. The reality is that the first idea is rarely the best idea.
The fix: Create a culture that values evidence-based decision-making over gut feelings. Demonstrate ROI by showing how early validation prevents expensive development of features that don’t resonate.
Poor handoff between the Define and Develop phases means insights from the first diamond don’t reach execution teams. Developers start building without understanding the validated problem, resulting in solutions that miss the mark.
The fix: Document problem statements and research insights in accessible formats. Hold handoff sessions where discovery teams share findings directly with development teams.
The Double Diamond should not be a rigid, one-way street. Modern product development requires iterative feedback loops where testing in the second diamond might send you back to the first.
The fix: View the framework as a mental map that guides thinking, not a checklist to complete linearly. Build in regular checkpoints where teams can loop back if needed.
Teams apply the model superficially without the depth of research and synthesis it requires. Running a single-user interview and calling it “Discovery” doesn’t fulfil the spirit of the framework.
The fix: Set minimum standards for each phase. Define what “good enough” looks like for your organisation: how many users, what types of research, what depth of analysis.
Leadership that doesn’t understand why divergent phases are necessary will pressure teams to skip them.
The fix: Educate stakeholders about the framework’s value using real examples of projects that failed by skipping validation. Share success stories from your own organisation.
The opposite problem—never converging on decisions, endlessly gathering data without action.
The fix: Set clear criteria for when you have enough information to move forward. Use quantified validation data to make these transitions confidently.
Waiting until the Deliver phase to involve users means changes are most expensive.
The fix: Build continuous customer access so validation doesn’t require lengthy procurement processes. Implement rapid feedback tools that make divergence and convergence faster and less resource-intensive.
A real example illustrates the value: spotting weak ideas early in the funnel saves significant development time and resources. One organisation using continuous validation discovered that a feature concept they were excited about tested poorly with users in the Develop phase.
Rather than building it and discovering the problem post-launch, they pivoted immediately, saving months of development effort and avoiding a feature that would have frustrated users.