The Product Picnic has gotten big! And rather than pass the cost of hosting it onto my readers, I’m funding it through some side projects. Now is your opportunity to support one of those: I’m doing a full-day workshop together with friend-of-the-picnic Sara Wachter-Boettcher in Philadelphia on July 31st. Come learn how to stop waiting for permission to kick ass, and start practicing UX without excuses.

Back to our regular programming! We pick up where we left off last week, when we discussed how the “more is more” approach to software — the paradigm that AI embraces and accelerates but did not invent — is running out of gas. And if you don’t want to take my word for it, read a serious newspaper citing serious people who are worried about what’s being done with their money.

But “AI ruined everything and now we’re doomed” is not sufficient analysis (indeed, many criticisms of AI slop end up a kind of slop themselves). For an industry that’s always struggled to prove its worth, proclamations of the end of the world are just another Tuesday.

So in a way, this essay is actually an extension of a much older Picnic: design is not dead, but has not yet arrived.

And the reason that design has not yet arrived is that the logic of the industry has — so far — allowed companies to avoid having to do it. As long as you can scale through simply doing more, there’s no reason to think about better. Better is a qualitative change. Better is risky. More is safe, and the more we are boxed in by half-heartedly justified layoffs, the more appealing safe becomes.

But the honeymoon period of more fades with the first token bill, and the conversation inevitably transitions into: would it be possible to still get more from our employees, but give them fewer resources and support to achieve these new targets? In other words: can we shift the consequences of our shortsightedness from the employer to the worker?

The answer, by the way, is no. But on the journey to that “no”, a lot of ordinary people have their livelihoods ruined. And yet, there’s only so much we can do now that “more” has run its course and the formerly infinite money supply shows signs of running dry. Companies will soon be forced to admit that the contradiction of “do more with less” cannot be resolved at the individual employee level.

I won’t pretend that they will suddenly have an epiphany that design offers an escape from this dilemma. But I do want to cover some ways we can get ready to seize that moment.

At the root of “do more with less” is the idea that we can achieve more leverage if we apply the same amount of force to somewhere else in the system. But the highest bang for your buck comes from applying that force to changing the system itself. This is called service design, and it rules:

Now, I don’t actually care about titles. A UX designer can still do service design. Hell, service design at your company is probably being done by a product manager (if you’re lucky). But it’s worth calling out the implications of this paradigm shift from unilaterally designing a product for consumers, and designing a service that mediates interactions between entities (power centers, even!) with agency.

The former is very easy to scale through the logic of more. Users are fungible because they are rendered fungible by the product. This is no accident of the material, but an axiom of non-LLM software business models: it costs almost nothing to replicate a program, so if you can bear the initial cost of writing it, the unit economics guarantee pure profit.

The problem is that the huge cost of writing code returned every time users demanded changes to the product, which messed with the economics. The more you allowed the nature of your business to evolve, the more expensive it would be — and so the trick is to grow like a plantation, getting bigger and bigger without allowing transformative relationships to form:

The notion that computer science is not sufficient to explain interactive systems is not a new one: this paper from 1993 may be older than many people reading this, but somehow has ideas I’ve yet to see implemented in the practice. Instead, tech has set itself upon the doomed trajectory of replacing as many humans as possible with programs. Even before LLMs, we had Big Data — the idea that a system could just Know, and then Do the Right Thing. Analysis and decision-making became standardized and commoditized; the entire concept behind SaaS was founded on locking your org’s spreadsheets in a prison and then charging for visitation rights.

But as we all know, the “automagical” approach only worked until it suddenly didn’t. As soon as real life deviated from the tidy “use cases” we were sold, we found that the designers had sawed off any controls that would let us steer it back onto the right path. The people who knew what to do when things broke were the very ones laid off in pursuit of the new “agentic” vision.

As the result, the more outdated a system is, the more resilient it is to error — and the more we can learn from it when designing automation that grants agency to humans instead of solely to machines. These are the systems that will remain standing when they encounter reality.

This is the pivot point where “scale the thing for ever” thinking fails. Despite the best efforts of product managers, the emergent properties of software change its very nature as it scales. There is a very low ceiling on how useful up-front decisions can be.

The result is that a release plan (what is usually and incorrectly called a “roadmap”) packed full of features is the worst way to engage with this kind of complexity. The problem you are solving does not sit still. They are wicked problems.

Fortunately, design has tools for dealing with wicked problems. Design is a tool for dealing with wicked problems. But this moment demand that we learn to apply that tool above the feature design level:

One of the biggest mistakes the industry has been making so far is conflation between “action” and “shipping software.” This logic has led vibe coded slopware to colonize every company’s PR queue today: we will simply ship every half-baked idea and see what happens. Not only is this extremely wasteful — burning everything from tokens to user trust — but it doesn’t even work, because no amount of small-scale tweaks will ever add up to one big, transformative idea.

The answer is to embrace action that takes place outside of the “fidelity cascade” of a software interface, outside of the spectrum that begins with wireframes and ends with production code.

Ecosystem mapping is one such action — and I will emphasize that as with all maps, is is the activity of mapping rather than the resultant map that produces value.

Persona landscape mapping is another approach to work that enables deep thought over layout design, though all the caveats with personas apply:

Finally (lest I continue to receive accusations that I’m claiming UX is at a dead end) I want to spotlight a very cool project in the early stages of development. Jason Hobbs has been putting together a framework for Information Architecture to engage with the challenges I’ve talked about in this issue:

Hobbs has shared a three-part lecture series (1, 2, 3) which is much more penetrable than the IAD website itself for understanding what this framework is trying to do. It’s dense, juicy stuff, so you may come away from it with nothing more than a sense that new and interesting things are happening — but in this day and age, even that sense is a precious commodity.

— Pavel at the Product Picnic