Roadmap and versioning
A design system feels unstable when teams cannot tell what is ready, what changed, what broke and what is safe to adopt.
Lesson learned
Build in layers, with a usable outcome at each stage
A sensible setup sequence moves from foundations to implementation rather than starting with a large component catalogue. Each phase should leave behind something a product team can use, test or review.
This keeps the roadmap grounded in delivery. A token model is not complete because its names look coherent; it is complete when a real component can inherit it in Figma and code. A component is not complete because it renders; it is complete when guidance, accessibility, states and migration are ready too.
- 01Audit and name the foundations
Inventory products, Bootstrap versions, brand rules, repeated components and exceptions. Agree the
icare-namespace and the separate token-name grammar. - 02Publish shared token collections
Create reviewed global and semantic decisions in Figma and code, with explicit theme mappings and ownership.
- 03Package high-use components
Start with controls that remove repeated product work. Include supported Bootstrap mappings, states, tests and guidance.
- 04Prove patterns in a product
Compose components into one funded feature, capture implementation friction and turn the evidence into roadmap priorities.
- 05Scale documentation and governance
Publish contribution rules, release notes, compatibility guidance, adoption measures and a visible support model.
Backlog structure
Use one hierarchy for system work
Delivery can be managed in Jira under a design-system initiative. Epics group meaningful outcomes such as foundations or a component family, while stories capture the work required to design, build, test, document and release each change.
The hierarchy kept component work visible without pretending that the design-system team owned every dependency. Work inside the library stayed in the design-system backlog. If adoption required a change in a product codebase, a linked story moved into the relevant squad’s backlog for that squad to plan and deliver.
The long-lived investment, outcomes and organisational roadmap.
A foundation, component family, major migration or adoption outcome that can be planned and reported.
Figma design, code build or change, states, accessibility, tests, documentation, release and migration work.
Product-code changes sit in the owning squad’s backlog and remain linked to the system epic so the dependency stays visible.
Planning views
Separate direction, operating guidance and delivery
Use high-level roadmaps to show the sequence of component work, Confluence pages to explain how the design system operates, and Jira to manage committed delivery. Each view answers a different question and needs a clear owner and review cadence.
What capabilities and component families come next, and why that order matters.
How work enters the system, how decisions are made and how sequencing is assessed.
Who owns the current work, its dependencies, acceptance criteria and target release.
Prioritisation
Sequence components by value and delivery reality
Do not order the component roadmap by visual simplicity or whoever asks most recently. Review candidates against a small, published set of criteria, then record the evidence behind the decision.
How often the component or pattern appears across products and active delivery work.
How strongly consistency, accessibility and interaction quality affect the user’s ability to complete important tasks.
How many products, teams and supported Bootstrap versions could use the shared result.
Whether requirements are understood, engineering capacity exists and dependencies can be planned.
Tables often become an important roadmap discussion because they combine high usage and high user impact with substantial complexity. Sorting, filtering, selection, pagination, responsive behaviour, empty states and accessibility make a table a capability rather than a single visual component. Treat work of that size as an epic with staged stories and real product validation.
First release
Keep the first deliverables concrete
The first release should be deliberately small enough to maintain and complete enough for one product team to adopt without private explanation.
- The
icare-namespace and a token-name grammar shared by Figma and code. - Core colour, type, spacing, radius and elevation decisions.
- Default theme mappings and an explicit position on future themes.
- A small set of high-use components with states, accessibility and Bootstrap compatibility documented.
- One live product implementation that tests the system outside its own repository.
- A changelog, support route and named owner for the next release.
Release strategy
Ship around decision boundaries
Release when a meaningful decision is complete: a token set, component family, pattern or migration. Avoid releases that bundle unrelated fixes into one hard-to-read event. Every release should say what changed in Figma, code and guidance, which products are affected and what action adopters need to take.
Version the contract, not every internal edit
Corrections that preserve the supported API and visual intent, such as documentation fixes or non-breaking implementation repairs.
New backward-compatible tokens, component variants, patterns or guidance that teams may adopt when ready.
Breaking changes to names, APIs, behaviour, dependencies or supported Bootstrap versions that require migration.
Figma libraries and code packages should tell the same release story even when their version numbers cannot be mechanically identical. Link both to one human-readable release note and migration decision.
Deprecate before removing
Give teams a replacement, a migration path, an owner and a date. Mark deprecated items in Figma, code and documentation at the same time so nobody discovers the change too late. Where products carry different Bootstrap versions, publish the compatibility boundary and avoid forcing migration without funded product work.
Keep the changelog public
The changelog is a trust object. Write in plain language, link to examples and say who is affected by each change. Pair it with a small compatibility register showing each product’s Bootstrap version, design-system version, known exceptions and migration owner.
A roadmap is not a promise to build everything. It is a promise to make choices, dependencies and migration visible.NextResourcesFigma libraries, token exports, workshop decks and the standards index.