#1 of 5 of the series Design Systems Generations:
Defining | Planning | Adopting | Naming | Retiring

You’ve made a library. Users adopted the library. The design system has settled into an operational rhythm. Days, weeks, and months go by as your design system kicks out new features, smooths rough edges, and help teams along. Then, the whispers. Something is afoot. Is that a VP working concepts with an agency? Is IT grumbling about frameworks? Something...

Bang! “It’s redesign time!” “Our visual foundation is stale!” “We’re shifting platforms!” “We’re switching from {this} to {that}!” Just like that, it’s time for the next generation of your design system. The entire library is in play to be made, delivered, and implemented (again) across adopters that upgrade immediately, sooner or later.

What is a generation, anyway?

I’ve been using the term design system generation for years, although it’s not a term used evenly and regularly across our community:

Design system generation: a stable and sufficient core library of assets, docs, tools and practices delivered for use by designers (in Figma?) and/or developers (React?, iOS?, Android?, …).

A new generation generally means:

1. The entire library’s features — “All the things” — can be impacted.
2. Upgrading requires attention yet may or may not be effortful, depending on the scale of breaking change, tooling and regression required.
3. Changes require aligning with partners like brand and/or architecture.
4. Because things are breaking, it’s time to revisit a backlog to do things a system couldn’t do before so as to not break things.
5. Other system work slows or stops, crowded out by the focus on updating “all the things” and enabling adoption.

Delivering a new generation is the largest, most complicated cycle a design system goes through. The system and its adopters may live with the outcome for years. Therefore, everyone must understand what it is, why it’s happening, and the scale of the effort and reward. This introductory post explores the big questions that define a generation:

• Cause: Why are we changing?
• Scope: What is changing?
• Scale: How expensive is the change? How big is the impact?

Equipped with high-level answers, you can orient your team, set expectations across an organization and start planning.

Cause: Why are we changing?

A design system’s next generation can arise from one of many triggers, including a system’s need to:

• Start from scratch as a “first generation,” because no library exists.
• Redesign features like foundations and components, such as a rebrand.
• Rearchitect features like tokens and component API extensively to support new capabilities, evolve with tools, or right all the old wrongs.
• Switch framework like going from Angular to React or Sketch to Figma, or possibly framework version, such as React 16 to 17.

Not every library-wide change is a “next generation,” however. Improving accessibility or adding component density and sizing controls across a catalog are considerable improvements.

Sometimes, the term generation doesn’t apply: a framework version update or a partial foundation overhaul also may not qualify. The characteristics of a rollout are the same, but at a far lower scale. Such library-wide fixes and enhancements are certainly worth communicating but fall short of the fanfare of a “next generation.”

Who’s driving change: external forces or the design system itself?

Sometimes change is triggered from a system team, other times the change is thrust upon a design system. Both types of triggers — external and internal — come with tradeoffs.

Brand updating a visual identity and IT norming on a “north star architecture” are examples of externally driven generational change. In these cases, a design system has no choice but to “hitch to the wagon” (credit: Alex Skougarevskaya, one-time Atlassian Design System design lead) to enable the outcome.

External forces make things complicated: executives decree timelines, other groups create plans, stakeholders unpredictably communicate. Amid the chaos, a design system can struggle for control. System aspirations can be lost in the din. Therefore, it’s critical to take a “seat at the table” to influence emerging design and the system’s role in implementation.

Communicating priority of generational change to adopters is easy when externally driven: they’ve heard about it, can’t object to it, and may already be planning for it. However, that pressure is double-edged: adopters may be unwilling to wait. A design system’s work translates and encodes a design language into reusable bits. That takes time. Communicating long term values — efficiency, quality, consistency — of that translation is essential to avoid adopters rushing to hardcode answers themselves.

On the other hand, generational change can be internally driven by the system team without external pressures. Stale visual language, outdated architecture, or unachievable new capabilities all drive change. There may be no broader wagon to hitch to, but why wait? There’s no reason a system team can’t rollout big changes themselves.

Adopters are less likely to request generational change, and can resist it once cognizant of the effort required to upgrade. When internally driven, system-led activities require more attention communicate scope (“What you get!”), process (“How to get it!”), and benefits (“Why it matters!”). For example, the design system may target advocates across design and development communities to present explorations, agree on API, and support pilots. Without a galvanizing external force, it’s the up to the system to form groups, drive consensus, and communicate outcomes.

Takeaway: Ensure you—and your team — know who’s driving the change in order to orient what role to play, what posture to take, how flexible to be with your time and how assertive to be when driving decisions.

Scope: What is changing?

Generational change opens minds. Moments that sweep change can lead teams to (re)consider everything they’ve ever wanted to do. It’s all on the table: new features, platforms, tools and ways of working.

Foundations and components … and other stuff?

Usually, adopters expect a new design system generation to refresh visual foundations (implemented as a token taxonomy) and UI components across the catalog. These updates can cascade to UX patterns, page layouts and templates. Less certain is the overlap of design and content, where a new generation may or may not impact content standards and practices.

This generation will update all components with a refreshed take on color and typography that means a new design token taxonomy. We expect minimal impacts to space and size, although shape is in play. Existing standards for accessibility and content (like voice and tone) aren’t expected to change.

To describe feature scope, use visible models that customers are familiar with. For example, sections and oft-used pages of a documentation site provide a foundation to succinctly describe change.

Takeaways: Establish boundaries of what is in and out, balance aspiration with time, resources and customer needs and take opportunities to expand the portfolio

Design assets or code packages or both?

Most generational moments synchronize change across design assets (like a Figma library) and code (like React, Angular, iOS and Android).

However, sometimes a generation can be output and discipline specific. For example, imagine shifting a Figma library from using props to variable/modes to enable color theming. Designers have a whole new model for fundamentals, yet code isn’t impacted. Alternatively, a system may update a React-based code library to support only React 17 and above. Developers must make careful updates, yet designers have no work to do.

In both cases, the work carried all the hallmarks of a generation: touch “all the things,” break and deprecate some things, slow the BAU work, and communicate heavily to system customers. Ironically, in this story, those events occurred at the same time in the same design system. The only overlap of this big moment was to balance program-level communications when they released simultaneously.

Takeaway: Generational change need not impact both design and code, libraries and docs all at the same time. Sometimes, it’s narrower to only one library or one type of output, and that’s ok. Just make sure each audience gets the message(s) they need.

Just docs content, or the publishing platform too?

When features change, so does documentation. The scale of copy, images and examples updates can feel like an approaching slog, but a familiar and predictable slog. Adopters, too, expect the system to update feature documentation. On the other hand, adopters fear is their ability to consume the changes cleanly.

So get past the conversations about “What are we doing with Foundations and Components content?” Get to the richer topic of how you’ll prepare adopters to change through documentation. Upgrades must feel straightforward, easy and risk free. Getting started, procedural migration guides, self guided training materials and demo and playgrounds can carry big payoffs. Done right, they also require meticulous attention and iteration to smooth out rough edges. As you set expectations about your big changes, it’s essential to think through and communicate all you’ll do to enable their changes too.

A generational moment also zooms a team out out to challenge platform assumptions, too. Beyond new content, does documentation need…

• …a site design refreshed to match the new visual foundation?
• …an overhaul to how to author, manage and publish content?
• …to migrate to or from a platform like ZeroHeight, Storybook, … or both?

Any of those transitions will be a major project within a major project (delivering a generation), warranting considerable strategy, planning and communication. Must you pursue any of them to deliver a new generation? Often, no. Should you consider pursuing some of them? Usually, absolutely. Bottom line: generational change usually impacts both and work typically exceeds a simple, fresh coat of paint on an existing site.

Takeaway: Use generational moments to challenge both what and how you publish docs of both what to use and how to change.

Tools and practices

Generational change in a library may be coupled with— or even require — changes to how a system approaches:

• Testing practices, such as Figma component testing, automated visual regression, unit testing and how you integrate accessibility
• Releasing pipelines and practices, such as new places and locations to publish assets or stewarding users through alphas and betas
• Ways-of-working for system makers and adopters and tooling in which they collaborate (such as Jira or Asana)
• Communications throughout implementation and past launch (including email distribution lists and platforms)

Such changes also present as projects within a bigger project. They can be disruptive, unfamiliar, and risk consuming considerable time (such as when licensing third party tools or getting security approvals).

Takeaway: Think upfront about potential new tools and practices rather than organically realize them as you go. Set aside session(s) for the team to explore implications and ambitions that change how the system works.

Scale: How big is the change?

When characterizing change, focus how the change matters to adopters:

• What’s impact of what I get?
• How much will it cost to upgrade?

When upgrading is hard, focus on core and long-term values

Generational terms like “redesign” and “refactor” trigger costs and fears of major changes. Whether a visual overhaul, transition to Figma, or a wholly rebuilt React library, impact may be massive but the switching cost can feel daunting, even paralyzing.

If you are hitching to a wagon carrying the whole organization, teams tend to bow to efforts that seem non-negotiable. There, the system has an opportunity to be perceived as a solution enabling, not albatross preventing, of realizing of that value. When the trigger is internal, the system must communicate how the generation makes an adopter’s present even better and/or describes a now-possible future that previously felt impossible. Let the slidemaking commence.

If upgrading can be easy, make it so and say so

Other times, impacts can be positive and catalog wide, but change costs are limited. At Morningstar, I led the delivery of a second major generation in 2018 refactored all components to synthesize sizing and support varying densities. Sure, every component technically had a breaking change. All the version numbers bumped to a next major version. But developers could integrate updates mostly using search and replace with little fuss.

More recently, I led a team to refactor the Figma library from color styles to variables to ease setting light and dark themes. Fill and stroke color attributes changed across the catalog. Over half of the component assets (including all with a surface property set to dark) were deprecated. Yet, upgrades were trivial (click “Update”), broke nothing in existing files, changed nothing visually, and made finding and swapping deprecated versions a breeze. Developers, apart from interpreting files differently during handoff, were not impacted.

Was the variables switch a next generation? Depends on how you want to apply the term. For tools? Definitely. It reinvented how to apply and use fundamentals, setting a new baseline to grow from. For fundamentals features like core colors and typography? No, those didn’t change.

In both cases sizing/density and variables, communications focused on what adopters got and how not hard and not risky it was to change.

Takeaway: Adopters will compare what’s in it for them with how hard change will be. Relating the value a system enables to the costs it incurs is something you must do succinctly, clearly and honestly.

From the outset, clarifying what will change (scope), why it’ll change (cause), and how big a change it’ll be (scale) is essential. Once those broad strokes are defined, it’s time to dig into how the system will align everyone to a vision and strategy, get the work done, and launch for adopters to use.

Next: #2. Planning a generation