There's a lot of discourse around the design process right now: throw out the process, trust your intuition, skip the research, and start building. Jenny Wen, design lead at Anthropic, has been one of its more prominent voices. The argument sounds compelling, especially to designers under pressure to move fast.
The Argument Against Process
The recent argument against design process goes something like this:
- The traditional design process feels outdated and disconnected from how good work happens.
- Iteration, intuition, and skipping steps are strengths, not sins. Build strong intuition, obsess over details, and remix processes to fit the moment.
- Great work often starts with solutions, not problem statements. Only after seeing a compelling prototype does one understand the problem it's actually solving.
Where the Argument Falls Apart
These observations aren’t wrong. But they don’t prove that process is unnecessary. They describe what experienced designers already do: they internalize process and adapt it to their work, moving fluidly through discovery, ideation, and evaluation rather than treating them as rigid steps. What looks like “skipping the process” is just compressing it — running faster through the stages and using experience as a guide.
The double diamond (and design thinking process) was never meant to be a literal checklist or template to be rigidly followed. Its purpose is to manage risk: help teams understand problems, explore solutions, and reduce the chance of building the wrong thing.
Solution-first approaches work when the problem space is mature, rich with embedded knowledge, and you're building on established patterns rather than inventing something new. It’s simplistic to presume you know what’s best for your users and you’ll build the right thing beyond these circumstances.
Process Compression, Not Abandonment
In this argument against process, the “design process" is treated like a monolith. Except that process isn’t one big thing you either follow or abandon.
The double diamond isn't "the process." The design thinking cycle isn’t “the process.”
These are just simplified representations of stages that anyone doing creative problem solving moves through: figure out what's wrong, figure out what to build, build it, learn from it. It’s a high-level description of what happens when you're trying to solve a problem you don't fully understand yet.
The "throw out process" argument leans heavily on a misrepresentation of how human-centered design works in practice. Experienced practitioners run it nonlinearly and contextually. The formal frameworks exist to make the thinking approachable and transferable.
When a seasoned designer working on a mature, competitive consumer product says "I just started building," they’re not abandoning the process. They’re compressing it — running an internalized version of it, often within established paradigms and well-tested patterns.
This process compression is driven by accumulated knowledge of the users and their needs from studying user behavior, analyzing competitor trends, and conducting research with experienced teams. What gets called "intuition" is really process, compressed and internalized through years of doing the work. The intuition designers trust was built by the very process they dismiss.
AI tools accelerate this compression further — and democratize it. Vibecoding has shrunk the gap between an idea and something testable; exploring, making, learning, and refining can happen in a single afternoon. Where experienced designers have always run the design loop faster than formal frameworks suggest, AI now enables less experienced practitioners to do the same.
Intuition Does Not Replace Process
The advice to embrace intuition in the design process appears liberating, but it oversimplifies a complex reality.
Not Everyone Can Operate on Intuition
Experienced designers like Wen have built their intuition over years of practice at established companies with strong design cultures and high-caliber teams. They have the skill, authority, track record, and team quality to lead with intuition-driven decisions.
Relying on intuition is far less viable for junior practitioners who haven’t accumulated the knowledge that makes intuition reliable. Allowing an experienced designer to make a fast, informed call is very different from telling a recent graduate to “trust themselves” without exposure to institutional knowledge, user behavior patterns, or business constraints.
Intuition Lacks Accountability
In many environments, decisions require documentation and justification. Process artifacts — research findings, usability testing results, or analytics data — are necessary for stakeholder alignment and approval. In most corporate environments, "I followed my intuition" does not survive a VP asking "What evidence backs this up?"
Intuition Won’t Work in Highly Regulated Industries
In industries with high-stakes or regulated products — healthcare, finance, government, accessibility-critical systems — process isn't a bureaucratic ritual but a safeguard against harm. Skipping research on a medical device UI is not the same as skipping research on a whiteboarding feature.
Intuition Carries Bias
Even well-earned intuition has blind spots. A seasoned designer can unconsciously anchor on familiar patterns or dismiss edge cases that don't fit their mental model. The deeper the intuition, the harder it is to detect the bias. Process forces assumptions into the open before they harden into costly mistakes.
Solution-First Design Works Only in Narrow Contexts
In the AI era, many experts advocate for solution-first design: starting with new technological capabilities and working backwards to identify the problems they might solve. This approach inverts the traditional model where you identify problems first, then seek solutions.
But the examples Wen uses to argue for solution-first design — such as the successful, widely adopted features of an AI product created by a well-resourced company — reflect survivorship bias. What we don’t see are the many solution-first experiments that failed: impressive prototypes that excited internal teams but never resonated with users, or features that shipped but saw little adoption because they didn’t address a meaningful need. Every approach looks brilliant when you showcase only the wins.
Rapid implementation is essential when designing for emerging technologies, but the speed of execution doesn't diminish the importance of proper problem framing. You don't need a formal problem statement or a discovery sprint, but you do need to know what you're trying to fix.
Solution-first design doesn’t mitigate risks and suits only a narrow slice of the industry. It can succeed in environments where product patterns are already well understood, users are sophisticated, and the design challenge is discrete differentiation. It also assumes a high level of organizational and UX maturity. Teams with strong domain knowledge and the experience to quickly recognize promising directions.
Most teams do not operate under those conditions. In low-maturity environments, where institutional knowledge is limited, or in novel and high-stakes contexts, starting with a solution can amplify the cost of wrong assumptions. In those cases, even a modest amount of upfront problem framing remains essential.
Process Literacy: Match Your Process to the Problem
The real skill in modern design is not the ability to abandon process — it’s process literacy: picking the right approach and tool for the problem. Know which process fits the job and understand the risks of not following it. Better yet, don’t claim you’re not using a process if you’re just applying it differently.
This doesn’t mean every project needs a six-week discovery phase, nor that every design problem should be treated like developing a medical device. It means matching the process to the problem: some problems require deeper investigation; others benefit from quick experimentation and iteration. The key is choosing intentionally. These decisions should be made deliberately, not because someone declared that the process is dead.
AI tools now enable rapid prototyping and iteration at a pace we haven’t seen before. But they don’t eliminate the uncertainty and the risk that the design process mitigates. Designers still need to understand problems and evaluate ideas. Process frameworks like the double diamond, design thinking, or jobs-to-be-done aren’t rigid procedures — they’re scaffolding. They teach ways of thinking that, once internalized, become implicit in how experienced practitioners work.
The question was never whether to follow a process. It was how the work we do maps to the problem we're solving. As AI compresses more of our workflow, and agentic systems begin to act, remember context, and make decisions on our behalf, skipping that question becomes more costly, not less.
