The shared-language problem

Every legacy product has the same conversation on a loop. The UI is inconsistent, everyone can see it, and the explanation is always the same: we do not have the engineering bandwidth to fix it. I used to believe that too. I do not anymore.

I spent months inside a long-lived admin platform built on PHP and jQuery. Hundreds of pages, no shared component library, styles from every era of the product sitting next to each other. The team was not lazy and the engineers were not slow. The problem was structural. Every screen was a negotiation between what design intended and what engineering interpreted, and that negotiation happened hundreds of times with no shared reference. Quality did not erode because people stopped caring. It eroded because there was no common foundation to build from.

So I stopped treating it as a capacity problem and started treating it as a language problem.

I audited the whole platform and found something I did not expect. Underneath the visual chaos, the interaction patterns were far more coherent than they looked. The mess was at the surface, in CSS and layout, not in the structure. That meant a shared foundation was possible. I built a component library mapped to our design tokens, documented it, and made it the single source both design and engineering would draw from. Then, working with one developer who believed in it, we connected that library to the live product, so a designer could produce a working screen and an engineer could ship it without rebuilding it from a static file.

The point was never the tooling. The point was that once design and engineering shared a real language, the quality problem mostly dissolved. The same engineers who could not keep up before were now shipping consistent screens quickly, because they were no longer interpreting intent. They were reviewing something that already expressed it.

This is the part I want other designers to take seriously. The gap between what we design and what users actually get is the most expensive gap in our work, and it is almost never closed by better specs or more documentation. It is closed by reducing the distance between design intent and deployed output. Sometimes that means a design system. Sometimes it means learning enough about the stack to co-design the data model. Sometimes it just means sitting next to the person who builds it until you both mean the same thing by the same word.

Designers who can close that gap are going to work differently from designers who cannot. Not because they write production code, but because they understand the system well enough to connect the layers. That shift is already happening. The tools make it faster, but the tools are not the point. The shared language is.

This thinking shows up across my work, most directly in the Gainsight AI generation project.