Evidence you can argue with

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

A useful research answer makes a decision easier to examine.

At Linktree, teams asked us how to approach interactions, components, and accessibility. I wanted our answers to draw on work beyond our own library. Other systems had already encountered many of the same problems, and comparing their choices could help us ask better questions about ours.

That didn’t remove judgment from the work. It gave us something more specific to judge.

It started with Slack

Teams would ask how to build something, and I wanted the answer to hold even when it wasn’t “use Arbor.” If we didn’t have a component for the task, the person asking still needed an accessible way forward. Sending them away with a gap in our catalog wasn’t much help.

I built a design-system research capability that used AI to investigate specific questions across mature systems. We could compare approaches to form validation, elevation, or token structure and bring the findings back to our own decisions.

The starting point was a question we could answer. “What do good design systems do?” is too broad to guide an implementation. A question about how a field connects its label, validation, and error message gives the research something to look for and the team something to discuss.

A focused question made the work useful.

An answer you can question

The output brought several systems into a structured comparison: where their approaches agreed, where they differed, how Arbor compared, and what we might change.

The recommendation still belonged in the discussion. Several systems can converge on a convention for reasons that don’t apply to the product in front of you. A comparison helps reveal those reasons; counting agreement alone doesn’t establish that a choice is right.

That is what I mean by evidence over taste. An experienced opinion can start the investigation. The evidence makes its reasoning available to someone who doesn’t share that person’s experience or authority.

A useful table gives a team places to disagree. We can question the systems included, the behavior being compared, or whether the recommendation fits our constraints. That is a better conversation than trying to decide whose intuition should win.

Similar controls, different jobs

Tabs and Segmented Control were one place the researcher earned its keep. We needed to understand what selecting an option would do: navigate to a destination, reveal a related panel, or change the current view.

Those questions don’t map neatly to component names. The WAI tabs pattern switches between panels within a page. Its guidance also accounts for content that takes time to load, recommending manual activation when automatic activation would slow keyboard navigation. Whether the content is already loaded doesn’t settle which control to use.

That helped us understand what designers were asking for. Often, they wanted the active segment to animate across the row. They were describing how the selection should look and feel. That motion didn’t determine whether the control needed to navigate somewhere or change the view in place.

We could keep the intended experience and choose the implementation that suited the content and navigation. The behavior needed to be clear first. Then we could give it the visual treatment designers intended.

The research gave us a way to discuss behavior and appearance separately without losing either. It turned a choice between two component names into a clearer design and engineering decision.

The Field and forms work needed a broader comparison. Labels, validation, error messaging, and the states of an input all have to agree. Looking at those APIs together helped us design a coherent Field system. A collection of individually reasonable inputs wouldn’t have settled how they should work as a group.

The research helped connect the decisions.

A finding needs somewhere to go

Accessibility was often the reason to investigate. A question about whether a component was accessible could lead us to compare the ways other systems supported the interaction, then inspect where our own implementation differed.

The accessible-name audit led to corrections, checks against regression, and warnings during development. That is the path I want a finding to have: a change in the implementation and a way to catch the problem next time.

Research also changed our tooling plans. Auditing Arbor against other systems helped me identify a missing step in our workflow: giving engineers a specific design-system correction in the pull request itself. That finding became the reviewer discussed in Part 5.

This mattered because the research could question how the system was delivered as well as what components it contained. A missing capability might belong in a workflow, not in the component library.

Research is part of the service

I wanted the design-systems team to be a place people could bring a problem before they knew which component, pattern, or tool would solve it. Research made that more practical. We could investigate beyond the boundaries of our catalog and bring back a reasoned answer.

That still asks something of the team. Someone has to shape the question, examine the comparison, and decide what to do with it. AI made the investigation easier to carry out; it didn’t make those responsibilities disappear.

The next problem was delivery. A good answer helps little if someone has to leave their work, find it, and translate it into a change. Part 3 follows that answer onto the Figma canvas.