A decade of tools have been sold on fixing design-to-development handoff, and handoff is still the part everyone complains about. That alone is a clue. If a problem survives ten years of tooling aimed straight at it, the tooling was probably aimed at the wrong thing all along.
Handoff tools show up at the moment the design is finished. The actual friction starts a lot earlier, right when the design is being decided, and it comes from designers and developers looking at completely different evidence.
The two libraries problem
Almost every product team has two reference collections running in parallel and doesn’t realize it.
The designer has one. It lives in Figma, Savee, Pinterest, or just a folder, and it’s organized around visual direction: mood, composition, what a category feels like right now, what’s current.
The developer has one too. It lives in bookmarks, CodePen, GitHub stars, and a screenshots folder, and it’s organized around implementation: how did they actually do that, is this even achievable, what would this cost us.
The two barely overlap, and neither person even knows the other one exists. So when a disagreement comes up, both sides are arguing from evidence the other has literally never seen, and the whole conversation turns into an argument about taste and feasibility in the abstract, which is a conversation that never really ends.
What the arguments are actually about
Three recurring ones, all the same shape underneath once you look closely.
"Can we even do this?" The designer has seen it done somewhere. The developer hasn’t, and has no way to look at what the designer saw beyond a flat image that doesn’t actually answer the question. Hand them a capture that carries the real implementation instead, and this stops being a debate and turns into ten minutes of just reading.
"That’s not what I meant." The developer built exactly what the picture showed. The picture showed one single frame of something whose real value lived in a transition, a hover state, or how it behaved at a smaller width. None of that was ever transmittable through a screenshot. This isn’t carelessness on either side. It’s a bandwidth limit baked into the artifact being passed between them.
"Why does it look different from the reference?" Usually because the reference had values nobody ever wrote down, so the developer had to approximate, and eight small approximations stacked together into something visibly off that nobody can quite point at.
All three of these dissolve once both people are looking at the same capture, and that capture holds more than pixels.
What a shared reference workspace actually has to do
Four requirements, and most tools miss at least two of them.
- One library, not one per discipline. If a designer and a developer each have their own view into the same collection, that’s fine. Two separate collections is the failure mode.
- References that answer both kinds of question. A designer asks what does it feel like. A developer asks what is it actually made of. A flat image only answers the first one, which is exactly why developer participation in shared moodboards has historically been close to zero.
- Annotation living in the same place as the artifact. A comment left in Slack about a reference sitting in Figma is a comment nobody will ever find again. Notes have to live on the thing itself.
- Friction low enough that both sides actually contribute. Developers stop contributing to a shared board the moment contributing means opening up a design tool they don’t normally touch.
The upstream win nobody counts
The obvious benefit of a shared library is fewer disputes at handoff. The bigger benefit is earlier feasibility signal, and it’s usually the one nobody thinks to measure.
When a developer can browse the exact same references during exploration, cost information shows up while the design is still cheap to change. "That layout’s fine, but that particular scroll behavior is a three day build" is worth an enormous amount more said in week one than said in a review meeting.
Teams that get this right report the same kind of change every time: fewer review cycles, shorter ones, and design decisions that show up already scoped. The mechanism isn’t some soft improvement in communication. It’s that both people are reading the exact same evidence at the exact same time.
What not to do
Three common attempts that reliably fail, every time.
- A shared Figma file full of screenshots. Developers don’t open it, and even when they do, a pasted screenshot is just as inert there as it is anywhere else. This is the most-attempted and least-successful version of all of them.
- A Notion database with a reference column. Structure with no actual browsing experience attached to it. Stalls out around forty rows, without fail.
- A Slack channel. Great as an inbox, useless as a library, because search over a channel is really just search over a conversation, and anything that scrolls past never gets seen again.
The pattern across all three is the same: they solve sharing and completely ignore fidelity, so the developer half of the team gets nothing back for participating and just stops.
How to start without a full migration
Don’t try to merge two existing libraries into one. That project never actually finishes.
Start with one current problem instead. Pick something the team is actively deciding right now, spin up one shared collection just for it, and get both a designer and a developer to each add at least three references with a one-line note. Ninety minutes, total. It’s the same three-pass method from our pattern library post, just applied to two people instead of one.
The output is a written decision with actual evidence sitting underneath it. Do that three times and the shared workspace exists, without anyone ever having agreed to some big migration project.
Where Stele fits
Stele is a shared canvas of captures that carry their real DOM and computed CSS, which is exactly what makes the same artifact useful to both people at once. The designer sees the reference. The developer reads the spacing scale, the type ramp, the real colors, the contrast audit, and can generate a first draft implementation straight from it.
Spaces are shared and editable, sticky notes and annotations live right on the canvas next to the thing they’re about, and search runs across everything, including text read out of images.
The requirement it’s really built around is the second one on the list above: a reference that can answer both kinds of question at once. Everything else in a shared workspace is basically table stakes. That one is where these efforts usually die.