skip to content

Why does a design system team publish a public roadmap for its consumers, and what should that roadmap avoid promising?

level: middleimportance: nice to knowfreq 20%

answer

  1. consumers plan around you
  2. fewer 'is it coming?' questions
  3. now, next, later
  4. direction, not delivery dates
  5. show what was declined, too

basics

~20 s

A public roadmap lets consuming teams plan: build locally now or wait for the system. It cuts repeat questions and invites early feedback. It should show direction and confidence, such as now, next and later, not fixed dates it cannot keep.

solid answer

~50 s

Product teams constantly decide whether to wait for the system or build something themselves, and they can only decide well if they know what is coming. A **public roadmap** answers that once for everyone, cuts the stream of 'is X coming?' questions in the support channel, and lets consumers comment on priorities before work starts. The format that works is usually **now, next, later**: what is in progress, what is committed after that, and what is being considered, with confidence falling as you go right. What it should avoid is **fixed delivery dates** far out, because a small team's plans change and every missed date costs trust; and it should not list every request as if accepted. It helps to show what was **declined** and why, so teams stop waiting for something that is not coming.

go deeper

for a junior

Recall that a public roadmap tells consuming teams what the system will build, so they know whether to wait for it or build something themselves.

for a middle

Explain the now, next, later format, why confidence falls to the right, and why a declined column is as useful as the plan itself.

for a senior

Show how you would keep a roadmap trustworthy: scheduled reviews, links to requests, public announcements when items move, and dates only where realistic.

for a principal

Weigh how much commitment the roadmap should make to leadership and consumers against the flexibility a small team needs for urgent work.

## What a public roadmap is A **design system roadmap** is the team's plan for what it will build, change or retire. Making it **public** to consumers, visible to every product team that uses the system, turns it from an internal planning tool into a support tool. It answers in one place the questions consumers would otherwise ask one at a time. ## Why publish it - **Build or wait decisions.** A product team that needs a date picker must decide whether to build one or wait for the system. Without a roadmap, it guesses, and a wrong guess creates either a duplicate component or a missed deadline. - **Fewer repeat questions.** 'Is the new data table coming?' stops arriving in the support channel when the answer is published. - **Early feedback.** Consumers can say 'we need this sooner' or 'this is not what we need' before the work starts, when changing course is cheap. - **Trust through transparency.** Teams that can see the plan are more willing to depend on the system, and more forgiving when priorities shift for visible reasons. - **Alignment inside the team.** Writing the plan publicly forces the team to agree on it. ## A format that survives reality | Column | Meaning | Confidence | |---|---|---| | **Now** | In progress; expected in the next release or two | High | | **Next** | Committed and scoped, starting after current work | Medium | | **Later** | Being considered; may change or be dropped | Low | | **Declined** | Considered and not planned, with a reason | Decided | The columns communicate confidence without dates. A date may appear for items in **now**, where it is realistic; items further out carry a quarter at most, or none. ## What to avoid promising - **Fixed dates for later items.** A small system team's plans shift with urgent bugs, accessibility fixes and organisational priorities. Every missed date spends trust that took months to earn. - **Every request as accepted.** A roadmap that lists every ask becomes a wish list, and teams wait for items that will never be built. - **Scope detail too early.** Committing to a component's variants before research locks the team into a design it has not validated. - **Silence about changes.** When an item moves or is dropped, say so and why; a roadmap that quietly changes is worse than none. ## Keeping it alive 1. **Review it on a schedule**, for example monthly or each planning cycle, and date the last update so readers know it is current. 2. **Link items to their requests** in the intake, so requesters see where their ask landed. 3. **Walk through it in community meetings**, where consumers can question priorities in public. 4. **Announce moves**: when an item changes column, post the change and the reason in the support channel. ## An example: an airline booking flow Teams working on an airline booking flow ask repeatedly whether the system will offer a date-range picker for outbound and return flights. The roadmap shows it in **next**, with a note that the search team's research is informing the variants, and a **declined** entry for a seat-map component, with the reason that only one product needs it. The fare-selection team now knows it can wait a cycle for the date-range picker; the seat-selection team knows to build its map locally. The support channel stops receiving both questions. ## How it relates to other support The roadmap is one layer of the system team's support model, alongside documentation, the support channel, office hours and the request intake. It works best when the intake feeds it, triage decisions appear on it, and community meetings discuss it, so consumers see one consistent story of what the system is doing next and why.

  • Why include a declined column on a design system roadmap?
    A declined item with a reason tells teams to stop waiting and build their own solution, and shows that requests were considered rather than lost. Without it, every unlisted request stays an open question, and teams keep asking or quietly postpone work in hope.
  • A roadmap item slips a quarter. How should the team communicate it?
    Move it publicly, with the reason, and post the change where consumers will see it, such as the support channel and the next community meeting. Teams that planned around it need time to decide whether to build locally, so early, honest notice matters more than the slip itself.

saying these in an interview costs you the question

  • A system roadmap should list every request so no team feels ignored.
  • Firm dates on every item make a roadmap more trustworthy.
  • Roadmaps are internal; consumers only need release notes.
  • Changing a published roadmap item quietly avoids needless worry.