Product development has a seam problem. Designers hand off to engineers. Engineers push back on what’s not buildable. Designers fight for what matters. Something gets lost every time. Neither side is wrong. They’re just standing in different places, working from an incomplete picture.
I’ve spent a decade doing product design. I’ve owned front ends for just as long. I can arrive at a design critique and say, with some precision, which decisions will cost two sprints and which will cost an afternoon. I can sit in engineering standups without needing a translator. I’ve also spent those ten years feeling like an imposter in both rooms.
The imposter syndrome isn’t mysterious. You’re always playing an away game. Compare yourself to a designer who does nothing but design, and they’re deeper in Figma than you. Compare yourself to an engineer who does nothing but engineer, and their GitHub looks more serious than yours. The measuring tools favor specialists. If you’re not one, you always come up short.
The tools miss what happens at the seam.
The handoff is where quality dies in product development. Not always visibly. Usually through accumulation: the interaction a designer simplified because nobody flagged that it mattered, the component an engineer rebuilt three times because the spec assumed something the codebase couldn’t deliver, the feature that ships technically correct and functionally wrong. Everyone did their job. Nobody owned the seam.
Teams compensate in two ways. Process is the default: longer specs, more review cycles. Culture is the optimistic version, where you hire people who communicate across disciplines and trust them to close the gap on their own. Both approaches work partially. Both scale poorly.
The field spent the better part of a decade convinced it had a third answer: design systems.
The promise made sense. If design and engineering worked from the same component library and the same token system, the translation layer would disappear. Engineers would stop guessing at intent. Designers would stop watching engineers ship it wrong.
Design systems do help. Nobody debates button states anymore. Spacing scales settle. Teams put components in Storybook once so engineers stop rebuilding them from scratch. The arguments that used to eat sprints go away.
But a design system is documentation. It tells you what exists. It can’t tell you which component to reach for when you’re three levels deep in an edge case, or why a particular pattern was built the way it was. Those decisions require someone who understands both the intent behind the design and what the component is actually doing in code.
The seam lives in the conversation that happens when the library doesn’t have what you need. A designer reaches for the nearest pattern because it looked close enough in Figma. An engineer implements every spec correctly and still ships something that doesn’t behave the way a user expects. Design tokens don’t help. Neither do Figma variables. Those moments require judgment, and judgment can’t be tokenized.
Worse: design systems gave a lot of organizations a reason to stop looking for people who could exercise that judgment. If the system solves the communication problem, you don’t need communicators.
The rare alternative is finding someone who thinks natively in both directions. Not a designer who can write a bit of CSS, or an engineer who’s read some Nielsen. Someone who can hear a product requirement and feel the tension between what it asks for and what it’ll cost to build. Someone who knows, before the argument starts, which fights are worth having.
The problem doesn’t stop at the door.
Specialists produce legible outputs. A designer ships screens. An engineer ships code. Both leave artifacts in Figma and GitHub that someone can point to and say: I did that.
The work of owning the seam doesn’t leave an artifact. It leaves an absence. The meeting that didn’t spiral because someone reframed the question before it became a fight. The spec that didn’t go to engineering half-formed because someone caught it in review. Nobody files a ticket for the mistake that didn’t happen. It doesn’t show up in the retrospective. It looks like a clean sprint, and clean sprints get attributed to good process or good luck.
The imposter syndrome feeds on this every day. You’re not underperforming. The work just doesn’t register in any system that tracks performance.
This is a structural problem. I spent a long time taking it personally.
Teams measure designers in design artifacts. Teams measure engineers in engineering artifacts. The imposter syndrome, the sense that you don’t fit cleanly anywhere, is a reasonable response to a system that doesn’t have a unit for what you are. There’s no artifact for “I caught the thing that was going to be expensive before the sprint started.” That conversation happened and then it was over and everyone moved on.
Something does accumulate, but a team feels it rather than measures it. They’ve been faster. The seam stopped being a source of friction. None of that gets attributed to a person. It just becomes the new baseline, and the new baseline becomes invisible too.
The only metric that actually captures it is time. Long enough that a team can remember what it felt like before. Long enough that when the seam comes back into focus, because it always does when the person owning it leaves or a new project starts and nobody’s standing at the gap, they can name what was there.
I don’t know a faster way to make it visible. I’ve looked.