Naming, taxonomy & IA for the Birch Design System

Discoverability was zero. That wasn't a documentation problem. It was a language problem

If you don't know the name of a component, you can't find it. If you can't find it, you build your own. If everyone builds their own, you no longer have a design system. You have a collection of similar-looking things that nobody trusts.

That's where Birch was.

User interview synthesis, FigJam

Two groups, two sources of truth, no reliable way to reconcile them

The users of the Birch system were ZipHQ designers and engineers. For engineers, search was text-based and useless without already knowing the component name — so they built their own. For designers, the documentation didn't reflect what components actually looked like in production. New team members had no clear path into the system.

The problem wasn't missing documentation. It was that the language holding the system together had never been defined.

A name is not cosmetic

The component audit didn't just surface what existed. It surfaced what the existing names implied — and where the implications were wrong.

Dropdown was the name of a component that behaved like a menu: an overlay triggered by an action. Renaming it Menu wasn't a stylistic preference. It was a correction. The old name described an animation. The new name described a behavior. Page Header became Page Layout for the same reason — the component defined structure, not a position on screen. Dashboard and Email moved out of the component library entirely, into Patterns, because they were compositions of components, not components themselves.

Each decision followed the same logic: a component's name should carry its intent. When it doesn't, people either misuse it or avoid it. Both outcomes produce drift.

Component audit output, Birch Design System

The audit as a governance act

Research revealed a consistent frustration across designers and engineers: you had to already know what you were looking for to find anything. I ran a card sort to make the implicit explicit — to surface where mental models agreed, where they diverged, and where ambiguous components like Tag, Pill, and Link were being placed differently depending on how you understood their behavior.

The final information architecture resolved those ambiguities with explicit rationale. Tag belongs in Feedback as a status indicator. Pill belongs in Actions as an interactive filter element. Scrim isn't a standalone component — it lives inside Modal documentation. These weren't arbitrary groupings. They were documented arguments. Not documentation decisions. Classification decisions. The kind that determines whether a system stays coherent as it scales.

Card sort analysis, Birch Design System

One place, one voice

Before building anything, I reviewed how mature design systems handle documentation — Cedar, Adobe Spectrum, Base Web. What made each trustworthy was the same: clear principles, consistent structure, and a rationale behind decisions. Not just specs. That standard informed what the reference site needed to be.

I evaluated Storybook, Zeroheight, and Notion against requirements that had emerged directly from the research. Zeroheight was the only platform that scored yes on Figma integration, ease of editing, and structured categorization — the three criteria that came up most consistently.

The final information architecture was flat-first, with nested structure for component families and Patterns grouped separately. It was built to make the system scannable before someone knew exactly what they were looking for. The discoverability problem that surfaced in every interview was built into the structure of the solution.

Tool comparison matrix, Birch Design System

A system that can explain itself

The audit covered fifty components — renames, reclassifications, items moved from the library into Patterns. Every decision was documented with an explicit rationale, not just a new label.

The governance model defined ownership, a clear path from the tool of origin to the reference documentation, and a content template that enforced consistency regardless of author. It was designed so that language decisions would hold as the system grew.

Documentation workflow, Birch Design System

Before this work, component knowledge was scattered across Storybook, Figma, and designers' working memory. Engineers were building duplicate components because they didn't know they already existed. The reference site consolidated that into a single destination — one that designers and engineers can navigate without asking anyone for help.

By the end of the engagement, components were findable in ways they hadn't been before. Not because more documentation existed. Because the language holding them together finally made sense.