How I Approach Complex Product Problems

A working process — Double Diamond, seven activities, and what actually holds it together

If you asked me to name a design process, I'd point at the Double Diamond. It's been around long enough to earn its place. Discover · Define · Develop · Deliver — the shape is recognizable, it holds up under real work, and it's flexible enough that a senior designer can operate inside it without being boxed in.

What I want to do here is share how I actually work within that shape. Not as a recipe — recipes are for kitchens. As a description of the beats that a complex product problem usually moves through when I'm running it, and the things underneath the beats that matter more than the beats themselves.

This is written for other designers who might want to adopt or adapt any of it. Nothing in here is proprietary. Nothing is untested — this is drawn from fifteen years of practice across healthcare, enterprise software, analytics, travel and commerce, most recently on a large reporting product line at athenahealth where the questions ran deep across research, product direction, technical architecture, and delivery. If you find any of it useful, take it.

Why the Double Diamond

I use the Double Diamond because it's honest about two things most process diagrams gloss over.

First: divergence before convergence. Every hard product problem I've worked on has had a stage where the right move was to widen — to look at more evidence, more possibilities, more angles — before narrowing to a decision. The diamond shape says that out loud. Widen, then narrow. Widen again, then narrow again. Anyone who's tried to skip the first widen has ended up shipping something that solved the wrong problem.

Second: the two diamonds are different diamonds. The first one is about understanding and framing. The second is about making and delivering. Conflating them — treating define the problem and define the solution as one act — is where I've seen good teams lose months.

If you've never used the Double Diamond formally, don't feel behind. The framework works whether you name it or not. Naming it just makes the parts easier to talk about together.

The seven activities inside the diamonds

Within the two diamonds, seven activities are where I actually spend my time. They're not steps in a strict order — the diamond visual flattens them. In practice they overlap, they double back, some phases get thin treatment when the problem doesn't warrant more, and others get weeks.

01 · Understand the system

Users · business · product · technology

This is the first activity for a reason. Before a problem is framed, before a direction is shaped, before anyone starts sketching, I want to understand the system I'm operating inside. That means the users' actual context — not the personas, the context — but also the business's constraints and priorities, the product's history and where it's headed, and the technology underneath, including the data.

Complex product problems are almost always systems problems. Skip this and you'll design against the wrong constraints. Or you'll design against no constraints, and the design will die in engineering review.

Senior signal here: you can hold four kinds of context — user, business, product, technical — in the same head at the same time, and you can move between them without losing sight of any one.

02 · Frame the right problem

Evidence · gaps · opportunities

Framing is the highest-leverage move a designer can make. The problem you're handed is almost never the problem you should solve. Not because the person who handed it to you was wrong — because framing benefits from research the person often didn't have time to do.

Framing means going from "we need better search" to "we need discovery, comprehension, and lifecycle to hold together, and search is one strand of that." It's the moment where you look at the evidence and say: this looks like problem A on the surface, but the underlying shape is problem B. Then you argue for problem B, with evidence, and the team decides.

If your job is to execute against a framing you don't believe in, you are being paid to design the wrong thing. Reframe, or ask why.

Senior signal here: you can distinguish an ask from a problem, and you're willing to argue for the problem behind the ask when the evidence supports it.

03 · Shape direction

Principles · requirements · trade-offs

The second diamond starts here. Framing gave you the problem; direction is your first pass at what the answer should look like — not the interface yet, but the shape of it. The principles the design will follow. The acceptance criteria it needs to meet. The trade-offs you're deliberately accepting.

Writing acceptance criteria is often thought of as PM work. In my practice it isn't. If I've done the framing, I'm the one who best understands what the design needs to do. Writing the criteria myself keeps the direction sharp and makes the eventual handoff cleaner.

Trade-offs are the important word in this activity. Any direction worth having has trade-offs. Naming them explicitly — "we are optimizing for X, at the cost of Y" — is what separates a designed direction from a wishlist.

Senior signal here: you can articulate the trade-offs you're making and why, and you can defend them in a room that includes people whose priorities differ from yours.

04 · Make ideas tangible

Flows · prototypes · AI-assisted exploration

Design happens here, in the sense most people mean it. Interaction models. Flows. Prototypes.

I lean heavily on prototyping to think, not just to communicate. A prototype exposes gaps in the direction that no document will. Building a working version — even a rough one — forces you to answer questions the framing left open.

This is also where I use AI-assisted exploration. Not to replace design judgment. Not as an accelerator that produces the design for me. As a way to generate more variants faster than I could alone, to explore edge cases I'd miss, to draft technical scaffolding for a prototype in an hour instead of a day. AI is a tool that widens what I can consider. The judgment about what to keep is still design work.

I mention AI here, at Make ideas tangible, because that's where it changes the shape of the practice most. Not because it defines the practice.

Senior signal here: you prototype to learn, not to present, and you can tell the difference.

05 · Validate & refine

Users · feasibility · iteration

Validation is not a phase you visit once at the end of Develop. It runs through Make ideas tangible, and it runs into Deliver. In my process, this activity sits at the seam between the two — because that's where it actually lives.

Validation has three parts:

• Users. Does the design work for the people it's for? Test it. RITE sessions are cheap and shift the design before it locks. If you can't run user tests, at minimum run heuristic evaluation and structured internal critique.
• Feasibility. Does engineering agree it can be built at the fidelity the design assumes? Bring engineering in early. A design that looks great in Figma and is unbuildable is a failure, no matter whose fault it is.
• Iteration. Validation should change the design. If it doesn't — if every session ends "confirmed the direction" — you're not running validation, you're running presentations.

Senior signal here: you can distinguish validation that shifts the design from ceremony that protects it.

06 · Partner through delivery

Engineering · implementation · quality

The design is not done when the mockups are done. What ships is what users experience, and what ships is engineering's product. Partnering through delivery — sitting with engineering as trade-offs surface during build, catching quality issues before they become customer-visible, and making calls on interaction detail as things go live — is where senior designers add value that mid-level designers often don't.

I use the word partner deliberately. Not "hand off." Not "spec." Partner. If you consider yourself done at the mockup, you'll be handed decisions later that shape the product without you.

Senior signal here: engineers reach for you when something in the design meets the reality of implementation, because they know you'll help — not defend the mockup.

07 · Learn & evolve

Outcomes · feedback · opportunities

The last activity, and the most under-invested. What did we learn from what shipped? What did users actually do? What did the metrics show? What did the field surface that we didn't predict?

Learning is what closes the loop. It's what makes the next Understand richer than the last one. If you skip this, you'll be designing on the same assumptions three cycles later, wondering why the same problems keep recurring.

Learn & evolve isn't about proving the design "worked." Sometimes it didn't. That's information. What matters is that you looked, and that what you saw flows into the next cycle.

Senior signal here: you insist on the retrospective loop even when nobody else is asking for it — because you know that's what compounds practice over time.

Learning feeds the next cycle

The dotted return arc on the diagram is not decoration. It's the point.

A design process that ends at Deliver is fundamentally incomplete. The value isn't just in the design that shipped — it's in the practice that got smarter through the process of shipping. The next Understand is better than the last one because Learn happened.

If your organization doesn't invest in this — if there's no retro, no post-launch review, no capacity to circle back to the same problem armed with new information — you have a design process, but you don't have a learning practice. You'll ship. But you won't improve.

What sits underneath — leadership behaviors

Four behaviors run continuously beneath the activities:

• Align. Get the people who need to agree, on the same page. Not once. Continuously.
• Influence. Move decisions with reasoning, evidence, and a clear point of view — without formal authority over the people you're influencing.
• Make trade-offs. Name what you're choosing to protect and what you're choosing to spend. Get the trade-off explicit, get it agreed, and move.
• Communicate. Write it down. Make it findable. Explain it to different audiences at the right level of abstraction. Communication is design work; the design is nothing if it can't be understood by the people who need to build it, ship it, and use it.

These aren't a phase. They aren't a step. They're what a Lead or Principal designer does while the seven activities are happening. If they're missing, the process still runs — but the outcomes are noticeably worse, and the reason is often invisible until you look for it.

Where AI actually fits

I want to be careful about this one because there's a lot of noise around it right now.

In my process, AI is an accelerator inside Make ideas tangible. Not a phase. Not a layer above design thinking. Not a replacement for the framing work in Diamond 1 or the delivery partnership in Diamond 2. Where it changes my practice most is:

• Rapid exploration of variants. More options in less time.
• Prototyping technical scaffolding fast. So a design can be interactive and testable, not just visual.
• Surfacing edge cases I'd miss. A model prompted well can flag failure modes I wouldn't have thought of.

What AI does not do in my practice: reframe problems, make design trade-offs, decide what to ship. Those are still design judgment, and design judgment is the reason I'm in the room.

If you want to add AI to your process, add it here — as an accelerator inside the making. Don't build a process around it. The process is the same. AI just makes some parts of it faster.

Adapting this for your own practice

If any of this is useful, take it. A few things worth knowing before you do:

Not every problem needs all seven activities in full. A quick fix to a well-understood bug doesn't need a discovery phase. A well-scoped feature building on a mature product may only need light framing. The activities are a menu — read the problem, use what fits.

The framework is the least important part. The seven activities matter more than the diamonds. The behaviors that sit underneath — Align, Influence, Make trade-offs, Communicate — matter more than the activities. The Learn cycle matters more than any individual activity. If you keep the shape and lose the underneath, you have a diagram, not a practice.

Naming activities helps teams collaborate. Even if you don't use the Double Diamond visual, having common language for "we're framing" versus "we're shaping direction" versus "we're validating" keeps teams from talking past each other. Adopt or invent naming that fits your team.

Adapt the language to your organization. Frame the right problem might land in your context as scope the initiative. Partner through delivery might be engineering enablement. Use the words that will actually get used. The concept matters more than my labels.

What NOT to do

Common failure modes worth flagging:

• Skipping Understand and going straight to Make. You'll ship a fast, high-fidelity, wrong thing. Speed is not a substitute for framing.
• Treating the two diamonds as one act. Problem-framing and solution-framing are different work. Conflate them and you'll define the solution before you've defined the problem it's solving.
• Making "iterate" the answer to everything. Iteration inside a bad framing is polish on the wrong object. If iteration isn't shifting the framing, revisit it.
• Building an AI layer around the process. AI doesn't reframe. It doesn't decide what to ship. Insert it where it accelerates a specific activity; don't rebuild the practice around it.
• Considering the design done at ship. What happens after ship is what your users experience. If you're not partnering through delivery and looping back through Learn, your process ends where it matters most.

The point

A design process is a shape you can look at. A design practice is the thing underneath — what you actually do when the work gets hard.

The Double Diamond is a good shape. The seven activities are how I fill it in. The leadership behaviors and the learning loop are what hold it together over time.

If any of this helps, adapt what fits and leave the rest.