A Design System That Researches Itself

Part 2 of Building Arbor. A series about my design-system work on Arbor at Linktree.

Most design systems answer “should we build it this way?” with taste and seniority. Someone experienced has an opinion; the opinion wins, and the opinion becomes a token. That works until the system gets big enough that nobody can hold it all in their head. Then taste starts to quietly contradict itself across surfaces.

Evidence over taste is how I wanted us to decide, and making that literal became my job.

It started with Slack

Teams would ask us how to approach something, and I wanted our answers to be more than accurate. I wanted them to be high-quality, grounded in how the best systems in the world actually solve the problem. And crucially, I wanted that to hold even when the answer wasn’t “use Arbor.” If someone was building something we didn’t have a component for, they still deserved the best, most accessible way to approach it.

Being the team that gives that answer — every time, with receipts — is worth more than any single component you ship.

The researcher

So I built a design-system-researcher capability: a way to point AI at the field’s actual frontier and ask a specific, answerable question. When we were about to decide on elevation, form validation, or how tokens should tier, we could ask: what do the systems that have already solved this at scale actually do? And get back a structured synthesis rather than a vibe. Here are several mature systems. Here’s where they converge. Here’s exactly where we’re aligned, and here’s the one place we’ve drifted, with a recommendation attached.

The output wasn’t an opinion. It was a table you could argue with:

• “Five of six systems treat dark mode as a semantic-token swap, never a primitive inversion. We do too, so we’re aligned.”
• Or the more valuable kind: “Every surveyed system enforces an accessible name on icon-only buttons — and we’re missing them in hundreds of places.”

That second kind is the whole point. It turns “someone will notice this eventually” into “here’s the gap, the count, and the fix.” It made the design system legible to itself.

Two places it earned its keep

Tabs vs. Segmented Control. Designers and engineers kept getting these two confused: when to reach for which, and how each actually behaves. That’s not a question you answer well from memory; you answer it by looking at how a dozen mature systems draw the line. The researcher let us settle it with evidence and write the distinction down once, instead of relitigating it in every review.

The whole Field/forms system. Building accessible form inputs (labels, validation, error messaging, the states that have to agree with each other) is genuinely hard to get right, and it’s exactly the kind of thing where you don’t want to invent your own answer. Consulting multiple design systems’ form APIs side by side let us design a coherent Field system instead of an improvised one.

Accessibility as the reason to investigate

There’s a thread running through all of it: accessibility was usually the reason to go investigate. “Is this accessible?” would open into “what’s the most accessible way anyone has solved this?” That question, asked seriously, is how you make sure you’re not quietly leaving some of your users out of the experience. The research skill made asking it cheap.

Which raised the obvious next problem: an answer only matters if it reaches the person at the moment they need it. That’s the next post.