The Double Diamond, Minus the Ceremony

If you've worked in design for more than a few months, you've seen the Double Diamond. Two diamonds side by side, labelled Discover, Define, Develop, Deliver. It shows up in onboarding decks, agency pitches, and case studies so often that it's started to feel like wallpaper — something everyone recognizes and nobody really looks at.

I'll admit I rolled my eyes at it for a while. It felt like a diagram designed to make clients feel reassured, not something that changes how you actually work on a Tuesday afternoon.

Then I realized I was using it anyway — just without the ceremony. And the stripped-down version has become the most useful mental model I have.

The one idea that matters#

Strip away the labels and the Double Diamond says one thing: open up before you narrow down, and do it twice.

The first diamond is about the problem. You go wide — talk to people, look at data, question the brief — and then you converge on a clear statement of what's actually wrong.

The second diamond is about the solution. You go wide again — sketch, explore, try ideas that might be wrong — and then you converge on something you can ship.

That's it. Everything else is detail.

The reason this matters is that most teams skip the first diamond entirely. They receive a brief that says "redesign the dashboard" and immediately start opening Figma. The problem has been defined by whoever wrote the brief, and nobody checks whether that definition is right.

Why the first diamond gets skipped#

It's not laziness. It's pressure. Discovery feels like a cost with no visible output. A stakeholder can't look at "we talked to eight users and realized the problem is different than we thought" the way they can look at a polished mockup.

But the first diamond is where the biggest wins come from. I've had projects where a brief said "users need a better filter system," and ten conversations later the real problem was that users didn't trust the data enough to filter it at all. Building a better filter would have been a beautifully crafted answer to the wrong question.

Skipping discovery doesn't save time. It just moves the cost to later, when it's more expensive — usually right after launch, when the metrics don't move and nobody understands why.

My lightweight Discover#

I don't run three-month research programs. Most of my projects don't have the budget, and honestly most don't need it. Here's what discovery usually looks like for me:

• Read everything that already exists. Support tickets, sales call notes, analytics, previous research decks, angry app store reviews. Most organizations are sitting on more insight than they realize; nobody has just read it all in one sitting.
• Talk to five to eight people. Real users if possible, frontline staff if not. Thirty-minute conversations, mostly listening. I ask about the last time they did the thing, not what they'd want in theory.
• Talk to the people who build and sell it. Engineers know where the system is fragile. Sales and support know what customers complain about. Both are underused sources.
• Map the current journey. Not the ideal one — the real one, including the workarounds, spreadsheets, and screenshots people use to get around the product.

For a medium-sized feature, this takes a week, sometimes less. It almost always changes the brief in some meaningful way.

Define: write the problem down#

The end of the first diamond is a problem statement. I'm strict about this being written — a short paragraph that the team can read and argue with.

A good problem statement names who is struggling, what they're trying to do, and why the current experience fails them. It does not contain a solution. "Users need a new dashboard" is a solution wearing a problem's clothes. "Clinic managers can't tell at a glance which appointments are at risk of no-show, so they spend their mornings calling everyone" is a problem.

Once it's written, I share it with stakeholders before designing anything. This is the cheapest moment to discover that you disagree. If the product lead thinks the problem is something else entirely, I'd much rather learn that from a paragraph than from a fully designed flow.

Develop: go wide on purpose#

The second diamond opens up again, and this is where I try to resist my own instincts. Experienced designers develop strong first ideas. That's useful, but it's also a trap: the first idea is usually the most obvious one, and the obvious one is often what the competitor already built.

So I force breadth. For a key screen, I'll sketch at least three genuinely different approaches — not three variations of the same layout, but different mental models. A list versus a map versus a timeline. A wizard versus a single dense form. An automated default versus full manual control.

Most of these will be wrong. That's the point. Seeing the wrong options side by side makes it much clearer why the right one is right, and that reasoning becomes the backbone of the design rationale later.

This is also where I bring in quick validation. Rough prototypes, a few unmoderated tests, a hallway check with a colleague who hasn't seen the project. I'm not looking for statistical proof. I'm looking for the moment someone gets confused, because confusion at the sketch stage is free.

Deliver: narrow, then ship#

The last phase is convergence. Pick the direction, refine it, build out every state, and work with engineering to get it shipped well.

This phase looks the most like "design" to people outside the process — high-fidelity screens, polished prototypes, component specs. But by this point, most of the important decisions have already been made. The craft is in executing them carefully, not in deciding what to build.

Delivery also includes what happens after launch. I try to set up at least one way to see whether the change worked: a metric, a follow-up round of interviews, a support ticket tag. Without that loop, you're shipping into the dark and calling it done.

It's not linear, and that's fine#

The diagram makes it look like a neat sequence. Real projects loop back constantly. You'll be in the middle of developing ideas and realize the problem definition was off. You'll ship something and discover a new problem that sends you back to discovery.

That's not the process failing. That's the process working. The value of the Double Diamond isn't that it prescribes a sequence; it's that it gives you language for where you are. "I think we're still in the first diamond" is an incredibly useful sentence in a meeting where everyone is arguing about button colors.

Scaling it up and down#

The same shape works at very different scales. For a two-day feature, the first diamond might be an hour reading support tickets and a fifteen-minute chat with a customer success lead. For a new product, it might be six weeks of research. The shape stays the same; the depth changes.

What I try never to do is skip a diamond entirely. Even a tiny amount of divergence — fifteen minutes questioning the brief, three quick sketches instead of one — consistently improves the outcome.

The point of a process#

I don't follow a process because it makes me look rigorous. I follow it because I've been wrong enough times to know my first instinct isn't always right. The Double Diamond is just a structured way of giving yourself the chance to be wrong early, when it's cheap, instead of late, when it's expensive.

Drop the ceremony. Keep the shape. Open up, narrow down, and do it twice.