For anyone that doesn’t know the Double Diamond is a fairly well established and prolific representation of a commonly accepted design process.
We adopted this here at Redgate a few years back; not because we didn’t already have a process in place, but because we needed to emphasise and educate others around the importance of understanding and defining the problem to be solved, before jumping to a technical solution.
The Double Diamond, as a model, is great for conceptually illustrating two key points:
1. As above, the importance of first defining the problem to be solved and as such, the need for designers and the wider product team to operate in the problem space (vs. being purely solution-focused).
2. The need for divergent-thinking; both to understand and define the problem and to be comfortable with exploring a number of ideas, before converging on what they think would be the best solution.
However, as with any off-the-shelf model or framework, there is often a need to interpret and adapt to your own circumstances and organisational challenges. So, whilst the principles above hold, there needs to be some creative license involved when deciding how best to apply this model to your established research, design and engineering processes (AKA product development).
Whilst diamonds are rigid, your process shouldn’t be.
For the rest of this article, I’m going to discuss what we’ve learnt about the Double Diamond and how it applies in practice to product development here at Redgate, as well as some of the pitfalls and traps to avoid whilst attempting to integrate this in a modern, Agile software organisation.
Strategy vs. Execution
Whilst in an agency setting, It’s right and likely that your design process will start right from project inception. However, for in-house teams, working across a mixed portfolio of new and established products, that starting point and the concept of a ‘starting point’ is likely to be very different.
The majority of the time the team will begin the process with a good, foundational understanding of customers, the problem space and their needs; often shortcutting the necessity to redefine the fundamentals.
Within the scope of a given opportunity, the boundaries of the team’s efforts have already started to narrow in; focusing on understanding and defining the exact nature of the problem to be solved. The goal here is to be able to clearly articulate the problem, who is affected, when and how they currently work with or around said problem. This is the level of detail necessary for us to be confident with any solution(s) we explore. Confident that we have a stable basis for the creative process that follows.
The learning here is that this model can apply both strategically (early stage) and tactically (established), where the scope of your efforts and methods utilised will vary depending on where the product is in its lifecycle. For an established product, the focus, more often than not, will lean towards execution, where there is likely a long-list of potential, valuable opportunities queued up ready to explore. As such, the need to open out again and conduct extensive, upfront discovery is less obvious, since the foundations are well established and the scope is to a greater extent predetermined.
However, as we know, customers and their needs are not static; markets change, demands change, technology changes, legislation changes. Any of these factors can introduce new challenges for a business and it’s employees, and with that, new and changing demands and expectations from the products and services they consume. To remain competitive and identify new opportunities for innovation, we should always be searching for signals that evidence the existence of new or unmet customer needs.
In practice, this means layering on exploratory/generative research efforts, alongside the more thematic, targeted research, necessary to execute on the current opportunity. Here, the concept of Continuous Discovery can introduce a dual-track approach in an established product context, where the likelihood of doing big, upfront discovery projects are often few and far between. When done well, it ensures an ongoing investment in the effort required to both ‘Search’ and ‘Execute’; delivering both shorter-term value and seeding a long-list of future product opportunities.
Rigid vs. Fluid
Much like physical diamonds, design projects come in lots of shapes and sizes. As such, your design process needs to be fluid and able to adapt to different scenarios that will require different sets of methods and with that, the relative emphasis on Definition vs. Delivery, or Problem Space vs. Solution Space. For example, where the problem is fairly well defined and underpinned by a body of prior research, we’ll rightly focus more of our effort on delivery i.e. exploring, validating and creating a first releasable version of a working solution.
To describe this further, I’ll use three known examples of where we, the Design Team at Redgate, have flexed this model based on the scenario or specific type of problem we’re trying to solve.
1. Problem Focused Approach
In this scenario whilst the business opportunity might be clear, the scope of the initiative and/or specific nature of the problem(s) to be solved are poorly defined. As such, there is a greater need to better understand the target customer, their context and the impact of the problem. The emphasis here is on defining the problem.
It follows, therefore, that the team’s efforts, approach and associated methods bias towards understanding and defining the specifics of the problem to solve. Proportionally, they will spend more time upfront (vs. other scenarios) doing good customer research to the point that they are confident enough about where to focus and can start to see the shape of solution they could potentially build.
2. Solution Focused Approach
In this scenario the business opportunity is clear, the scope of the initiative is well-bounded and the team have a good understanding of the problem to be solved. As such, there is a greater need for the team to explore, test and refine a solution; ensuring it will solve the problem that’s been identified.
It follows, therefore, that the team’s efforts, approach and choice of associated methods bias towards finding the best version of a given solution for our customers. Proportionally, they will spend more time ideating, prototyping and testing solutions to the point they are confident that they have identified something that will address the problem and deliver customer value.
3. Opportunity Focused Approach
In this scenario, a promising, yet speculative future opportunity has been identified and we want to rapidly explore, test and validate ideas for how we might tackle a future product initiative or pursue a new or alternative customer proposition.
For those familiar with Design Sprints, the approach is reflective of a short (time-bound) cross-section of the end-to-end design process, used to rapidly explore and validate a new idea or opportunity.
In summary, while the fundamentals of the model apply across every scenario (“solve the right problem and then solve it right”) the process has to be one that is capable of being fluid and flexible. Recognising when and how to change your approach is key to enabling the blend of skills and resources necessary to deliver the right outcomes at the right time.
Linear vs Non-Linear
Taking the Double Diamond at face value, it appears to be a linear process. Cranking every project through a series of well-defined stages, step-by-step, and then handing off to another team at the end. Again, this might be the case in another industry, but in an Agile software setting, where design and engineering are tightly coupled, that is simply not the case. We’ll likely see teams go back and forth, working between stages of the design process as new information and new perspectives inform their understanding.
As such, we’re done with a phase when we have enough confidence to proceed, having addressed our biggest assumptions, not once we’ve checked off a series of predetermined activities. As a model, the Double Diamond serves to keep us honest about where we are relative to an ideal process, but the likelihood is that we’ll flex on that, and in the true spirit of Agile can adapt as we become aware of new information.
As an example, if we find ourselves exploring solutions, based on what we thought was a well-defined problem, only to discover through testing a prototype that our understanding of the problem wasn’t right, then we’ll rightly revisit our definition of the problem; effectively resetting on any solution work.
Again, it might sound obvious, but this is what’s necessary to ensure that we’re always open to questioning if we’re doing the right thing by Redgate and our customers.
Blindly following process, without asking these difficult questions and being open at any point to being proven wrong, can lead a team down a path of solving problems no one cares (or cares enough) about. This understanding shapes the trajectory of your efforts and the likelihood of your work having the desired impact, so as and when necessary be prepared to recalibrate.
Serial vs. Parallel
As well a being non-linear, I’d argue that any successful design process, operating in an Agile setting can only succeed where research and design activities are done in parallel with the wider team’s engineering efforts. Not wanting to retread age-old Agile vs. upfront design debates, but the reality is that we’re often required to operate a blend of discovery, definition and delivery in parallel.
As the engineering effort never stops or stands still, inevitably your research and design activities will need to run concurrently. As a result, what is typically illustrated as a series of phases, structured sequentially, would, in reality, operate in parallel and likely stagger across multiple development cycles. As per the illustration, this would see some level of work upfront to define the problem, which would feed the exploration of solutions in the next cycle, that in-turn specifies the detailed design work required to release something of value to the customer.
In contrast, when working on a greenfield project, it’s reasonable and acceptable to take the time upfront to discover, define and plan for what we intend to build first, for whom and why. Without an initial north star, we have no starting line or conceptual destination for any of the engineering effort that follows. With mature products, however, the machine is always in motion, so as designers we have to work in a way that allows us to explore and shape ideas that are further out; working ahead of engineering counterparts, whilst also tackling the more detailed design needs associated with any in-flight solutions.
The problem is more complex still when you also factor in Continuous Discovery and the need to always be searching for the next best opportunity. This would see designers, by which I’m also including research, needing to carve out time to be diligent about staging and staggering the full gamut of activities necessary to:
- Search for and discover new, valuable business opportunities
- Conceptually explore and validate a given opportunity
- Identify, design and validate a good solution to a problem
- Deliver and iterate on the design specifics of a current solution
The Double Diamond in practice
So having worked with this model for a while and seeing how we’ve tried to apply to a range of product scenarios, I would conclude, as above, that the fundamental principles stated at the beginning of the article still apply.
Using this as a model to underpin our framework (the design playbook) has been particularly helpful for new starters (design and non-design). We’ve been able to layer a set of familiar methods and techniques, applicable in different scenarios on top of this stages; guiding us through key decisions points and giving us the confidence to know when to proceed or to revisit those tough recalibration questions.
In reality, our application of the Double Diamond probably looks a bit more like the illustration below. This has seen us needing to flex and blend different approaches according to the situation, in a manner that is Agile, timely and can deliver across a range of current and future design needs.
In summary, irrespective of whether you choose to adopt the Diable Diamond or some other model for your design process, I would encourage that you think about and have answers to the following:
- Strategy vs. Execution — Think about where your design process starts. Remember, in software companies with an established portfolio of products is a high likelihood that most teams will be working to execute on an existing strategy. What is the trigger point or starting line? What do you need to know up front? Is the scope clear or ambiguous? Is this effort to inform and shape a future strategy or execute on what’s already in motion?
- Rigid vs. Fluid — Whilst having a uniform, on-rails design process is great from an education and alignment perspective, the reality is that you’ll often need to adapt it and operate more fluidly than any model is likely to illustrate. How does this current scenario differ to the last? Where do you need to focus/bias your research and design efforts? What’s the best approach to deliver against the desired outcomes?
- Linear vs. Non-linear — At times you’ll find the need to deviate from a structured design process, revisiting and challenging some of your key assumptions. New information will often come to light, sometimes requiring you to stop and recalibrate. Are you still solving the right problems for the right people? Do you need to revisit and redefine your understanding of the problem? Are you designing on top of shaky foundations?
- Serial vs. Parallel — In an Agile software environment there is less room for a big, upfront design effort. This necessitates more of a staged and staggered approach to your research and design activities, and the ability to service both current and future design needs. How do you make time for continuous discovery? How do you design ahead of the engineering effort? How do maintain the quality of design work during execution? How do you keep one step ahead of the engineering effort?
If you’re thinking about your next career move or are looking for an exciting new opportunity in the field of design, take a look at our current Product Design vacancies on the Redgate careers page.