TheDoubleDiamondinpracticeforchoosingwhattoautomate

When a law firm asked me to make “the agents learn,” the request came with the solution inside it: train a model. I researched that path and it didn’t add up: not offered for current models, expensive to keep running, and risky with client data. Behind the request was a different question: how does the system get better at the way we work? That one had a different answer, and it didn’t require training anything.

Automation requests almost always arrive like that, with the second diamond already open. The method for going back to the first one I learned on design projects. The example I use to explain it comes from a project I delivered for Eduzz, a Brazilian platform for digital products, in 2024.

That year, Eduzz was going to do its annual year in review for creators again: a sequence of stories-format screens with each creator’s achievements for the year. The piece already existed. The natural path was to open last year’s file, swap the colors, and think up new screens.

The question that came in was “how to make a beautiful year in review.” The one that came out of the first diamond was different: how to make a year in review people want to show off. A year in review nobody shares is just a report with animation.

What changed the question wasn’t opinion. The previous edition had left behind a data point: the share rate of each screen. The most shared one (21%) wasn’t the revenue screen. It was the one saying how many lives the creator had helped change. Right behind it (20%) was the opening screen with the person’s name. The corporate screens were at the back of the line. That data point was the discovery, and it decided the content before any new screen was drawn.

This article is about that part of the method, the part that usually gets skipped.

The model in one picture

The Double Diamond was popularized by the UK Design Council in 2005. The core idea is that solving a problem well takes two openings and two closings: one to understand the problem and another to find the solution.

1. DiscoverShare data from the previous edition and benchmarking
2. DefineFrom “beautiful” to “something people want to show off”
3. DevelopStakeholder workshop across four fronts
4. DeliverImpact × effort matrix and interactive prototype

• Discover (diverge): get out of the room, listen, observe, gather data. The goal is to expand understanding, not to reach an answer.
• Define (converge): organize what you learned and choose one problem. The deliverable is a sentence, not a screen.
• Develop (diverge): explore many solutions to the chosen problem.
• Deliver (converge): test, refine, and launch the solution that survived.

Where teams go wrong

The most common mistake is treating the first diamond as a formality. The brief already arrives with the solution (“we need a dashboard,” “let’s build an app”), and the team jumps straight to the second diamond. The Double Diamond becomes a Single Diamond with more steps in Jira.

In the Year in Review, that was exactly the temptation. The piece existed, the format was familiar, and the deadline was two weeks. Skipping discovery would have looked like efficiency. The likely result would have been repeating the formula of filling screens with metrics and hoping someone found it interesting.

The symptoms of skipping the first diamond show up later, and they’re expensive:

Symptom at the end of the project	Cause in the first diamond
The feature launched and nobody uses it	The problem belonged to a different audience, or wasn’t a priority
Every stakeholder understands the goal differently	The definition was never written down or negotiated
The usability test “passed,” but the metric didn’t move	The test checked whether the screen is usable, not whether it solves the pain
Rework on the data model after launch	The users’ mental model was never mapped

What happens in the first diamond

Discover: expand understanding

Discovery mixes sources, because no single one is enough:

• Interviews with people who live the problem, about the past and not the future (“tell me about the last time you did this,” never “would you use this?”).
• Observation of real use: shadowing support for an afternoon, watching a work session.
• Behavioral data that already exists: funnel, share rate, tickets, internal searches with no results.
• Benchmarking to understand what’s already standard and what nobody solves.

In the Year in Review, two of these sources did the work. The first was behavioral data. Nobody had to ask creators what they thought of the previous edition: the share rate of each screen already answered that, and answered it better than an opinion survey would. People don’t share numbers. They share what the numbers say about them.

The second was benchmarking against Spotify Wrapped. The reference was obvious, and the care went into using it to understand the mechanism, not to copy the aesthetic: stories format, one idea per screen, personal data turned into identity, first-person narrative.

Benchmarking done well becomes an argument, not a mood board. In the concept for Conker, an app for discovering trails and waterfalls, comparing it with Waze, Strava, and Google Maps showed that each one solved a piece and none solved the whole: discovering an outdoor activity spot near you, with a community. The product’s opportunity came out of that comparison.

Define: choose one problem

Converging is the most politically difficult phase, because choosing one problem means not choosing the others. What helps:

1. Synthesize what you learned into themes and turn themes into opportunities: users’ needs, pain points, or desires, not features.
2. Prioritize the opportunities by size of impact and by evidence. The opinion of the highest-paid person doesn’t count as evidence.
3. Write the definition: one short sentence, negotiated with stakeholders, that will guide the second diamond.

In the Year in Review, the definition was the change of question. “Beautiful” is the designer’s criterion. “Something people want to show off” is the recipient’s criterion, and it reorganizes everything: the opening has to greet them by name, the middle has to talk about the creator’s impact on other people, and the corporate message stops being the center.

1. 01Gather

   Share rate per screen from the previous edition and benchmarking against Wrapped.

2. 02Read the pattern

   Impact on people (21%) and personalization (20%) lead; corporate content trails.

3. 03Opportunity

   Creators want to show what the year says about them.

4. 04Define

   A year in review people want to show off.

A definition format that works:

Rewriting the Year in Review definition in this format today, it would read: creators need a year in review that says something about them, because screens full of generic metrics aren’t what people share. We know this because, in the previous edition, the impact and personalization screens were the most shared and the corporate ones the least. We’ll consider it solved when share rate per screen is the success metric for the new edition.

The last part is the most ignored and the most important. Without it, the second diamond has no criterion for saying it’s done. And notice that, in this case, the criterion and the evidence are the same measure: the data that opened the project is what will judge it.

The second diamond, with the right question

With the problem defined, the second diamond is the better-known one: generate alternatives, cut, prototype, and test.

In the Year in Review, divergence was a stakeholder workshop in October 2024. The ideas were organized into four fronts: Product, Creators, Journey, and +Human. Convergence came on an impact vs. effort matrix, to decide what made it into this edition. The article From sticky note to opportunity shows the board from the inside.

What the first diamond changed in the second was the filter. With the “beautiful” question, any visually interesting idea competed on equal footing. With the “something people want to show off” question, ideas were judged by what they say about the creator. The final narrative followed that: it starts with the person (personalization), moves through their impact on others, and ends looking ahead, with the tier of the recognition program the creator can reach next year.

Two reminders for this phase:

• Actually diverge. Three different solutions to the same problem teach more than three versions of the same solution. Four fronts with different names help force that variety.
• Test against the definition. A usability test answers “can people use it?” The Double Diamond question is different: “does this change the behavior we defined back then?” In the Year in Review, the prototype was interactive and navigated on a phone, screen by screen, so stakeholders could see it the way a creator would. The final yardstick is still sharing.

The first diamond of an automation

The same method, applied to manual operations, changes its material but not its shape. In place of the share rate, the data is the work as it’s done today.

In the legal AI agent, the first diamond meant documenting the workflow that already existed: the lawyers used an AI chat with instructions written by the firm itself, and the picture came from the screens of a real work session. From there came four requirements that became law in the product: the binary conclusion, the documentation gap paired with the defense it opens up, declaring what couldn’t be read, and a mandatory anchor on every claim. And the request to “learn” became a different definition: keep the model fixed and let the context evolve, with short lessons learned from corrections, proposed by the machine and promoted by a partner.

In a distributor’s ordering system, the first diamond fit in one decision: don’t ask anyone to change their habits before they get something out of it. Buyers already photographed their handwritten notes. Rewritten today in the format above, the definition would read: the back office needs to receive the order without retyping it, because whoever retypes also interprets, and interpreting leads to errors. We know this because “balde” (bucket) means 20 liters and “tb” means a drum. We’ll consider it solved when the photo order ends up in the same queue as the catalog order, with no doubtful line getting through undecided.

In both cases, the definition doesn’t mention the AI. It mentions the work. The AI came in during the second diamond, as one of the solutions, with a person confirming.

The Double Diamond isn’t a sequence

In practice, the diamonds repeat and overlap. A prototype in the second diamond can reveal that the problem was poorly defined, and it’s fine to go back. The model isn’t an assembly line; it’s a reminder that opening and closing are different activities, and that the team needs to know which one it’s in.

It’s not a matter of time, either. The Year in Review took two weeks. The first diamond didn’t need a month of research: it needed someone to look at the data already on the table before opening the design file. Cheap discovery is still discovery.

First diamond checklist

• Before coming up with new ideas, did we look at what users have already told us through their behavior (usage, sharing, support)?
• Did we talk to people who live the problem, about real, recent situations?
• Did the benchmarking explain a mechanism or a gap, not just an aesthetic?
• Does the synthesis separate what we observed (fact) from what we think (interpretation)?
• Does the definition fit in one sentence without mentioning any interface?
• Is there an observable criterion for “solved,” ideally measured with the same data from discovery?
• Did stakeholders agree on the definition before the first prototype?
• Was the automation request treated as a hypothesis, not a requirement?

If any answer is no, the team is still in the first diamond, even if the AI has already been picked.