The design process did not die. It moved. It used to live in phases, workshops and sign-off meetings, where everyone could see it. When the work runs through agents, AI assistants that write and change a product's code from plain-language instructions, it lives in the setup: the conventions the agent reads, what it is made to remember, where it has to stop and ask, and the gate a person holds before anything ships. A team that believes it has dropped process has usually just moved it somewhere nobody looks.
What the obituary gets right
The case for the obituary is strong, and Jenny Wen makes it well. On Lenny's Podcast (opens in a new tab) in March she argued that the classic sequence of discovery, then mock-ups, then iteration is becoming obsolete, with engineers forcing the designer's role to change. She had made a similar case in a keynote at Hatch in Berlin, written up by Simon Willison (opens in a new tab), which questioned the routine of research, personas (made-up profiles of typical users), journey maps and rough layouts before anything gets built, and pointed instead to prototypes, now cheap enough to make first.
Underneath the headline, the skill that matters moves: when anyone can make anything, it is choosing and curating what gets made.
I agree with almost all of it. The persona nobody opened after the workshop, the journey map made because the template had a slot for one: that ritual has earned its funeral. Prototyping first is often the right order, and with agents it is frequently the only sensible one.
Two things called process
Where I part ways is over the word. "Process" has been doing two jobs, and the obituary covers only one of them.
The first is the ritual: the named phases, the deliverables, the order they arrive in. That is what is dying, and it should.
The second is what the ritual was for. Somebody looked at the problem before somebody solved it. The alternatives were seen side by side. The constraints that could not move were written down where the next person would find them. Somebody with the standing to say no saw the thing before customers did. And when a decision was made, there was a record of why.
Those functions do not stop being necessary when the phases go. A prototype made in an afternoon still has to be checked against the problem, still needs someone who can say it is not ready, and still produces a decision that someone will want to understand in six months. Even on Wen's account the designer still chooses what gets made, so the route still exists. The open question is where it is written down.
Where it went
When I build Card Orb, my card-collecting tool, with coding agents, every one of those functions is still present. None of them happens in a meeting.
The design principles document became the conventions file the agent reads before it starts. The research folder and the decision log became the records it has to search before it changes anything that already exists. The checkpoint where a lead signed off became a short list of situations in which the agent stops and asks instead of deciding: anything destructive, anything touching real money or production, a genuine fork with no better option. And the crit, the group critique of the work, became a single review at the moment a change is saved into the project, with a verdict and the evidence for it.
I have described the memory side of that setup before, so the point here is a different one. That setup is a design process. It encodes who decides what, in which order, against which standard. It is not shaped like a timeline, so it does not look like a process, and that is exactly what makes it easy to miss.
Invisible process is still process
The risk is not that teams lose their process. It is that they keep one without being able to see it.
A team that says it has moved past process and now simply prompts and ships is still running on something: one person's habits, the defaults of a tool, an instruction someone wrote in the first week that nobody has reopened since. That is a process, with all the authority of the old one and none of its visibility. Nobody argues with it, because nobody knows it is there. A new designer cannot learn it except by watching. When it produces something wrong, there is no step to point at.
The old phases had one virtue nobody noticed until they were gone: you could see them. A workshop on the calendar is a process anyone can challenge. A sentence in an agent's instructions is a process almost nobody will.
What the setup has to contain
If the process now lives in the setup, the setup deserves the care the process used to get. For design work I want at least these in it, written where people and agents both read them.
The problem, as a file
Not the first prompt of a session but a standing description: who this is for, what they are trying to do, what done looks like. Every piece of work is checked against it, and it changes only on purpose.
The house calls
The decisions this product has made that a capable model will get wrong by default: the named colours and sizes, the tone of voice, the minimum standard for accessibility, the patterns already ruled out. Generic advice is persuasive, so these have to outrank it explicitly.
Where it must stop
A short, specific list of the places an agent may not decide alone. Copy that makes a promise to a customer. Anything that moves or displays money. Removing a state, an error or an empty view. Reversing something a decision record says was deliberate. In payment work this list is long, and it should be.
Memory that includes the rejections
What was decided and why, and also what was tried and dropped, with the reason. An agent that cannot see the rejected options will offer them again, confidently, as new.
The gate
A named step before anything ships, with a person at it and criteria written in advance: the rendered result on a real screen, the states nobody designs first, the one thing this feature cannot get wrong. A gate without written criteria is a mood.
A way for the setup to change
The retrospective, the look back at what went wrong, moved too. When review catches something, fixing the output is half the job. The other half is changing the setup so the next run does not need catching. A setup that never changes is the old ritual again, in a new file format.
Trust needs an address
Wen ends on trusting ourselves again, and she is right about whose judgment should lead. But an agent cannot read trust. It reads files. Whatever a team believes about how good work gets made has to be written where the agent will find it, or the agent will follow a process anyway.
It will just be someone else's.