Design Thinking, Redesigned

For the past two decades, design thinking has been treated as sacred. The Double Diamond. Discover, Define, Develop, Deliver. Research first, problem statement second, solution last. Every design program teaches it. Every consulting firm sells it. Most product teams still live by it.

I don’t think it’s going away. But I do think it’s no longer the only way — and for a growing number of designers working with AI, it’s not even the primary way anymore.

The process is changing. Not because the thinking behind design thinking is wrong, but because AI has fundamentally changed how fast we can move through it.

The Discovery Phase Just Got Compressed

In the traditional process, discovery is expensive. You plan interviews, recruit participants, synthesize findings, build personas, map journeys — weeks of work before a single design decision gets made. That rigor exists for a reason. You’re trying to understand a problem before you commit to solving it.

AI doesn’t eliminate that need. It just changes the timeline.

When I watched Jenny Wen talk about her team’s approach to designing Claude, something she said crystallized a feeling I’d been having for a while. The idea of solution before problem — not as a shortcut, but as a legitimate design method. The prototype becomes the research instrument. Every iteration surfaces new understanding. You’re not skipping discovery. You’re doing it in motion.

I’ve experienced this firsthand. With AI, I can go from a rough idea to a working prototype in hours. That prototype — broken, incomplete, wrong in interesting ways — teaches me things about the problem that three rounds of stakeholder interviews might have missed. What works, what doesn’t, why it breaks, what’s missing. The failures are information.

A lot of designers hit this point and say the AI is stupid. I think that reaction is exactly backwards. That friction is the design process working.

The Complaint Is the Brief

Here’s something I’ve noticed about how I start projects now — and I think it’s more universally true than designers want to admit.

It usually begins with a complaint.

Not a formal problem statement. Not a research question. A complaint. Something frustrating, something broken, something that shouldn’t be this hard. And here’s the thing: we’re all wired for this. Humans know how to complain. We’ve been doing it our whole lives.

That complaint is the pain point. It’s the most honest version of the problem statement you’ll ever get — unfiltered, unpolished, and completely real.

When I start working with AI this way, something interesting happens. The AI starts asking questions. Clarifying, pushing back, asking what I mean. It’s doing what a good researcher does in a discovery interview — helping me articulate something I felt before I could explain it. Except it happens in a conversation, not a formal session, and it takes minutes instead of weeks.

I don’t need to draw anything yet. I just need to give AI enough to start with. And as an experienced designer, I already know what to look for in what comes back.

Solution First

There’s another shift happening that feels more uncomfortable to talk about — but I think it’s real.

Sometimes the right starting point isn’t the problem. It’s the possibility.

We’ve seen this before. Early Apple products weren’t built to solve a defined user need. They were built around what the technology could do, and the need crystallized through use. The iPhone didn’t start with “users need a touchscreen phone.” It started with “what if the whole thing was the screen?”

I’m not saying ignore users. I’m saying sometimes the product reveals the need, rather than the other way around.

I had this experience recently building a tool with Claude Code. I started by describing what I wanted to do — roughly, informally, the way you’d explain something to a colleague. Claude built the backend logic in Python and walked me through what each command would do. My immediate reaction wasn’t to stop and write a requirements document. It was: this is great, but I don’t want to type commands every time. So I asked for an interface. Two buttons. Claude asked what else I’d want, made technical decisions I didn’t need to make, and we kept going from there.

At no point did I stop to define the “primary user persona.” But by the time we’d gone through a few iterations, the user needs were completely clear — clearer, honestly, than if I’d tried to define them upfront. Because I’d actually used the thing.

What This Means

I’m not arguing that the Double Diamond is dead. For large-scale enterprise problems with many stakeholders and high stakes, structured discovery still matters enormously. My work at RTX and FedEx wouldn’t have been possible without it.

But I am arguing that it shouldn’t be the only model designers reach for. And I think the designers who will do the most interesting work in the next decade are the ones who can move fluidly between both modes — rigorous and structured when the problem demands it, reactive and iterative when speed is the advantage.

The design process used to feel like a solo methodology you followed. With AI, it feels more like a conversation with a team — messy, fast, generative, and constantly revealing things you didn’t know you needed to know.

That’s not a loss of rigor. That’s what rigor looks like when the tools get better.