Adopting Design System Generations

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

What’s changing? All colors, typography, space and component designs.
Why? Because executives decided to.
How big is the change? It’s big. More a revolution than a refinement.

Now that you’ve painted the big picture, it’s time to talk specifics. What does all this mean to how adopters must change? Each adopter’s questions reveal the bias of they may see their world:

“When can we start?” (→ Eager)
“By when must we be done?” (→ Pragmatic)
“Do we have to? What if we don’t?” (→ Reluctant)
“What if we didn’t use your system to do it?” (→ Individualist)

These questions aren’t complicated. Unfortunately, answers can be. Harried product owners and leaders may not be interested in what to them feel like complicated conversations. For generational changes, answering sufficiently requires you understanding who’s asking it and their patience to listen. Both may be in short supply. Under pressure, they just want to get on with it and see a system as blocking them from delivering the goods. Heck, will they even wait?

This post covers common challenges that emerge when aligning how a design system deliver changes to adopting teams to integrate that change into their experiences.

Challenge 1: A system IS a dependency. Or, lots of them.

When keen adopters ask “How long?”, you can’t keep responding “We’ll let you know.” A system generation may take three, six, twelve or even more months, and you must have a plan to clearly communicate. As you start to explain things, reality sets in. You deliver things like colors and components to them, and then they integrate them. That puts the system in a position of being “The Dependency.”

Yet, a design system library is made of many subsystems and component parts. That means you can decompose delivery into a succession of dependencies as relevant for adopters.

• Adopters must be encouraged to start before a system is done. To deliver incrementally means they could integrate incrementally too if it helps.
• Adopter should influence priorities to get what they need when they need it, which may give the system more time for other things too.
• Adopters could finish before the system finishes, since the system can defer features many don’t need to the end. Wouldn’t that be delightful?

Takeaway: Be generous with the time you invest in crafting, sharing, aligning and nurturing plans with adopters throughout the cycle. Critical is a shared sense of purpose in delivering value to end customers. We’re in this together. So let’s figure this out and deliver as best we can, together.

Challenge 2: The system HAS dependencies

What’s more challenging than the system being a dependency? A system that has dependencies causing it to move slowly, wait, or not even start.

A typical example: the system team may be blocked by an agency hired by design and brand VPs to establish a new design language. The agency may iterate, concept after concept. Delays arise when stakeholders schedules don’t align. Iterations continue to get things just right. Nobody seems to acknowledge that all the iteration impacts timing of delivering downstream work.

The system team may not control any of this. Heck, the system team may not be in many of these conversations. Such opaqueness and uncertainty can feel paralyzing. Even worse, it’s the system that seems “The Blocker.”

So, to serve adopters best, shift the mindset to getting “The Head Start” instead. Getting a head start can include:

• Quick passes to inject emerging design language choices into existing system assets to show the future (and expose gaps from here to there).
• Explore refactored system models — token taxomony, expanded modes, a spike of component code — based on emerging designs even if those designs are unstable or disposable.
• Coordinate with upstream providers to deliver incrementally, too. Could they finish color language before optimizing typography? Could semantic colors be delivered before data visualization palettes?

Takeaway: Challenge yourself to start the system engine without waiting for dependencies to finish. Possible setbacks and wasted work occur. That’s the game you play. But when time is short, it can be worth the risk.

Challenge 3: Adopters may be unwilling to wait

Separating an agency’s design language activities from a system team’s library production exposes most dangerous misperception: Once a design language is approved, adopters can get started, right? Not so fast. Most of the system team’s work to finalize, code, test and produce library assets may be just beginning.

Will adopters wait? If they don’t, what if they deliver the design directly themselves? When an external force triggers change, speed to market creates pressure on adopters to implement without system assets. They’ll push the system to the side or ignore it altogether. “It’ll look the same, right?” seems, to them, a reasonable compromise. If waiting for a design language is paralyzing, becoming “The Ignored” system is even worse.

This behavior may seem consistent with the first part of my third principle of my 2017 Principles of Designing Systems:

Products own their destiny…

Yet, design systems promise much more than making disparate experiences “look the same.” In this moment, the system must educate partners on tradeoffs grounded in system principles. If the adopter ignores the system, outcomes include:

• Redundancy to produce features the system team will also deliver.
• Inconsistency with a system when adopter implements an incomplete and often unstable design language the system ends up refining.
• Poor feature quality (such as accessibility) and completeness (such as states and variations) when they cut corners. Which adopters will.
• Inability to upgrade as the system delivers, fixes and extends features.

You don’t have come in too heavy handed, like:

“So, to be clear, you want to be the product building redundant, lower quality, incomplete things inconsistent with the other products? To be fast? Got it.”

I mean, you could. But you probably shouldn’t. And you shouldn’t need to. Instead, this is when I’d bridge to the second half of that principle:

…systems equip products to realize that destiny.

Unfortunately, “The Wait” — the time between the design language being complete and the adopter able to use system assets to achieve their destiny — is real, impactful, and largely out of an adopter’s control.

Design system planners must minimize “The Wait” to best suits interests of that adopter AND the organization overall to:

• Order features based on (prioritized) adopter needs.
• Prioritize minimum viable features, such that upgraded features not needed now can be delivered later but not impact component API.
• Delivering useful but not yet fully tested features so that adopters to can start implementing and the system can follow with stability and robustness later.

Takeaway: Assuaging the fears and tamping the tendencies of impatient adopters is hard. So equip yourself with talking points of system rationale, patience to tread difficult conversations, and peace in the control you don’t have over the decisions they make. But you can control what you deliver how well by when, so get to work optimizing that with your partners.

Challenge 4: Adopters fear migration is too complicated

Of course you’ve planned for roadshows, training materials, playgrounds and automations to help adopters bridge from here to there. Yet, the work ahead may feel daunting to even talented designers and engineers.

When work looks hard, unfamiliar, complicated or a distraction, that can lead to a “Rough Start.” Teams may delay getting going. Once they do get going, their progress seems slow and stunted.

Would you be willing to help get them started? In vast ecosystems across a big enterprise, the design system team isn’t responsible for integration work. However, system experts can be well equipped to demonstrate work in context rapidly, such as in the form of “Kickstarts” large and small.

Examples of kickstarts include:

• A front end system technologist migrating a flagship product from using old variables to new tokens in what becomes a massive pull request full of small edits. Ed, you rule!
• A system Figma-expert branching other team’s shared libraries, converting select components from styles to variables, and using outputs to train those library owners to do the rest. Plus, take learning outcomes back to improve system docs too.
• A system advocate auditing an existing build — whether code or Figma — to identify examples of items to upgrade or swap, impacts to API, and tips on how to order the work.

Kickstarts aren’t for everyone and require available system team capacity, adopter priority, and adopter interest. Plus, let’s be clear: the kickstart doesn’t do all the work (well, Ed’s did, but that’s because Ed is awesome). Usually, a kickstart can quicken integration in most-impactful places. Benefits go both ways, since the system can learn lessons that lead to improved features and documentation, too.

Takeaway: If willing and able, ask “How can we help?” Even if you have to say no to some ideas, conversations can lead to partnerships benefitting both and remove a fog of fear of how new things work.

Challenge 5: Adopters coordinating launches, particularly a big bang

When working with many adopters, a few things become clear quickly:

1. Adopters often start integrating at different times.
2. Adopters often launch integrations at different times.
3. Adopters may not coordinate when to launch integrations in concert, but are expected to launch in concert nonetheless.
4. Adopters own their own roadmaps and backlog, it’s often already full of other priorities, and it’s up to them to fit the system in.

Typically, the design system doesn’t own, drive, or is accountable for any of these decisions or outcomes. That’s up to other stakeholders, leaders, and business units that the system serves.

Adopter roadmaps and coordination are out of the design system’s control, but are certainly within the system team’s influence. In particular, I would expect that the system team is often best positioned to:

• Identify opportunities for and gaps of adopters lacking alignment when the should be (even if the system isn’t responsible for resolving them).
• Equip adopters launching in concert with shared needs that serve all of them, such as timely ongoing assets, updates and fixes.
• Communicate needs emerging from one adopter that are relevant to the rest of them, such as an updated logo, refined token values, or revised standard content (such as footer legal and link content).

Takeaway: You want a seat at the table? Then provide the value through mindful participation, helpful hints, and assertive problem solving when systems can have positive impacts. Just as much, don’t bear responsibilities you shouldn’t, such as product managing a coordinated launch across stakeholders you don’t control.

In summary, coordinating with many independent, self-interested adopters can be complicated and challenging. Turn those challenges into opportunities by being helpful to redirect and reorient conversations with:

• How can breaking down what we deliver help you?
• How can we integrate with upstream activities to move faster?
• How can we get you enough so you can get started?
• How can we help kickstart your efforts?
• How do your efforts relate to other teams?

All those questions — and, hopefully, useful answers and conversations that follow— demonstrate you are as interested in making them successful as you are in getting your token taxonomy and component API done.

Next: #5. Naming a generation