Look closer at the double diamond process.

Double Diamon “applied”

Today we’re talking about charts and sometimes their inability to capture details in favor of simplification.
Simplifying can sometimes improve vision, but can result in a loss of often important details that may not have been considered.

Every now and then there is a new methodology and relative chart that is in fashion and in the last few days I was looking and looking at the double diamond chart.
What does the double diamond chart hide from us?

Reality

Reality trumps simplification. “Reality is analogical” and therefore when you model an analogical phenomenon you “sample” it, that is you leave out (deliberately) the details.
But how reliable is “simplified” photography? Sometimes a little. That’s why I would ideally zoom in on the Double Diamond phases to see a bit closer in the real-world process.

The design process is not a linear process

Even if for educational purposes, in the youngest, we could create the illusion (and the conviction) that the process of defining the problem is a clear/linear process and occupies a limited (and predictable) time and is constant to be able to arrive at a fixed point to say:

“OK then we have defined the problem”.
We’ve climbed steadily through the process to the “diamond” peak and now we’re “coming down” to problem definition.

Well, this is almost never the case.

Generally in case studies, it refers to problems of the type:
– travel agency (the user knows where they are starting from and they know where they want to go);
– ecommerce;
– food delivery.
Vice versa, when we talk about an unusual problem or situation (and so real situations), things become complex and a “simple” double diamond chart no longer shows the complexity of the process and it’d needs a “zoom-in”.

Example

Let’s take a practical example as we usually do:

Stakeholder X (usually a manager in charge) requires a feature for his department.

Let’s start: the ideation begins, the engine starts for the requirements analysis and we slowly move towards the problem definition;
the problem is defined and …BOOM!

Stakeholder X leaves the Company.

What do we do? Do we cancel the functionality? Often not.
Who remains not only knows little but try to take the original requirements and begins to put them in question regarding its point of view:

“maybe this thing here can be done this way, maybe this thing can be done more extensively”.

We are told a lot of time that the phase iterates so it would be possible to iterate and redo all from scratch, but what’s happens, in reality, is a little different.

My “double-star chart”: zoom-in the double diamond

In reality some intermediate phase of assessment and “dynamic adaptation” for which we make slight deviations, mini-cycles of reconstructing the assumption (or later the develop) to stay on track .

So we reanalyze the change, we recover all the “already done” we try to stay on the path traced before the abandonment of our famous “stakeholder X”.

From the initial problem, therefore, through a simple path of adaptation (the upper part of the graph) or through a more tortuous path (the lower part of the graph), we arrive at the PROBLEM* (problem star), i.e. a problem that extends and perhaps incorporates the previous one.

As well as we consider making some supplemental intermediate prototypes to accord micro-fracture of requirements or unforeseen lack of scenarios.

What’s “double star” also shows
For this reason I thought to describe these situations with a graph that I called “double-star”, where:
– DISCOVER and DEFINE phases don’t “look” DIVIDED but always walk together and influence each other generating also state changes;
– DEVELOP and DELIVER phases do not “look” DIVIDED but they walk together and the mutual influences determine the realization of intermediate prototypes (not released) to readjust the path in case of need.

In these cases sometimes even subsequent development operations are influenced by feedback from stakeholders who had not originally thought about the “problem” and so mini-cycles of adaptation may be required here as well.

Zoom in on the double diamond (for example with the double star) can help to represent visually (and so better estimate) extra effort not representing each phase as a linear path but take into consideration of potential (or real) deviations.

Oh sure! It’s definitely more complex than how we planned it but…”it’s reality baby!”