Welcome back to a sort-of part 2 to last week’s post, where we started to wrestle with the explosion of aimless prototyping.
The key insight from that week that I’d like you to carry forward is that prototyping is a qualitative research tool. But the semantic environments of our orgs are quant-driven, and struggle to understand this. The only thing we know how to do with a prototype is to ship it and see if the numbers on our dashboard go in the right direction.
This kills the product.
User Experience Rot
One of the most memorable presentations from IAC26 this week was Jared Spool’s hand-drawn rendition of his classic piece on user experience rot. Unfortunately, eight years of knowing about it hasn’t helped our software resist the trend. Version numbers creep up. Features aggregate. The cognitive load of understanding what any of it is for continues to stagger users.
LLMs make this trend even worse (as you might expect would happen when you scale up a broken process):
The harder case is a feature that succeeds just enough to survive. Some users adopt it. A few workflows start to depend on it. The team now owns it. It may not have made the product meaningfully better, but it has made the product larger.
That is how products become cluttered. Not because teams intentionally choose it, but because the threshold for adding something falls below the threshold for living with it.
Sure, code generators might be a solution for the problem of “not having enough features.” But that is not the problem with your product. The problem with your product is that there is already too much shit, and none of the shit is organized in a way that makes sense to people.
One line in my notes from Jared’s talk has a star drawn next to it. That line is: by the time you notice experience rot, it is too late. You need to prevent it from occurring in the first place.
C.R.E.A.M. (Content rules everything around me)
One of the classic moves to deal with experience rot is to slap on some labels that try to explain it to the user. This never works. And it’s not because users don’t read — it’s because your product was not designed coherently. Individual labels do nothing for sense-making if the system as a whole defies understanding.
The problem comes from looking at text as labels, things that are attached to the interface. But if anything, that relationship is the other way around: the interface wraps around the text and serves it to users. Interfaces are touchpoints of the system, but the text is the system. Take away all your <div>s and <script>s and the system should remain coherent; if it doesn’t, you did it wrong.
A lot of people do it wrong. And it starts with prototyping a page or a widget — an interaction — without taking care to establish what the user is meant to be interacting with.
In other words, you should prototype content first. Rather than prototyping content despite its unimpressiveness to stakeholders, you should do it because of that. Because a page of text resists being demoed. It does not try to seduce you into designing for the presentation, so you can stick to its intended purpose, which is learning. You can figure out what the moving parts need to be, and only then devote your focus to rendering them visually.
And because it doesn’t look like an app, a content-first prototype resists thoughtless integration into the product. Instead it becomes a valuable decision-making artifact against which product design work may be judged.
Everyone is always telling me how UX designers are becoming generalists, but for some reason that always means "learning to code” and content design ends up being treated as a separate thing. Prove me wrong. Start your next project with content design. Do it. Do it now.
And I actually have two links for how to do content-first design! One from the public sector (part 1, part 2). And another from the private sector (part 1, part 2). The principles of design are still the same. Only the medium is different.
— Pavel at the Product Picnic