What comes next

You have a working component library: a three-tier token system, eight themes, layout primitives, typography, forms, overlays, navigation, charts, a drag-and-drop board, Storybook documentation, and a test suite. It builds, it publishes, and someone can install it.

That is the end of the guide and roughly the beginning of the work. This chapter covers what usually comes next.

Where the gaps are

The most useful thing you can do at this point is stop adding components and go find out what is missing.

The example pages from chapter 10 are the instrument. Build a real page for a domain you have not covered, and record every time you reach for a raw element, write a one-off style rule, or work around a component’s API. That list is your backlog, ordered by something better than intuition.

Done honestly across four domains, the same gaps show up repeatedly.

A data table. This is consistently the largest one, and it is not close. Almost every application domain needs sortable columns, aligned cells, row selection, and horizontal scroll on small screens. It is also the single most complex component in any library, which is why it tends to be deferred past the point where the deferral is defensible. React Aria’s useTable family gives you the accessibility layer, which removes the hardest part but not the work.

A toast or notification system. Timed, non-blocking feedback. The interesting part is not the visual component, which is close to the Alert you already built. It is the queue: a store, a portal, stacking behavior, timers that pause on hover, and a live region that announces without interrupting. That is a system, not a component.

A popover. A floating panel triggered by a button, without a modal’s focus trap. usePopover handles positioning and dismissal, and you already used it inside Select in chapter 8, so most of the pattern is familiar.

An accordion. Collapsible sections. React Aria does not expose a useAccordion hook; the equivalent is Disclosure and DisclosureGroup from react-aria-components, which is already a dependency after chapter 14’s Menu.

A combobox. Select with typeahead filtering. useComboBox exists, and the component is harder than Select because the input is simultaneously a text field and a collection trigger.

Add these in the order your own usage demands, not in the order a competitor’s documentation lists them. Every component is a permanent maintenance and documentation obligation, and a library of forty components where twelve are unloved is worse than a library of twenty-five that are all solid.

Keeping Figma and code aligned

Design-code drift is the most common friction point in design system adoption, and it is a naming problem before it is a tooling problem.

Figma Variables map onto the token architecture directly. Create collections mirroring your tiers: a primitives collection with the raw palette and scales, a semantic collection of aliases, and optionally a component collection. Name the variables exactly as you named the tokens, so color/brand/primary in Figma is color.brand.primary in JSON. Shared names mean a conversation about brand.primary refers to the same thing in both places, which is most of the value before any sync exists.

Tokens Studio, a Figma plugin with a free tier, can read token JSON and sync values into Figma. Point it at your token files and it keeps Figma’s values current. Run the sync in one direction, code to design: the code is what ships, so the code is the source of truth, and a bidirectional sync mostly produces conflicts nobody wants to arbitrate.

One practical caveat. This library’s tokens are split across tokens.json, semantic.json, components.json, and six theme override directories. Plugin setups that assume a single token file need configuring for that structure, and the theme overrides in particular need explicit mapping onto Figma’s mode system. Multi-file sync and themes are both paid features in Tokens Studio.

Figma Code Connect maps Figma component properties to code props, so a designer inspecting a component sees the real import statement and prop names rather than a CSS dump. It is worth the setup cost on teams with both designers and developers, and hard to justify on teams without.

None of this is set up in the companion repository. Treat this section as a starting point.

Governance, and the word “design system”

A component library is code. A design system is code plus the operating model around it: contribution guidelines, a decision process, a release cadence, support channels, adoption metrics, and someone whose job includes its evolution.

The library you have built is a component library. It becomes a design system when an organization adopts it as the standard and invests in keeping it useful. That transition is organizational rather than technical, and the code cannot make it happen. It can make it easier or harder.

Three artifacts do most of that work, and all three are cheap now and expensive later.

A CONTRIBUTING.md stating what a complete contribution includes: the component, its stylesheet, its stories with descriptions and categories, its tests, its tokens, and a changelog entry. Without it, every pull request negotiates the standard from scratch.

A CHANGELOG.md maintained per pull request, as chapter 12 described. Assembled at release time from commit messages, breaking changes get missed.

A written record of decisions. Why React Aria over Radix. Why the published package excludes Tailwind. Why component tokens are not optional. These get re-litigated every time someone new joins, and a paragraph written once ends the argument faster than reconstructing the reasoning under pressure.

If you want the longer version of this, “Design Systems Are Easy Until You Ship One” covers the governance, adoption, and support side in detail.

What you have now

A complete component library. Three tiers of design tokens compiled by Style Dictionary into eight themes. Eight layout primitives that respond to available space rather than viewport width. Three typography components. Accessible forms, overlays, navigation, and status components built on React Aria. Theme-aware charts. A keyboard-operable drag-and-drop board. Storybook documentation with generated pages, example compositions, and an accessibility audit on every story. A test suite spanning unit tests and browser-rendered stories. A published package with correct externals and type declarations.

More than the inventory, you have the reasons. Why tokens have three tiers, why layout belongs in the library, why the package does not ship a CSS reset, why some components use React Aria and some do not, why a chart needs a MutationObserver, why a drag interaction needs a live region.

Where to go from here

The specific components and token values will change as you use this. That is the point. The architecture absorbs those changes without requiring you to rethink the foundation: tokens define values, components consume tokens, layout handles arrangement, tests verify behavior, and each layer moves without the others.

The parts that should not change are the constraints. Every component reads tokens rather than literals. Every interactive component is operable from the keyboard. Every visual state has a non-color signal. Every published export is one you are willing to support. Those hold whether the library has twenty-five components or a hundred and twenty.

If building this from scratch is not the right investment for your team, Rudiment UI is a pre-built version of this architecture, ready to customize and extend. And the companion repository is the complete implementation of everything in this guide, available to read, clone, or take issue with.