The Design Process Is Dead. Here's What's Replacing It.

Summary

Why does it matter? Because the design process that built every great product you use is already obsolete.

Jenny Wen — head of design for Claude Co-work, former director of design at Figma — has a front-row seat to the fastest restructuring the design profession has ever seen. Engineering velocity didn't just speed things up; it collapsed the gatekeeper model entirely. What replaces it is more fluid, more technical, and far less comfortable for designers trained in the old gospel.

• The classic research-diverge-converge-mock cycle is functionally dead, killed by engineers who can prototype faster than designers can open Figma
• Design time in mocks dropped from 60-70% of the job to 30-40% — the gap filled by paired engineering sessions and direct implementation
• AI products can't be clickable-prototyped at all; the model's non-deterministic behavior means you only learn by running real users on real models
• Trust in a rough early product is built through visible iteration speed after launch, not through polish before it

Engineering velocity didn't give designers a new tool — it dissolved their old role entirely

"This design process that designers have been taught, we sort of treat it as gospel. That's basically dead." Jenny Wen made that declaration at a Berlin conference in September — and by the time the conversation was recorded, she felt the talk was already outdated.

The mechanism is straightforward: when engineers can spin up seven parallel Claude agents and have working prototypes before a designer finishes mocking, the sequential handoff model breaks. Designers are no longer the ones who shape something before it gets built. Engineers build first, and the designer's job becomes guiding and polishing what's already moving.

Wen is explicit that this isn't a design-led revolution. Nobody in the field stood up and said the process needed to change. Engineering tooling changed, and design is trailing the consequences. She compares it to a forcing function: "The result of engineering changing a bunch is that design is sort of forced to change."

The implication she draws isn't defensive — it's operational. Stop trying to preserve the gatekeeper role. Let engineers cook. The designer's job now has two modes: help executing what's already in motion, and point the team toward a short-horizon direction before the next sprint of agent-powered shipping starts. Fighting the old process means blocking the team. Letting go of it means actually being useful.

The time allocation has inverted: mocks are now 30% of the job, not 70%

Three years ago, Wren estimates she spent 60-70% of her working time mocking and prototyping. That number is now 30-40%. The freed-up hours didn't disappear — they moved into two new buckets: paired engineering sessions (jamming directly with engineers on things they've already built) and actual implementation (going into the codebase to polish and ship).

The vision work changed shape too. The old model was a deck pointing two to five years out — sometimes ten. Nobody builds those anymore. "We actually don't know what's going to happen in 2 years," Wen says. Vision work now means a 3-to-6-month prototype that points the team in the same direction — not a beautifully story-told presentation, just something people can react to and orient around.

Wen describes her own current week as a mix: time set aside to think about what the next three months of Co-work could look like, daily conversations with engineers about what they've just built, and stretches of time in VS Code polishing frontend details. She still uses Figma — it remains the right tool for exploring eight to ten directions simultaneously, something that coding tools handle poorly because they push you to invest linearly in one approach. But Figma is no longer the center of gravity. The job is now wider, messier, and more collaborative than the clean sequential process designers spent decades refining.

You cannot prototype an AI product in Figma — the model's behavior is the design material

"You can't mock up all the states. You can't theorize. You can't even make a clickable prototype with it. You sort of have to use the actual models underneath."

For AI products, the non-determinism isn't a bug to design around — it's the fundamental reason traditional design artifacts fail. A clickable prototype assumes fixed states. A Figma mock assumes you know what the output looks like. Neither assumption holds when the model is the product.

Wen points to Claude Co-work as the clearest example. The product's direction came not from a design spec but from watching what users actually did with a rough internal prototype. Use cases that seemed obvious in theory turned out wrong; use cases nobody anticipated emerged from real sessions. "You have to discover use cases as you see people using them."

This changes where design exploration should happen at the earliest stages. Skip the static artifact. Build something in code with the actual model running underneath it, put real users in front of it, and treat what they do as the design research. The Co-work origin story — multiple internal prototypes, a dense agentic interface called Claude Studio that Wen initially couldn't parse, energy she couldn't fully explain — is the template. The form factor only became clear once the team was watching people use it, not before.

Shipping rough and iterating publicly is now a legitimate brand strategy — but only if you move fast afterward

Claude Co-work launched as a "research preview" with known flaws, under the explicit framing: this is the worst it will ever be. That turned out to be the right call. The product blew up. The reason it worked, Wen argues, isn't that users forgive rough launches — it's that visible iteration speed after launch functions as trust-building in its own right.

"The way you really lose trust around quality and releasing something early is if you release it early and then nothing ever happens. That is what degrades a brand."

The contract Wen describes is specific: ship early when the core value is real even if the execution is rough, then demonstrate responsiveness publicly — respond to feedback, ship fixes fast, make it visible. The Anthropic team tweeting replies and shipping updates the next day isn't just community management; it's the mechanism that makes the research preview framing credible.

Lenny distills it cleanly: "Building trust through speed." Wen extends it: speed plus making people feel heard. Fast fixes that ignore what users actually complained about don't build the same trust as fixes that visibly respond to specific feedback. The Co-work example compressed this loop to days — a timeline only possible because Claude Code itself could implement the fixes quickly. The release strategy and the engineering tooling are now entangled.

The best designer hire right now might be someone with almost no experience

Wren identifies three archetypes worth hiring, and the third is the one most teams are ignoring.

The first is the block-shaped generalist — not someone who's adequate across many things, but someone who's 80th-percentile good at several distinct skills. The T-shape metaphor breaks down; imagine so many overlapping Ts that the skill set looks like a solid block. Rare, hard to find, extremely valuable as the role expands toward PM and engineering territory.

The second is the deep T specialist — someone whose vertical goes farther down than anyone else's. Wen's examples: a designer who's essentially 50% software engineer, or someone who's the top 10% in the industry at visual craft or icon design. In a world where anyone can generate anything, genuine depth differentiates.

The third — and the overlooked one — is the craft new grad: early-career, wise beyond their years, deeply humble, and without baked-in process habits. "Having somebody who almost has a blank slate and is just like a really quick learner... that's super valuable." Most teams default to senior hires with established workflows. But in a role that's restructuring fast, the absence of old habits is itself an asset. Senior designers who've spent a decade doing research-diverge-converge have something to unlearn. The craft new grad has nothing to unlearn and everything to build.

Design managers who stayed in management through this transition are operating on outdated empathy

Wen spent part of her time at Anthropic managing a team, then stepped back to full-time IC work — and says the decision gave her skills she couldn't have acquired any other way during this specific period.

"The design process has changed so so much in this past year and I feel like I've just picked up so many hard skills that I wouldn't have necessarily had the time to do if I was just managing a team."

The problem isn't just skill atrophy. It's empathy calibration. A design manager who hasn't lived through the shift to paired engineering sessions, last-mile implementation, and code-based prototyping is giving direction and feedback from a mental model of a job that no longer exists. "I think it's actually pretty hard to empathize if you are not working in that way or you're not always testing all the tools and trying stuff."

Her proposal draws from engineering: make managers take IC rotations before moving into full-time people management, the same way engineering orgs require EMs to spend time on technical tasks before taking the helm. Design has historically been far more people-management-oriented — and Wen thinks that orientation is now a liability if it's not paired with hands-on fluency in how the work actually runs today.

The legibility framework: treat internal energy you don't understand as a signal, not noise

A 2-by-2 from SPC partner Evan Tana — largely unnoticed on Twitter — became one of Wen's most-used mental models. The framework maps founders and ideas across a legibility axis. A fully legible founder with a fully legible idea is probably working on something obvious that others will implement first. The interesting quadrant is the illegible idea: something on the frontier that isn't being articulated in a way that lands yet, but has unexplained energy around it.

Wen applies it internally at Anthropic. When she's scrolling through Slack looking at what teams are prototyping, she's not just looking for things she understands. She's looking for things she doesn't understand that other people seem excited about. "If there is some energy around it but I don't quite always understand what the energy is — dive deeper and try to understand what that is."

The Co-work example is concrete: an internal prototype called Claude Studio, built on an agentic harness, dense and confusing to look at. Wen couldn't parse it as a designer. But research folks and engineers were visibly energized by it. She leaned in. The skills framework and context-display patterns that eventually appeared in Co-work — Claude's plan, to-dos, files in progress — were pulled from that illegible prototype. "How can designers almost be more like VCs in this way internally, when we're looking at prototypes?"

The designer's job is becoming the last human judgment layer — and that layer is shrinking

Wen believes AI will get better at taste and judgment than most designers currently assume. The lesson from watching AI consume software engineering — where the best engineers in the world now trust outputs they don't even read — is that no skill category is safe from acceleration.

What remains, at least for now, is accountability: someone still has to decide what gets built and own the decision when it's wrong. Not taste in the aesthetic sense, but judgment in the organizational sense — the human in the loop who is on the hook if the thing ships broken or misses what users needed.

That's a narrower and more exposed position than the design profession has historically occupied. The process is gone. The mocks are secondary. What's left is judgment, direction, and the willingness to get close enough to the actual work — in the code, in the prototypes, in the Slack — to exercise it well. The designers who thrive next won't be the ones who defended the old process. They'll be the ones who figured out what they were actually for.