Design is in crisis. But this is business as usual. Design is permanently in crisis, such that we probably wouldn’t know what to do with ourselves if the crisis ever ended.

There are two parts to the permacrisis: a lack of trust, and a lack of rigor. And the “progress” that is currently being painted as inevitable is taking us in the wrong direction on both of these issues.

Lack of trust is not unique to design; it permeates the entire product development lifecycle. That’s why designers attempting to pivot to product management in hopes that they will get to call the shots end up in exactly the same place:

We touched on this subject last week: orgs built for trust can get the right people together in a room and crunch through deadlocked issues extremely quickly, regardless of the tools they use. Ironically, this kind of collaboration (delivering actual velocity) is in direct opposition to the thing orgs “hire” to try and achieve velocity: Agile development. Even before it mutated into a Scrum-monster, Agile was designed to solve the goalie problem for software developers: they were at the end of the waterfall and didn’t want to catch the blame for things being late. Devs had to find a way to write software in an environment where cross-functional colleagues could not be trusted.

But in an environment with trust, these ceremonies are obsolete. The cutting edge of organizational innovation is concerned with dismantling them as fast as possible and watching immovable backlogs melt away simply by giving people ownership over doing so and trusting them to do it.

There’s an interesting side effect to our current stage of the LLM hype cycle: in the race for maximum agility, organizations have given it functionally unlimited trust. Ten years ago, you wouldn’t dream of giving everyone in the company access to Github (ask me about filing Jira tickets to change a static string on a website); today, Claude is trusted to run roughshod over the codebase.

Is that trust earned? Of course not! The wave of low-quality code is driving devs crazy! But for managers who do not have any other strategy, the allure of letting Builders “just do things” is impossible to resist. Perhaps if they build the right thing, it doesn’t matter so much that they didn’t build the thing right?

Wrong! The solutions are also bad, because research takes time (spent on, among other things, building trust and establishing credibility) but vibes are instantaneous.

AI is making teams feel super productive by skipping that trust-building process. But the orders-of-magnitude increases in lines of code to prod are not producing any customer value, or for that matter economic value: a survey of app stores has shown that no one is using all the apps that have cropped up in this “agentic” coding era.

Accelerating the pace of delivery from once a month to once a week doesn’t actually make you get to a better product four times as fast if you still need that month to go through the rest of the OODA loop: observe, orient, decide. Anything you do under “act” before you’re done with the other three is waste.

Real insights always run on human time. Data needs to roll in. Analysis needs to happen, at a pace slow enough to actually pay attention to the data and not just mine it for what you expect to see. Then all that knowledge needs to propagate throughout the organization. Mental models needs to update, to wrap around the “so what” of it all.

But taking people’s problems seriously takes time, and sometimes it turns out that you shouldn’t do the thing you really wanted to do. That really hurts your velocity, so it’s important to insulate yourself from this outcome.

It used to be that we did this through fake empathy: designers described themselves as “empathetic” and product teams performatively left an empty chair in the room to represent “the user” in order to justify why they never actually go out and talk to people. But somewhere along the line, we insulated ourselves from users so much that even that paper-thin excuse vanished. Even pretending got too hard.

Designers stopped talking about empathy and started talking about taste. And orgs as a whole pivoted to a new word, as if merely invoking it could make it real: ethics. Ethics language has been adopted across the industry, at a superficial surface level, to obscure the fact that this insulation is fundamentally unethical.

Not all empathy is fake, far from it. And not all ethics are fake, either. But when these things exist solely at the individual level, they may as well be. For example, Google’s DeepMind team had a clear ethical line (no militarization of their work) — a promise that Google unilaterally broke. Now the team is unionizing as a way to make those ethics meaningful.

Ron Bronson’s talk from last year is a really good take on why and how all the empathy in the world is powerless without the infrastructure to turn it into action:

Of course, the question underlying all such calls to action is “who is going to let us?” The Google example shows one approach. But faced with a stakeholder who is not antagonistic, merely wary, it is worth to put conversations around taste aside and look for more effective leverage.

Hence my emphasis on consequence above. Unless you have the muscle to buck the system (think more DeepMind union and less design auteur), you are going to have to work with it.

What the system want to do is simply go faster, in the mistaken belief that faster outputs automatically lead to better outcomes. But the outcomes themselves are still the goal. And outcomes across the industry are showing us that the path to “good” does not go solely through “fast.”

AI’s well of unearned trust is deep, but not inexhaustible. Our bosses are currently learning an expensive lesson: that rigor is not optional and tacit knowledge (both our own, and that of our users) cannot be automated. That realness cannot be faked.

When that lesson sinks in, rigor is what will let us seize the moment. But doing so will require a lot of trust. The acts of play that make design so powerful are incomprehensible to a spreadsheet. The autonomy we need to do the work — real ownership of the process — requires us to, first and foremost, build trust. That trust can only be built through rigor.

— Pavel at the Product Picnic