English
ČeštinaDouble Diamond - Framework for Innovation
We're building a comprehensive knowledge library about product development as part of our mission. The library is for anyone looking to make better decisions — primarily decisions about how to further develop a product. Whether you're an inventor, a product manager, or a Chief Product Officer, using a structured decision-making method increases your chances of building the right things for the right audience (build the right thing for the right audience). Today we'll introduce the Double Diamond framework for Innovation.
Framework name: Double Diamond – Framework for Innovation.
Inventor: the British Design Council, for design.
Year first used: Unknown, probably around 2001.
Link to original research:
the blog article 20 Years of Building on the Double Diamond.
Key figures in developing the framework:
UK Design Council,
Jessie Johnson.
Key milestones in developing the framework:
Integration into the Systemic Design Framework.
History of First Use
The Double Diamond – Framework for Innovation is an extension of the Double Diamond framework. The newly added sections aim to improve orientation within the complex decision-making process of larger organizations, such as government agencies, communities, and large multinational companies.
How It Works
The Double Diamond – Framework for Innovation is a set of recommendations. The purpose of this layer is to organize communication between designers and non-designers, and to model the ideal company culture that ensures long-term positive change through design.
Because it's a layer on top of an innovation framework, there's no best or worst option within it. When deciding which problems or solutions to focus on, the authors rely on various research and prioritization techniques.
The process adds methods, principles, an outcome orientation, communication loops, and the building of a company culture that supports innovation. What was originally the process-driven, linear Double Diamond framework thus becomes a never-ending loop of gradually improving a specific problem.
Graphic representation of the Double Diamond – Framework for Innovation
Changes Within the Double Diamond
Within the individual phases, changes were made to ensure better communication of the design process between designers and non-designers.
The Discover Diamond
The UK Design Council's recommendation for this phase is to spend time understanding and communicating the problem, discussing it, and working exclusively with the people the problem directly affects.
The Define Diamond
The new recommendation is to use the knowledge gained from the Discover-stage discussions to define the problem.
Iterating on the views of the people affected by the problem, and then synthesizing their feedback, happens in a loop. So this is no longer a linear process.
The Develop Diamond
For this diamond, the UK Design Council recommends looking for inspiration outside the design field for a problem that's already well defined. The emphasis is on involving people outside the design team and gathering their feedback.
The Deliver Diamond
The final step toward better communication is testing solutions through small, compact experiments and prototypes, and evaluating dead ends in the design.
Iterating on the solution also happens in a loop here, with the designer collaborating with a wider circle of non-designers, gathering their feedback, and then working it into new prototypes.
Design Principles
In a new section called principles, the framework emphasizes good communication.
The first principle is understanding how people use the service or product — what their current needs and aspirations are, and what the strengths of the current solution are. The framework encourages putting people first, rather than the problem.
The second principle is striving to communicate both the problem and the solution visually.
Another principle is the emphasis on collaboration and co-creation throughout the entire process of delivering a solution. Inspiration from people both on and off the team also matters.
The last principle can be summed up by the motto "test, test, test." In practice, this means a maximum emphasis on involving users and key stakeholders throughout the entire design process, so as to reduce the risk of mistakes while increasing confidence in the proposed solution across the whole team.
Methods
The framework also has a new section called methods, which emphasizes the practices and artifacts important to success.
The first practice is explore, which emphasizes identifying needs, writing down ideas, and assessing them objectively and critically.
The second is shape, where prototyping based on feedback and a shared vision of success is key.
And the last practice is build, which emphasizes team ideas, planning, and drawing on professional expertise when creating the solution.
Success
The final ingredient that the Double Diamond – Framework for Innovation brings is the building of a culture of innovation.
Management should support innovation, help the team acquire new skills and experience, and enable experimentation. Agility and presenting the interim states of unfinished solutions are part of strong innovation management.
Involving a broader range of people in the design process is the foundation of its success.
A Worked Example
The Double Diamond – Framework for Innovation is a methodology of iterative thinking that helps you discover and define problems, generate solutions, and continuously test them with the people the problem affects.
The Discover Diamond
For example, "bad UX" in onboarding (getting into the app) also needs to be communicated. Discussing the issue with members of the Customer Success team — in a meeting or in the office — helps you learn what experience that team has from helping clients with onboarding.
The Define Diamond
Once you've defined what "bad UX" in onboarding means, you can float that definition on an internal communication platform to get feedback from the Customer Success team.
The Develop Diamond
Once there's enough feedback from the people who run into the problem very often — in our case, the Customer Success team — we build a quick prototype of the solution and show it to, say, the Sales department, or directly to the customers who had the problem, and ask them for feedback.
The Deliver Diamond
A solution that has gone through at least two iterations can be shown more widely. Let's bring in, for example, the marketing department and customers who don't have any trouble with onboarding. We communicate every step on an internal communication platform such as Slack, Teams, and so on. We show prototypes, test results, descriptions of experiments, and design samples. We also communicate the delivery date for the final solution.
Design Principles
First principle — instead of internal discussions, we ask customers, go into the field, and observe how customers use the product or service today. If we have the budget for it, we go directly to the customers, and the visit is often combined with a sales meeting. We record all feedback on the product. If it's a brand-new product, we work to understand how people use a similar service that we want to replace or significantly improve. One always exists.
Second principle — we share FIGMA prototypes, Cursor prototypes, annotated videos recorded with the Microsoft Snipping Tool, and any unfinished visual samples and intermediate products on our internal communication platform. We share presentations and answer the questions of when it'll be ready, what it'll be, and what it'll look like, so that the whole organization understands what problem we're solving and how it'll contribute to the organization's growth. We really try to "show it off," not just "send it to Slack."
Third principle — we involve various people who matter to the organization's internal decision-making throughout the whole process. In a small company, that might even include the CEO. The Head of Product or Head of Design may even communicate with investors. In companies of up to 100 employees, it's normal to let individual Heads know personally. Don't expect daily feedback from them. Heads only speak up when they "see an obvious problem." Heads can have very constructive comments that take the final solution to a new level.
Fourth principle — we test everything. In particular, we test with customers who have relevant experience with the problem, or who are our power users, or who belong to the group of people the problem affects — that is, the target group. Every week we talk with them, show them what's new, and use experiments to find out whether the final solution helps them with the problem.
Methods
First method — we describe in detail the problem we want to solve, and the world of the people it affects. Ideally, we narrow down the number of customers who have experience with our problem at least three to five times, because most problems look at first glance as though they affect every customer — but once we dig deeper, we find that isn't true. We lean on data from analytics tools such as Google Analytics, Mixpanel, and DataDog; feedback tools such as Productboard, Inari, GetUserUp, and others; and our experiments with customers. The goal is to understand how our target group perceives the problem.
Second method — we prototype everything using technical tools such as Cursor, Vibe Coding, Figma, Sites, and others. If our problem involves a physical object, such as a table, then in the "workshop" we build a prototype out of real wood and send it to people for testing via testing platforms like Betatesting.com. Conversely, if it's an electrical device, we again assemble the device in the "workshop" from known components and test everything in the field with customers.
Third method — once we're already building the final solution, we ask experts for their opinion. In particular, we work through the technical properties and limits of the solution, as well as potential problems that may arise during mass production or when the solution is used outside test conditions.
Success
How can management support a culture of innovation? Above all, by not punishing failure — employees who built products or features that didn't find their customers aren't penalized in their further development.
How do you involve a broader range of people in the process of creating a solution? Communicate on an internal communication platform, and treat feedback in the comments as part of success. Talk with customers, and treat their requests as part of the improvement process. Run small experiments every week that help validate the solution and define the problem.
License
Double Diamond by the Design Council, under the CC BY 4.0 license.
