The Rosetta Stone of Design Engineering

Before we dive in, you can watch the original talk during Granola's Design Engineering Night #4 that inspired this piece. It’s up on YouTube if you want the live version.

The problem with two rails and one destination

I’ve always imagined design and engineering as two rails on the same track. They run in parallel, supposedly toward the same product, but they rarely sit at the same spot. Design debt on one side, tech debt on the other, shifting priorities somewhere ahead, and the occasional giant “wait what are we building again?” boulder in the middle.

This is usually where collaboration breaks:

• handoff trap: design wanders ahead for weeks, convinced it’s at the finish line, waving mockups at engineering like “hey, just build this.” We all know how this one ends.

• “my Figma is better than production” fork: both sides move, but not together. By the time they meet in the middle, they’re holding two slightly different products. No villain, just desynchronization.

• “nobody knows what’s happening” freeze: no shared direction, no shared momentum. Everyone’s waiting for someone else to define reality.

The track doesn’t care who’s responsible. It only cares that the thing moves forward.

Where the wall appears

Why is it so hard? Because there’s a wall in the middle of the track. A wall made of translation problems: language, intent, ambiguity, assumptions.

That’s where the Rosetta Stone metaphor came from. The real Rosetta Stone didn’t solve languages, it overlapped them. Same meaning, carved three times, so people could decode one through the other. Design engineering is the same: we’re constantly trying to express intent twice — once visually, once in code, without losing the meaning in between.

When the languages don’t match, the wall gets thick. When they overlap, the wall becomes translucent. And when the overlap is high enough… the wall disappears. It becomes glass. I think that overlap, that shared percentage of language, is the real definition of velocity.

What design engineers actually do

Design engineering isn’t about merging roles. It’s not about “one person doing everything.” It’s about live translation. A design engineer moves on the track while continuously translating both ways:

• when designing, thinking about constraints and implementation;

• when coding, thinking about intent and aesthetics;

• when adjusting details, understanding how the system breathes and reacts.

It’s foresight. It’s catching translation errors before they happen. It’s noticing when we’re about to over-engineer the design or over-design the implementation.

The job isn’t to switch sides. It’s to stay on the track and keep both rails aligned. It’s not about roles, it’s about function.

The track changes every time

No project has the same terrain. Some features are straightforward highways. Some are chaotic mountain roads with loose gravel and a “we should refactor this someday” cliff on the right. The Rosetta Stone isn’t fixed either, it evolves.

Its clarity depends on how much shared language exists between the two sides: variables, naming, mental models, motion vocabulary, code structure, constraints, data, taste, intuition.

The more overlap, the more transparent the stone. The more transparent the stone, the easier the translation. The easier the translation, the faster the train — or the boat, or the rocket, whatever you choose.

This is why tools matter.

Building tools that sit on the Rosetta Stone

Some demos shown at 6:40, but feel free to watch these later.

At Linear, we consistently polishing the stone to keep it translucent, building tools that live right at this intersection:

• internal tweak systems that let designers fine-tune behavior directly in the app

• internal Figma plugins (icons SVG to TS components, color variables synced between design editor and codebase, data population)

• PRs from designers, visual and UX adjustments from engineers

• unified aesthetic across the team

These aren’t “utilities”, they’re translation devices. They’re bilingual dictionaries disguised as features. This isn’t just comfort, it’s the practice of keeping the stone clear.

And on my personal projects — especially the upcoming version of my personal website, this mindset shows up everywhere: turning every meaningful decision into a tweak-able dimension, testing ideas in code first, embracing the natural dynamism of the medium, and treating prototypes like sandboxes rather than artifacts.

When the Rosetta Stone becomes invisible

The ideal isn’t to erase the difference between design and engineering. Each side has its depth, taste, and craft. The goal is simpler: maintain a shared language of making. When that language is strong enough, the wall between the two sides stops looking like a wall. It becomes glass. You can see through it, speak through it, and move faster because of it.

That’s not just convenience — that’s translation in action. The artifacts fluent designers and engineers create together become a bilingual dictionary between design and code. Not to erase the gap, but to keep the shared language of making alive.