The Translation Tax: Why Design Engineering Carries Its Weight in Gold

The translation tax, itemised

Let me actually itemise it, because the cost hides in plurals and small increments.

A designer finishes a flow in Figma. At that moment it is a set of carefully composed static frames: real design work, real craft, and still a lossy format for software. The frames are annotated, shared, and interpreted, and interpretation is where the intent starts leaking. The engineer, acting in complete good faith, builds what the frames appear to say. The spacing drifts because the mock used a value that doesn't exist in the codebase. The empty state doesn't exist because the mock never showed one. The transition is skipped because a static frame cannot describe easing, and the loading behaviour is invented on the spot because nobody specified it, and none of this is anyone's fault. Static design is simply a lossy format for describing interactive software. Compressing a living, stateful system into still frames and then asking someone else to decompress it back into a system is a game of telephone played with your product quality.

Then come the correction cycles. QA against mocks. Design review of the build. Tickets, politely worded, each one a small translation dispute, each one a context switch for an engineer who has already moved on. Multiply by every screen, every sprint, every team. That's the tax. Most companies have simply decided it's weather: unavoidable, unbudgeted, eternal. It isn't. It's a structural gap between two crafts, and every unpaid gap is where UX intent thins out before a user ever sees it. Structural gaps can be bridged by people built for bridging.

I've lived in both crafts

My case for design engineering is not theoretical, so let me put my history on the table.

I began as an engineer. Real engineering, production code, the whole apprenticeship of caring about state, edge cases, and what happens when the API is slow. Then I crossed over into interaction design, which at the time felt like emigrating, and spent years learning the other country's language: hierarchy, motion, affordance, the psychology of a moment of friction. What I found at Scan.com, working as an interaction designer who had never stopped being able to code, was that the two passports together did something neither did alone. When a new idea surfaced, I didn't book a meeting to describe it. I built it. A working prototype, real components, real interactions, in front of stakeholders while the idea was still warm.

And the effect on sign-off was the thing that converted me from someone who happened to have both skills into someone with a thesis. When you put a static mock in front of a decision-maker, you are asking them to sign off on a prediction, and people hedge on predictions. When you put a working prototype in their hands, something they can click, break, and feel the timing of, you are asking them to sign off on an experience. They decide faster. They decide better, because their yes means yes to the actual thing. That is not a process trick. That is UX applied to the decision itself. Giving someone a real experience to approve, rather than a static representation of one, is itself a piece of product design. Sign-off is an interface. Most companies have never designed it.

The prototype is the spec

Here's what my toolkit has looked like in practice, and why each piece earns its place.

React is the trunk, because React is what the product is actually made of, and prototyping in your production paradigm means your prototype speaks the same language as your codebase: components, props, state. TypeScript, which I've used inside Framer's code components to build prototypes with real logic and real data shapes, does something subtle and wonderful to design work: it forces the design to confront its own edge cases at the moment of authorship. The type system asks the questions a mock lets you skip. What if this list is empty? What if this name is 40 characters? What is this value when the request fails? Answering those in the prototype means nobody downstream has to invent the answers under deadline. Tailwind has been my speed layer, spacing, colour, and type mapped to a constrained scale, which keeps even throwaway prototypes speaking in system values instead of magic numbers. And GitHub is where design work stops being an artefact and becomes a contribution: branches, pull requests, review comments on real code, design intent version-controlled next to the thing it describes.

Working in these materials collapses the lossy compression I described earlier. The prototype doesn't describe the behaviour; it has the behaviour. Easing curves, focus states, keyboard flows, loading sequences: all present, all inspectable, all real. The spec and the demonstration become the same object. An engineer picking it up isn't left to reconstruct still frames into software; they're reading working intent, often lifting logic and structure directly. I've watched estimation conversations with strong engineering teams change in kind, not just in speed, because the question shifts from "what do you think this frame means" to "how do we productionise what's in front of us." That is what good engineers deserve: material they can build from, not guess from.

There's an unglamorous benefit here that I'd put near the top of the whole stack: token validation. Design systems live and die on whether the values in the design tool actually correspond to the values in the code. A design engineer is bilingual enough to check, and positioned to care. At Scan.com I could trace a token from the design decision to the CSS custom property and catch the drift before it shipped, the spacing scale that had quietly forked, the colour that existed in Figma and nowhere else. Every one of those catches is a future inconsistency that no user will ever see, which is exactly the point. Whole categories of visual bugs stop being QA's problem because they stop existing.

What it does when you work with great engineers

I want to talk about the human side, because it's the part that compounds.

I want to be careful here, because the engineers I work with are excellent, and the old industry story of tossing work over a wall does not describe them. The friction I care about is not people. It is format. Even on high-functioning teams with sharp engineers and careful designers, static deliverables still ask brilliant people to reconstruct intent from stills. That is not a failure of talent. It is a lossy medium meeting a living system.

Having been an engineer changes how I show up in that partnership. When I bring work to engineers, it arrives already negotiated with reality: I know roughly what this costs, I've considered the rendering implications, and when I don't know, I ask in their language. Feasibility becomes an early design material instead of a late surprise. And I'll be honest that this is one of the deepest joys of the role: working beside engineers who care as much about craft as I do, who engage differently when a designer reviews PRs, ships, and brings prototypes they can actually read. You stop being the person who makes requests and start being the person who shares the load. Some of my best design decisions have come from engineers pushing back in technical terms I could engage with. Some of their best technical decisions have come from being pulled into design intent early enough to shape it. That is not handing work over. That is building together.

And design engineers make everyone around them faster in a very specific way: they absorb ambiguity before it lands on an engineering teammate as an interruption. The half-specified interaction, the "we'll figure out the empty state later," the animation nobody owns: these fall to the person who can resolve them in either language without a meeting. On most teams, ambiguity is resolved by whoever hits it last, under the worst possible conditions: mid-sprint, mid-build, with the designer unavailable and the deadline watching. A design engineer moves that resolution upstream, to the one person for whom it isn't an interruption but the actual job, which is one of the kindest things you can do for an engineering team you respect.

Design in production is where the craft actually lives

The last angle is the one I care about most, and it is the design argument, not the engineering one. There is a version of design that ends at the mock, and there is a version that ends when a real user touches a real interface, and the distance between those two endings is where most product quality is won or lost. Professional UX does not stop at approval. It stops when the experience is true in the product.

The last ten percent of any interface, the timing of a transition, the exact behaviour of focus, what happens in the 400 milliseconds while data loads, is essentially undesignable from outside the codebase. It can only be felt in the build, tuned in the build, and defended in the build. That ten percent is not polish. It is the craft users actually experience. Teams without design representation in production simply lose it, every sprint, forever, and the product develops that faint uncanny cheapness users can feel but never name. A design engineer is the role that stands in production and refuses to let professional design die in the last mile.

The business case follows directly and I'll state it plainly: fewer translation cycles means faster delivery; decisions made against working software mean fewer reversals; tokens validated at the source mean consistency without policing; and craft applied where users actually are means quality that survives contact with reality. That is why the role carries its weight in gold. Not because it makes the backlog tidier, though it does. Because it protects the thing companies claim to care about most and then systematically dilute: the designed experience. None of this requires heroics. It requires one kind of practitioner positioned at the seam.

I've noticed the industry arriving at the same conclusion; the teams whose craft gets most admired keep turning out to be full of people with this exact hybrid shape, and "design engineer" has gone from a curiosity on a job spec to a named, sought-after role. That doesn't surprise me at all. What surprises me is that it took this long, given the size of the tax it exists to delete.

I said at the start that the seam between engineering and design turned out to be a place you can live. I'd go further now: it's where serious design and UX actually keep their promises. I've been living there all along, since before the role had a name, one prototype and one validated token and one pre-negotiated PR at a time. The industry finally built a job title around the way I work. It would be rude not to answer.