The Polite Distortions Catalog

Here is how a real problem dies. Not in a dramatic failure, but in a series of reasonable steps, each one performed by someone doing their job well.

A user is trapped in a budgeting tool, re-entering the same numbers across three screens, late, afraid of getting blamed if the numbers are wrong before a meeting with their boss. That's the moment: situation, stakes, time pressure, a system fighting back. Someone talks to that user and writes it up. "The key takeaway is they want a simpler workflow." A week later it becomes "Budgeting is frustrating." Two weeks later it's "Improve reporting UX." Nothing in that chain is a lie. Every version is defensible. And by the end, the person and the stakes are gone, replaced by a theme bland enough that nobody can argue with it and nobody can act on it precisely.

I call these polite distortions, the predictable, well-mannered ways user context gets crushed under translation pressure. They aren't moral failures. They're the default outputs of a system optimized for smoothness, legibility, and throughput. Reality is none of those things, so the system files reality down until it fits.

They tend to fall into a few patterns. The summary replaces the situation: a lived moment gets compressed into a takeaway that sounds reasonable and quietly loses the stakes. The persona replaces the person: a fictional "Busy Brenda" becomes a mask that makes guessing feel legitimate, and you stop designing for a real user in a real moment and start designing for a character on a slide whose behavior conveniently always matches your assumptions. The user becomes "everyone," specificity stripped out so nobody has to prove impact for anyone in particular. And the edge case becomes a landfill: inconvenient reality gets relabeled "rare" so it can be ignored without anyone admitting they're making a trade. In budgeting, "multi-entity, weird general-ledger rules, partial allocations" isn't exotic. It's the job, for exactly the large accounts you most want to keep. Calling it an edge case is how you build a demo instead of a product.

You will recognize these because you've done them. I've done them. They happen because organizations reward the thing that travels well. A summary survives a dozen handoffs. A situation does not. So the system keeps the summary and drops the situation, and everyone keeps moving, and the only signal that mattered leaks out one polite step at a time.

The point of naming them isn't to assign blame. It's to give yourself a way to notice, in the moment, when the user starts slipping out of the room, fast enough to pull them back in. Once you have the names, you can feel it happen. Someone says "users want fewer clicks" and a small alarm goes off, because you know that sentence used to be a person under real pressure, and somewhere between then and now the pressure disappeared.

The counter to a distortion is a receipt. Not more analysis, more concreteness. One real artifact specific enough that it can't be reinterpreted into something comfortable: a thirty-second clip of the user stuck in the tool, narrating what they're trying to finish and what they're afraid will happen if they miss. A direct quote with the stakes intact. A screen recording of the workaround. If your "evidence" can be paraphrased into a generic statement without losing anything, it was never evidence. It was a theme.

For the persona problem, the counter is a small, rotating set of real accounts the team can actually walk through, each tied to a living workflow and a real pain, instead of a stable fictional character who always agrees with you. For the edge-case landfill, the counter is to instrument it: quantify how often it really happens and what it costs, and if you're going to trade it away, write that down as an explicit decision with a date to revisit, rather than pretending it's rare.

None of this requires more meetings or more process. It requires keeping one real thing in the room when the decisions get made. That's harder than it sounds, because the gravity of every organization pulls toward the clean version. The distortion is always the more comfortable path: it's smoother, it's faster, it doesn't force anyone to sit with how messy the actual situation is. Resisting it is a discipline, not a personality trait.

The teams that build things people actually use aren't the ones with the best personas or the cleanest research decks. They're the ones who keep refusing to let the user become an abstraction, who keep dragging the specific, inconvenient, real moment back into the room right when everyone would prefer the tidy summary.

This is one of the failure modes I map in my book, Intent: How to Build Products That Last in the AI Era.