Building a Design System That Survives Contact With Developers

Most design systems look great in Figma and fall apart the moment a developer has to actually build from them. Not because the components are wrong. Because nobody agreed on what to call anything.

Here’s what that problem actually looks like, and how we fixed it on a real project.

The setup

Wick App is an AI learning platform. The design team was in the US. The dev team was in Egypt. Depending on the time of year, that’s a 7 to 10 hour gap. No real overlap in working hours. Every handoff was async, every question sat unanswered for most of a day.

There was no atomic design system in place yet. Screens were getting rebuilt slightly differently every time, because there was nothing forcing consistency, just a rough Figma file and good intentions.

Across a normal timezone gap, you patch that with a quick Slack message. Across a 7 to 10 hour gap, you can’t. By the time someone reads your question, it’s tomorrow.

The fix wasn’t a component library. It was a shared vocabulary.

We built an atomic design system from scratch. Atoms up to full components, properly tokenized. That part is standard, most design systems get at least this far.

The part that actually mattered was smaller and less visible: the naming convention and branching strategy in Figma mirrored the naming convention and branching strategy in the codebase.

Same task number, showing up in both places, always. If a component was tracked as issue #4118 in GitHub, the matching Figma branch was named #4118 too. No translation layer. No “which screen were you talking about again.”

It sounds almost too simple to matter. It’s why development velocity went up 30% once the system shipped.

Why this works when nothing else does across a real timezone gap

When you can’t rely on live conversation to resolve ambiguity, you have to remove the ambiguity before it happens. A shared reference number does that. A developer picking up a task at 9am their time doesn’t need to wait for a designer to wake up and clarify which button they meant. They open the matching branch. It’s already unambiguous.

This is the actual value of a design system, and it’s not the one most teams optimize for. The visual consistency is nice. The real payoff is that two people, working async, on opposite sides of the planet, stop having to guess what the other one meant.

The result

Two months to rebuild the UI and roll the system out fully. Once it shipped:

• 30% increase in development velocity

• 90%+ consistency across the live product

Not because the components got prettier. Because the number of decisions a developer had to guess at, alone, without context, dropped close to zero.

The takeaway, if you’re building one of these

A design system’s job isn’t to make your product look more polished. That’s a side effect. Its actual job is to remove the guessing between the people who design something and the people who build it.

If your design system doesn’t have an answer for “how does a developer know exactly which component this is, without asking,” it’s not finished yet. No amount of visual polish fixes that gap.

This is the kind of problem I work on for B2B and AI startups: 0-to-1 product and design systems built to actually survive contact with a real engineering team, not just look good in a deck. If you’re facing something similar, get in touch.