Hey there, picnickers!
It seems like only yesterday that everyone was talking about how UX is dead (it was actually almost a year ago). But if you missed that discourse, good news: UX is dead again. Or specifically the design process, if the head of design at Claude is to be believed. Replaced by AI, of course.
Design is the applied science of decision-making
But while the breathless claims of design’s demise were taken at face value in 2025, people have caught on to the game at this point. When reading beyond the headline, it becomes clear that what AI proponents are actually mean by “design” is specifically production design.
The alleged death of the design process has nothing to do with AI at all; production designers abandoned it years ago as they fully switched gears to mastering Figma layouts for a living, and AI is just an excuse for them to finally admit it. But this approach to design relies on someone else doing the rest of the work for them:
The speed of making artifacts has never been the thing preventing organizations from doing high-quality design.
We can actually trace back this obsession with ever-faster cycles to the erosion of the design process. Without strategy, throwing things at the wall to see what sticks (frequently described as “build to learn”) is literally all you have left. You must ship an order of magnitude more things just to learn what research could have told you in an afternoon. You must “validate” all ideas in production, because you have no clear problem framing that would let you evaluate “good” in any other way.
The allegedly-dead design process has this cycle of trying and checking, too. But it can do this faster than an AI-generated prototype pipeline, because showing sketches to your team is always going to be a tighter feedback loop. And unlike validating in prod, this feedback loop also feeds back into problem definition. We can know we are wrong before we write a single line of code, because we realize we are solving the wrong problem.
AI makes you worse at design decisions
In this respect, the more AI you have in your process, the worse you are at it. Chatbots make you less likely to collaborate with other humans. They constrain your thinking towards a single, monotonous mode. And because they push you to move at a machine pace, while research with users happens at a human pace, it becomes ever-more tempting to lean into the illusory productivity of “building” in complete isolation from customers.
Baldur Bjarnason wrote a longer piece last year on the extent to which LLM usage can hijack our judgment — and thus our ability to evaluate its effectiveness. We feel like we are more productive, but we end up being misled by those feelings, because we can never be dispassionate observers of our own activities. Yet another study out this week shows how AI use actually intensifies work, but it is also interesting to look at the qualitative, self-reported data: AI proponents largely brag about the volume of work they do, not its fruit. They are, as the kids say, hustlemaxxing.
The bitter irony of it all is that the more of ourselves we invest into knowledge work, the more our judgment is undermined:
When we believe that our work determines our worth as humans, everything at work feels personal. A piece of design feedback feels like an attack on our character. A difference of opinion feels like rejection.
Designing the solution without framing the problem
LLM-driven tools afford making outputs, so we make lots of outputs with them. But orienting towards outputs means orienting away from thinking about the problem. This works fine when you are a production designer and answering “what should we be doing?” is someone else’s job. But if it’s your job, outsourcing this question to AI is going to be a disaster.
Because the real problem is in the world, and you are in your office. Good designers — designers who don’t see the design process as a waste of time before you get to the “real” work of making outputs — know that they need to get out of the technology to find the problem.
Understanding is not a deliverable that photographs well. You can’t put it on a roadmap slide. But it’s the difference between building something people use and building something which only accomplishes having built it.
I think by this point, it is clear that the real design process bears no resemblance to the linear “one-and-done” approach that design students take when practicing the Double Diamond for the first time. Discover, Define, Design, and Deliver do not have a secret 5th sibling named “Done” — the process is a cycle, a feedback loop, and like all loops it never actually starts at the beginning. No matter how early on you’ve been brought in, someone somewhere has already been doing something. Your job is not to hit them with a prototype at the highest possible velocity, but to understand what it was. Excavate what has already been done. Talk to humans.
— Pavel at the Product Picnic