Meeting people where they work

Part 3 of Building Arbor, a series about my year on Linktree’s design system.

Adopting a design system is work someone has to do.

A token can be named well, documented clearly, and available in the library while an existing design file still uses the old value. The person working in that file has to find the difference and carry the change across. Improving the source doesn’t update every place that depends on it.

That was the problem I wanted the Arbor Figma plugin to address. Designers were already making decisions on the canvas. I could put the system’s help beside that work instead of adding another place they had to visit.

Give the migration a home

Behind the scenes, I’d remapped Arbor’s Figma tokens to canonical values and naming conventions. The next job was making that work useful in the files designers already had.

The plugin could find off-system or outdated token values and move them onto the canonical tokens in a sweep. It connected through a Figma desktop bridge to Arbor’s MCP server. The designer could work from the file that needed changing instead of translating a migration document into a series of manual edits.

The important part was the distance it removed. A naming convention in a source library and the values applied to a design are two different things to inspect. The plugin connected them where someone could act.

I think migration belongs in the design of a change. Otherwise the person proposing the improvement gets the tidy new structure, while everyone using it inherits the cleanup.

The work keeps moving

The same issue came up on the engineering side. Product teams kept shipping while migrations were being prepared and run. New code could arrive using an older convention after an earlier pass had already changed the surrounding code.

Our codemods could be run again. That mattered more than treating migration as a single event with a finished date. The tool had to remain useful while the product moved underneath it.

The Figma plugin addressed the design side of that adoption problem. The lesson I took across both surfaces was to account for existing work and the next change someone would make. A better convention has to be reachable from where people are now.

That includes the cost of getting there.

Writing guidance beside the words

The plugin’s other job was UX writing. I embedded the house writing skill so a designer could select copy and apply the guidance without leaving Figma.

A voice guide may be clear when you read it on its own. Applying it while designing an interaction asks for another kind of attention: finding the relevant guidance, remembering it, and checking the words in context. The plugin brought the help to the selected copy.

That made writing part of the workflow on the canvas. The designer still had the words and the interface in front of them to judge. A tool can apply a voice guide; the person making the screen has to decide whether the result says what the interaction needs.

The standard became easier to use without taking that decision away.

Choose the surface for the problem

A Figma plugin wasn’t the answer to every request. The point was to choose a place where the intervention could help. Designers changing files needed help on the canvas. Engineers changing implementations might need a local warning or a suggestion in a pull request.

The feedback shaped the details. People had their own work to finish, and a tool that required them to take a long detour would have been another demand on their attention. I wanted it to make the shared approach easier to adopt.

Keep the knowledge connected

Putting help in Figma raised a question about what supplied it. Tokens, component specifications, and research each held information the plugin or another tool might need.

Building another interface wouldn’t be enough if it introduced another copy of that knowledge to maintain. The useful pattern was a new way to reach the system, with the sources behind it still connected.

Part 4 looks at that connection: one place to ask, with several kinds of evidence behind the answer.