Roadmaps for Design Systems

Summary

Effective design system teams utilize roadmaps to communicate their development priorities and commitments, ensuring alignment with the needs of the products and platforms they serve.

Abstract

The article emphasizes the importance of having a clear roadmap for design system teams. It distinguishes between teams that struggle to articulate their tasks and those that confidently outline their focus areas and delivery timelines. A well-defined roadmap is seen as a sign of a healthy system, providing a transparent view of the team's priorities and a reliable cadence of updates. Roadmaps serve to set expectations for product teams by highlighting key elements of each release without overwhelming with details. They evolve from foundational elements for new systems to more complex components and enhancements as the system matures. The roadmap also reflects the system's values and ensures that the team's work aligns with the broader organizational goals. While the presentation of the roadmap can vary, the consistency and predictability of the team's delivery are crucial for gaining trust and dependency from other teams.

Opinions

A design system's roadmap should focus on current, near-term, and future work increments, providing a clear direction for the system's evolution.
Roadmaps are crucial for communicating commitment to delivering value, setting transparent priorities, and maintaining a reliable release cadence.
For new design systems, roadmaps help prioritize foundational elements like visual style, UI components, and layout systems.
Once established, roadmaps should highlight new sections, important parts, and significant enhancements to existing components.
Detailed minutiae should be omitted from roadmaps to maintain clarity and focus on high-level priorities.
Roadmaps reveal what a system team values and ensure that their work aligns with the interests of the products and platforms they serve.
The roadmap should reflect the actual priorities and progress, even if it means removing items that lack organizational traction.
While the format of the roadmap can vary, from a simple story to a dynamic visualization, the key is to communicate and deliver on promises consistently.

Roadmaps for Design Systems

Communicate What You’ll Do Next That Teams Can Depend On

Whenever I chat with a new design system team, I ask:

So, what are you working on?

Some teams muster only an incoherent rambling of scattered tasks. Others confidently articulate discrete areas of focus, and when they plan to deliver each one. I view the latter — a team’s collective understanding that they are evolving a product with a roadmap — as a signal that that the system is operating well.

A Roadmap Reveals a System’s Direction

A design system’s roadmap need not be exhaustive. Most I’ve seen depict nothing more than what’s going on now, next and sometime in the near future across their increments of work, whether a two-week sprint or month-by-month delivery.

A roadmap enables a design system team to convey:

commitment to delivering value, justifying their well-defined funding
transparent priorities, especially critical when serving products and platforms with divergent interests
reliable cadence that customers depend on

Roadmaps Signal Releases That Set Product Team Expectations

Roadmaps highlight the most important elements of each release, charting the system’s direction without drowning in detail. Organizing that simple story into a a milestone based, columnar roadmap format works wonders.

If a system is just getting started, a roadmap may be limited to fundamentals like visual style (like color and typography), key UI components (like buttons & forms), and parts needed to assemble common displays (like getting started and a layout/grid system).

In fact, getting all those aspirational parts on stickies _and then_ arranging those stickies in a columnar roadmap format is a great exercise to center a team’s purpose early on.

Roadmapping exercise leading up to system launch, organizing parts into columns for what to deliver now, sooner, later, and wait

Once a design system is smoothly operating across releases, roadmaps tend to reveal, in priority order:

New sections and broad topics first, like expansions into branding, editorial guidance, a new platform (like Android), or practice like SEO
New, important parts, like a modal component, editorial word list, or system onboarding training for new hires
Very important enhancements & extensions to existing parts, like adding tertiary button variation or more responsive layout variations

Roadmap of an operating design system, delivering on a monthly cadence

Leave out the detail. Less relevant parts and a long tail of fixes and burgeoning documentation drown a roadmap, robbing it of its simple and focused appeal.

Roadmaps Expose What a System Values

Roadmaps also expose what a system team — and by extension, an enterprise — values at any given time. Our system roadmap across years of a responsive redesign always seemed to position responsive images in the third, “coming soon” column. During every monthly (sprint) planning meeting, we’d try to nudge it into next.

But there was no organization traction, and thus no will on the system team to drive an initiative that they didn’t own. Responsive images stayed on the far right month after month after month, until one of us had the guts to finally remove it until products got their act together. The roadmap worked well: the system’s priorities aligned with the portfolio it served.

Does Your System Have a Roadmap?

Your team need not display a glossy roadmap visualization on your homepage or rendered dynamically from a Jira backlog (although, either would be awesome).

Just ensure your team can tell a consistent, confident story of “We are working on [this] now, [that] next, and the [other thing] sometime soon…”

If you get your story straight and you deliver releases predictably consistent with that story, teams will value and depend on you.