Ten years of tools have been sold on fixing design-to-development handoff, and handoff is still the part everyone complains about. That persistence is a clue: if a problem survives a decade of tooling aimed directly at it, the tooling was probably aimed at the wrong thing.
Handoff tools address the moment the design is finished. The friction starts much earlier, at the moment the design is being decided, and it comes from designers and developers looking at different evidence.
The two libraries problem
Almost every product team has two reference collections and does not know it.
The designer has one. It lives in Figma, Savee, Pinterest, or a folder, and it is organized around visual direction: mood, composition, what a category feels like, what is current.
The developer has one. It lives in bookmarks, CodePen, GitHub stars, and a screenshots folder, and it is organized around implementation: how did they do that, is this achievable, what does this cost.
They overlap almost not at all, and neither person knows the other has one. So when a disagreement happens, both parties are arguing from evidence the other has never seen, and the conversation becomes about taste and feasibility in the abstract, which is a conversation with no ending.
What the arguments are actually about
Three recurring ones, all the same shape underneath.
"Can we do this?" The designer has seen it done. The developer has not, and has no way to look at what the designer saw beyond a flat image that does not answer the question. With a capture that carries the real implementation, this stops being a debate and becomes ten minutes of reading.
"That is not what I meant." The developer built what the picture showed. The picture showed one frame of something whose value was in a transition, a hover state, or how it behaved at a smaller width. None of that was transmittable. This is not carelessness on either side; it is a bandwidth limit in the artifact being passed.
"Why is it different from the reference?" Usually because the reference had values nobody wrote down, so the developer approximated, and eight approximations compound into something visibly off that nobody can point at precisely.
All three dissolve when both people are looking at the same capture and that capture contains more than pixels.
What a shared reference workspace has to do
Four requirements, and most tools miss at least two.
- One library, not one per discipline. If a designer and a developer each have their own view of the same collection, that is fine. Two collections is the failure.
- References that answer both kinds of question. A designer asks what does it feel like; a developer asks what is it made of. A flat image answers only the first, which is why developer participation in shared moodboards is historically near zero.
- Annotation in the same place as the artifact. A comment in Slack about a reference in Figma is a comment nobody will find again. Notes must live on the thing.
- Low enough friction that both sides actually contribute. Developers stop contributing to shared boards the moment contributing means opening a design tool.
The upstream win nobody counts
The obvious benefit of a shared library is fewer handoff disputes. The larger benefit is earlier feasibility signal.
When a developer can browse the same references during exploration, cost information arrives while the design is still cheap to change. "That layout is fine but that particular scroll behaviour is three days" is worth enormously more said in week one than said in review.
Teams that get this right report the same shape of change: fewer, shorter review cycles, and design decisions that arrive already scoped. The mechanism is not better communication in the soft sense. It is that both parties are reading the same evidence at the same time.
What not to do
Three common attempts that reliably fail.
- A shared Figma file of screenshots. Developers do not open it, and even if they do, a pasted screenshot is as inert there as anywhere else. This is the most-attempted and least-successful version.
- A Notion database with a reference column. Structure without a browsing experience. Stalls around forty rows, every time.
- A Slack channel. Excellent as an inbox, useless as a library, because search over a channel is search over a conversation and nothing that scrolls past is ever seen again.
The pattern in all three: they solve sharing and ignore fidelity, so the developer half of the team gets nothing out of participating and stops.
How to start without a migration
Do not attempt to merge two existing libraries. That project does not finish.
Start with one current problem. Pick something the team is actively deciding, make one shared collection for it, and require both a designer and a developer to add at least three references with a one-line note. Ninety minutes total, and it is the three-pass method from the pattern library post applied to two people instead of one.
The output is a written decision with evidence under it. Do that three times and the shared workspace exists, without anyone having agreed to a migration.
Where Stele fits
Stele is a shared canvas of captures that carry their real DOM and computed CSS, which is what makes the same artifact useful to both people. The designer sees the reference. The developer reads the spacing scale, the type ramp, the real colours, the contrast audit, and can generate a first-draft implementation from it.
Spaces are shared and editable, sticky notes and annotations live on the canvas beside the thing they are about, and search runs across everything including text read out of images.
The requirement it is really built around is the second one in the list above: a reference that answers both kinds of question. Everything else in a shared workspace is table stakes; that one is where these efforts usually die.