Structure, not house style
Part 1 of Building Arbor, a series about my year on Linktree’s design system.
A design system has to work wherever its decisions get made.
A designer choosing a token, an engineer reviewing a change, and an agent writing a component need different kinds of help. They may be working from the same system, but they won’t all stop to read the same document. The work is to understand what each person needs and build a way for the system to reach them there.
That is how I approached Arbor, Linktree’s design system. I led its engineering across product surfaces built by different teams, at different times, with different conventions. The components mattered. So did the research behind them, the Figma files using them, and the changes people needed to make when the system moved on.
Structure, not house style
The most useful distinction I took from the work was between shared structure and visual expression. A system needs a dependable way to name decisions, deliver them, and carry changes to the people who use them. That gives teams room to make different things without rebuilding the foundation each time.
A token’s name is part of that structure. It tells someone what the value is for and what they can expect to change with it. A migration tool is another part: it carries a decision into work that already exists. Documentation explains the choice, including when it doesn’t apply.
These jobs are connected. If a naming change is clear in the library but difficult to adopt in a product, the work isn’t finished. If a component exists but nobody can tell when to use it, adding another component won’t answer the question.
The useful unit is the decision and everything needed to act on it.
Start with the people using it
A lot of what I shipped began with someone on the team describing how they wanted to work, or something that felt broken to them. I shaped the system around that feedback. The details mattered as much as the plan, because those were the details someone else had to live with while shipping their own work.
That called on the product-design work I’d done before Arbor: listening, researching, finding the issue underneath a request, and deciding what to try. Sometimes the answer belonged in Figma. Sometimes it was a convention in the codebase or a check in CI. Choosing the right place was part of designing the solution.
Everyone is trying to get their piece of work shipped. A shared system should help them do that without requiring them to learn how the whole organization fits together first.
Five places to reach
The work took several forms, each serving a different decision.
A designer on the Figma canvas needed current tokens and useful writing guidance while the design was still taking shape. A plugin could put both within reach of the selected work.
An engineer in a pull request needed to know how an implementation should use Arbor. A reviewer could point to the relevant line and suggest the change, with a reason attached.
Someone reading documentation needed an answer connected to the system it described. The docs and tools could share the sources behind that answer.
An agent writing UI needed guidance it could retrieve and apply. Making that guidance available raised a further question: whether following it actually improved the output.
A reviewer approving a release needed to understand the effect of a change. Commit conventions, versioning, migration tools, and written context could make that decision easier to examine.
The tools were different because the work was different. Their purpose was shared: make the system’s knowledge available where it could change a decision.
The work between the tools
This is the range of work I want a design system to support. Research informs a recommendation. Design gives it a usable form. Engineering puts it into the workflow and keeps it working as the product changes. Feedback tells us whether it helped.
Moving between those activities was the job. I could research a question, work through it with designers and engineers, and build the intervention that fit. The surface might change; the responsibility for carrying the idea into production stayed with me.
The next part starts with a question from a team that needed an answer, including when Arbor didn’t yet have a component to offer.