Synthesis (Design Thinking)

If we were to explain it to our kids, we would say that in synthesis we work towards a spark, an AHA moment, which makes us feel we understand what is really going on. In training, we like to introduce the topic with the parable of the eight blind monks and the elephant, in which every monk touches just one different part of the elephant and describes it in his own words, from his own perception. None of them will grasp ‘the whole’ of the elephant before each monk has shared and synchronized his perspective with the group.

In cross-disciplinary corporate teamwork, we have a similar situation. Team members often believe they understand the customer and their problem spaces well enough to jump straight into designing solutions without research. But usually, it’s the insights from design research that let a more complete picture emerge, which deviates from or even contradicts each individual’s assumption-based perspectives. Once puzzle pieces in the form of field observations and interpretations are shared and put together, this more comprehensive picture emerges and helps the team to gain insights they were not able to discover before. Synthesis is therefore a very critical part of customer discovery. In fact, it is so critical that we always recommend that project sponsors and other decision-makers take part in it. So, how does it work?

Popular representations of design (thinking) practice often show colorful walls of sticky notes that get clustered somehow. And, yes stickies are a great tool to externalize information but affinity mapping/clustering is of course not the only way of sharing and organizing data. Hundreds of methods and visual representations exist to do so. So let’s not look at methods here — they are documented well enough. What’s more interesting and often less understood is how a team’s cognitive processing of data from information to knowledge during synthesis generally works.

Strictly speaking synthesis should rather be called ‘analysis-synthesis’, as it is not a linear process but one comprising alternating phases of analysis and synthesis. If you zoom in on this process, you can see that teams go through roughly four sub-stages: First, they ‘unpack and explore’ their data gathered in the field (also called ‘download’ or ‘story-share’). This means they tell each other what they’ve observed, make sense of what they’ve learned, and ‘build models of the current reality’ (e.g. by visualizing the status-quo of customer journeys, concept maps, flow charts, or stakeholder relations). This is more of an analysis exercise, often supported by certain methods, so far involving very little interpretation.

After this comes the actual synthesis part where they ‘connect and model’ what they’ve shared with each other. They now make and interpret connections between the data points and the models they have created. A statement you might hear in such conversations could be: “OK, if eight out of twelve interviewees struggle with A in this stage of the user journey we surely can assume that B, can’t we? Even though they wouldn’t admit it, my hunch is that they feel X here due to Y. Let me visualize that …”. The models from the analysis sub-phase become enriched with a layer of informed intuition and interpretation by the team. Such assumptions can later be transformed into hypotheses, which in turn can be tested in experiments during the prototyping phase. This is the single most critical part of any design thinking process and the one which companies suck at in our experience. If your ‘connect and model’ process is superficial, even if you have good research data, you won’t find the surprising truths which are the springboard for innovative solutions in ideation and prototyping. You therefore have to ask yourself over and over: What might be hidden in plain sight in our data? What do our ‘models of what is’ tell us that the users haven’t? Only this deep probing (and if needed additional research) will lead you to the AHA moments, which we call (user or customer) insights. It’s these insights that allow the team to select their initial problem(s) worth solving, which is the goal of synthesis.

At best these problems worth solving, also called ‘points-of-view’ or ‘problem statements’, are discussed and co-selected with sponsor users first. They then get tested with prototypes and experiments across several learning cycles, which helps to refine the team’s ‘models of what is’ and iterates the problem statement itself until the team agrees on having reached a sufficient point from which to move on.

Read more on synthesis and design methods