Skip to content

Roadmap

Where root is, what comes next, and how mature the system is - measured from the repository wherever a number can be measured, and said plainly where it cannot.

Nothing on this page carries a date. A design system that promises months it does not control is a design system that misses them; what it can promise is an order, a gate every component has to pass, and a count of how far along that is today.

Ready for Dev21

of 54 components: published to npm, covered by the accessibility gate, and safe to build on

In progress33

on this site with a warning on every page, so the work can be reviewed before anybody depends on it

Foundations10

token families, each page generated from the stylesheet it documents

Versionv0.0.1

one package per component, each released on its own

Every component, by the category its own package declares. Sortable on each column.
Category Ready for Dev In progress Total
Actions 1 3 4
Data display 6 4 10
Feedback 0 5 5
Forms 11 10 21
Layout & utility 0 3 3
Navigation 2 4 6
Overlays 1 4 5

What comes next

The order below is not a wish list: it is the low end of the maturity assessment, worked through from the bottom. A system improves where it is weakest, and the weakest dimensions here are the ones about people and consumers rather than the ones about code.

Finish the components that are in progress. Each one leaves the unfinished state the same way: its README documents what the code actually reads, its examples run on its own page in both color schemes, its behavior is covered by tests in a real browser, and axe finds nothing on the page. Then the flag moves, and the release picks it up. No component is promoted in a batch.

Publish a changelog and release notes. Releases are already gated per package, and the release script writes a changelog - but nothing published tells a consumer what changed between two versions of a component they depend on. That is the largest single gap in Support.

Write down how to contribute, and how to deviate. Governance is the dimension where this repository is strongest on paper - thirty architecture decision records, a lint for every rule that can be linted - and weakest in practice: there is no written route for somebody outside the team to add a component, and no way to record that a product knowingly went its own way.

Keep the tokens in step with the design tool. The plan for that is written (docs/figma-token-sync-plan.md) and not built: today the token stylesheets are the source of truth and Figma is kept in step by hand, which is the direction that survives a hurry better than the other one, but not a substitute for the sync.

Measure adoption instead of assuming it. Nothing here counts who uses these packages or how correctly they use them. Until something does, Adoption stays scored on absence of evidence, which is the least comfortable line on this page and the most honest one.

Build the multi-tag select. A <select multiple> whose picks render as removable Tags inside the field - the reader chooses from the select's own dropdown, each choice becomes a tag in the field wrapper, and removing one deselects the option. It needs to be the field's own component, not authored markup: a native <select> takes <option> children and nothing else, so only whoever builds the wrapper can put tags inside it. Tag already carries what it needs.