Why years of better documentation, tighter specs, and heavier design systems didn’t fix design–development friction—and why the real solution starts somewhere else entirely.
For a long time, we have comforted ourselves with the idea that the friction between design and development is a communication problem.
If only the handoff were cleaner. If only the specs were more precise. If only the documentation were more complete.
This story flatters everyone involved. It suggests that the problem is one of execution rather than imagination, of diligence rather than structure. It implies that if we just worked a little harder—or documented a little better—the tension would disappear.
It hasn’t.
After years of increasingly sophisticated design systems, ever-thicker documentation, and entire teams devoted to “alignment,” the friction remains. It has simply become more formal.
The trouble, it turns out, was never the handoff.
The handoff was the symptom.
Skim takeaway: We asked how to hand work off better instead of asking why we were handing it off at all.
Imagine a new shelf is being designed at IKEA.
Not assembled.
Not shipped.
Designed.
Two employees are assigned to the project.
They are both experienced. They both care. They are both working on the same product.
The designer is responsible for the physical form of the shelf—how it looks, how it feels in a space, how a customer understands it at a glance. They sketch, prototype, refine proportions. They decide how thick the panels should appear, where the brackets should sit, how the shelf communicates stability and balance.
The developer—in this case, manufacturing and structural engineering—is responsible for making sure that shelf can actually exist. They define tolerances, materials, load limits, packaging constraints, and assembly logic. They ensure the shelf can be manufactured at scale, shipped flat, assembled without failure, and returned without disaster.
They are not collaborating in real time.
They are working in parallel.
The designer finalizes the product.
The shelf looks right. It feels right. The proportions are elegant. The form communicates exactly what it’s meant to be. From a customer’s perspective, it’s obvious how this shelf should live in a room.
The designer produces a pristine instruction booklet—clear diagrams, perfect hierarchy, confident visuals. Anyone following it would understand what the shelf is supposed to be.
From their point of view, the product is complete.
Separately, the developer finalizes the implementation.
The shelf meets all structural requirements. The parts can be manufactured reliably. The tolerances are safe. The load-bearing capacity is correct. The packaging works. Assembly is efficient. Nothing fails stress testing.
From their point of view, the product is complete.
Only later—far too late—are the two brought together through specifications, documentation, and handoff rituals.
And that’s when the product starts to come apart—not because either side did poor work, but because they were never working on the same surface to begin with.
The visual design assumes material thicknesses that exceed manufacturing tolerances.
The structural plan removes panels the visual design relies on for balance.
The assembly order required for stability contradicts the order shown in the instructions.
The shelf technically works—but no longer matches what’s pictured.
The instructions are clear—but no longer accurate.
No one made a mistake.
Both did their jobs correctly.
Each produced a perfect output for their responsibility.
What failed was the space where the shelf itself should have been shaped together.
There was no shared surface where form, structure, constraints, and intent could be explored simultaneously—while decisions were still flexible.
Instead of co-designing one product, they designed around each other and tried to merge the results afterward.
This is the modern handoff.
Skim takeaway: Handoffs fail when teams design one product from opposite abstractions—and only discover the contradictions once it’s too late to resolve them cleanly.
This is not an IKEA problem. It’s a design–development problem.
Designers and developers rarely work on the same thing. They work on adjacent representations of it.
The designer’s world is one of surfaces frozen into view: frames, spacing, proportions, visual hierarchy. Even when systems and constraints are discussed, they are expressed through images—carefully arranged snapshots of intent.
The developer’s world is temporal and conditional. Interfaces unfold over time. Content changes. State mutates. Layout responds to context.
Both groups are describing the same product, but in different languages and at different moments in its life.
One describes how it should appear.
The other describes how it must behave.
Design systems were meant to reconcile these views. Instead, they often codified the divide.
A handoff presumes separation. One party finishes; another begins. The bridge between them is documentation.
But translation is an expensive activity.
Every translation introduces interpretation. Every interpretation introduces risk. When intent must be inferred rather than shared, collaboration turns into negotiation.
Design systems attempted to solve this by standardizing outputs: tokens for color and spacing, components for reuse, variants for flexibility.
These artifacts are tidy, reassuring—and frequently misleading.
A spacing token that reads 16px tells us nothing about when that spacing should grow, collapse,
or yield to content. A variant named “compact” doesn’t explain what happens when compactness collides with
accessibility, localization, or unpredictable data.
To compensate, systems grow. Variants multiply. Documentation expands. Governance emerges.
We didn’t eliminate friction.
We professionalized it.
Skim takeaway: We built complex systems to communicate simple intent.
When these failures surface, our instinct is to add more process.
More annotations. More variants. More rules explaining what the design really meant.
But this only reinforces the underlying separation. Designers continue to work in tools optimized for exploration. Developers continue to work in systems optimized for correctness. Alignment is deferred until change becomes expensive.
The real issue is not a lack of shared vocabulary.
It’s the absence of a shared working surface.
What’s missing isn’t more documentation or better collaboration rituals—it’s a place where intent can be shaped, tested, and challenged by everyone at once.
A shared working surface is not another bridge between tools. It’s not a better export format or a more faithful sync.
It’s a place where the product itself exists while it’s still being defined.
Imagine an environment closer to Storybook—but genuinely collaborative.
Designers explore real components, not approximations. Developers define logic, props, and constraints in the open. Layouts respond to real content. Breakpoints are conditions, not illustrations.
In this space, decisions about composition, responsiveness, and behavior are made together—not reconciled later.
Intent is not implied. It is declared.
Skim takeaway: Collaboration happens in shared reality, not across artifacts.
Artificial intelligence accelerates this tension.
AI is exceptional at translation. It can turn designs into code and code into designs with remarkable fluency.
What it cannot do is intuit intent that was never modeled.
AI is literal. It enforces whatever system it’s given. If that system is built on static snapshots and implicit assumptions, AI will reproduce those shortcomings at scale.
Paradoxically, this makes the need for shared intent more urgent, not less.
You can’t prompt an AI with ambiguity and expect coherence. You must give it rules, priorities, and relationships.
The future of collaboration is not heavier design systems or more elaborate handoffs.
It is fewer handoffs altogether.
This doesn’t mean collapsing roles or eliminating expertise. It means reducing the number of moments where intent must be translated instead of shared.
When intent becomes explicit:
The handoff disappears—not because collaboration becomes perfect, but because it’s no longer necessary.
For years, we treated the friction between design and development as a process problem.
It wasn’t.
It was a modeling problem.
We built tools that encouraged isolation and then wondered why alignment was hard. We mistook translation for collaboration and documentation for understanding.
A shared working surface doesn’t promise harmony.
It promises honesty—about what we know, what we assume, and what we’re willing to change.
When intent lives in one place, collaboration stops being a bridge.
It becomes a space.