July 20, 2024

Design System Shearing Layers

The Question: Episode 25 Wrap-up

On Thursday, July 18 of 2024 we held the Episode 25 design system deep dive conversation as part of a series called The Question. Thanks for being part of it.

Jeremy Elder and Ben Callahan were co hosts for this episode of The Question.

The Question was shared via email, on LinkedIn, and X and I received 33 responses. Review the FigJam file, the raw data, and the opening music (“From the River” by Elbow) from the Episode 25 deep dive. Major thanks to my friend and design system leader, Jeremy Elder, for co hosting this deep dive!

For the week’s question, we provided this context:

“A design system is a product.”

I’ve said this sentence out loud to many clients in the past, but I’ve stopped saying it in the last couple years. Instead, I’ve encouraged my clients to think of design systems as a program instead of a product. Jeremy and I have been chatting about why this is an important distinction: products are expected to move at a certain speed—generally fairly quickly. Design systems can’t and shouldn’t operate at the same speed. They are more foundational and it’s a higher risk for them to change because multiple products depend on them. If you call your design system a product, your organization might expect the same speed, despite the fact that design systems need to move more slowly.

Mark Boulton articulated this beautifully back in 2018 by connecting the work of Stuart Brand on pace layers to our work in design. And Stuart expanded the concept from Frank Duffy’s writings around Shearing Layers. Mark’s application is spot on and still resonates with our work in design systems today.

This week, we want to explore how you experience this in your organization and learn what it is you’re doing about it. With all of this as context, here is the question for this week:

How does the speed of your design system compare to the speed of the products built with your design system?

How does this play out in your organization and what are you doing to address these impacts?

The Answers

In answer to the first question, approximately 75% of respondents reported that their system does in fact move slower than their products:

In response to the question, “How does the speed of your design system compare to the speed of the products built with your design system?”: approximately 75% of respondents reported that their design system moves slower than the products built with that system.

In general, it felt like most folks who answered feel this tension on a regular basis. There seems to be a constant desire for leadership to see design systems evolve faster than they do.

I asked ChatGPT to generate a summary of the open text answers and received this back:

Challenges of Scale and Expectations: Many teams face challenges due to the expectation that the design system should move at the same pace as individual product teams. This expectation often clashes with the reality that building a scalable, reusable system requires more time and rigor.

Organizations have struggled with initial phases where speed was prioritized, resulting in components that didn’t scale well. This led to a shift towards more structured processes to ensure robustness and long-term scalability.

Balancing Speed and Stability: There’s a recurring theme of balancing speed with stability and robustness. Design systems often evolve slowly but steadily, ensuring foundational elements are stable before integrating new features.

Strategies include involving product teams early in the process to align on requirements, thereby reducing the need for reactive changes and ensuring that updates are aligned with broader system goals.

Empowerment and Flexibility: Some organizations emphasize empowerment, allowing teams to build custom solutions initially and later integrating successful ones into the design system. This approach aims to balance agility with the need for a unified system.

Flexibility in governance and contribution models is highlighted as crucial, enabling continuous improvement without becoming a bottleneck for product teams.

Communication and Education: Educating stakeholders about the design system’s purpose and process is essential. Many responses noted the need for ongoing communication to manage expectations and demonstrate the value of slower, deliberate progress.

Aligning stakeholders on realistic expectations and the long-term benefits of a well-maintained design system is crucial for gaining support and reducing friction.

Iterative Improvement and Collaboration: Continuous iteration and improvement are common themes, with organizations adopting processes to capture feedback and integrate it into the system incrementally.

Collaboration between design and development teams is highlighted as essential for effective integration and adoption of design system components.

Strategic Alignment and Resource Allocation: Finally, challenges in securing resources and aligning the design system’s roadmap with broader organizational goals are evident. Organizations struggle to position the design system as a strategic product rather than just a design tool.

Selected Quotes

Here are a few quotes shared by those who reported their system moves slower than their products (along with some commentary from me):

“In my current org, our system has been pushed as the leader in delivering high-quality product work quickly and easily. As a result, it’s often seen as a blocker when it does not contain everything a product team needs immediately, including new product exploration work.”

“For us it’s less a matter of speed, and more a matter of assumptions of what the DS will provide. Many expected the DS to be a component factory and provide whatever they need, when they need it. That was followed by them questioning why we take so long to release something. I’m still surprised how many people (even in the design org) are oblivious to the work that needs to happen to scale something from single-use to a company wide level (and people who should know better).”

“We’ve been trying to work out what tooling, processes, flexibility, and communication can do to provide ‘healthy tension’ between teams. We don’t want to be a blocker, but we also don’t want to introduce instability to the system.”

“We set a cornerstone pillar of our workstream that we are ENABLERS of work not BLOCKERS and that a consuming team, for example, should never wait on the system to deploy work to production/ship products…even if that means not using as much of the system as they’d like.”

“A majority of the system is foundations/primitives, that rarely need to change. New components/patterns typically get built in product teams, and we keep a ‘shared components’ Storybook for the product(s). Occasionally those move into the system. 9 times out of 10, newly built things aren’t really truly reusable enough to be in the system, IMO.”

This answer, in particular, hinted at the meta recognition that even our systems are made up of systems. The deeper down through these layers we go, the slower things move. Jeremy took some time to sketch a diagram or two (which you can see in the FigJam) to illustrate this. Here’s one that captured it well:

Jeremy sketched an image to illustrate that even the layers of a design system operate at different speeds.

Another observation is that the word “blocker” came up repeatedly in the open text answers. As a community, we understand we can’t be the team that always says, “No” but that we have to find ways to enable our subscribers. The trick is that saying “Yes” often means a consuming team will proceed without the system.

Many responses share how they are attempting to allow this and, at the same time, account for the techncial debt incurred. This became the primary topic of our conversation in the deep dive. It’s a struggle that most systems teams feel once they get into Stage 2 (“Growing Adoption”) of their system’s maturity.

This screenshot from the FigJam illustrates the challenge well—how do we establish “constructive turbulence” in the areas between the pace layers? How do we use this space to push our systems forward in healthy ways.

A screenshot from the FigJam file posing the question: 'How do we turn shearing into constructive turbulence?'

As always, attendees shared some great ideas. Here are a few that stood out to me:

“We’re trying to put in place a system of shared and local libraries, to at least get visibility of the chain of custody and identify when a component, updated feature etc is out of date and needs replacing. But this is slow going to get established, so too soon to tell.”

“In my current team, we’ve implemented contribution processes that allow teams to go custom so that we’re not seen as bottlenecks for the business. This allows teams to build products freely, test experiences, and then bring them back into the system so that we can amplify and scale them across the business. But this also allows us to weed out candidates that don’t perform as well in the product before they’ve even been shared back to us, which has been an issue in the past.”

“There are many context dependent variations that result in something like:

Feature team builds out first pass of newly designed component

DS Designers review design, vet additional edge cases + align with rest of system

DS Engineers take finalized DS design + working version of component from feature team and build out finalized component

Ideally: Feature team refactors to use new DS component”

“To address we’ve been limiting changes to the system as a whole and focusing more on general foundational elements—or from an article I just read, the ‘durable’ components—those which can be used in all verticals, but don’t / can’t change easily and without a larger discussion of why and how the change would benefit the system as a whole.”

As part of this discussion we had a few additional key acknowledgements:

Design system contribution doesn’t come for free. It comes with a heavy support cost—we spend a lot of time doing this throughout the contribution process. (Thanks calling this out, Davy!)
Often, design system work comes with a lot of baggage from past failed attempts. We have to be “systems thinkers” as much as we have to be design system practitioners. (Excellent point, ToniAnn!)
Perhaps shifting the way we think about systems teams as infrastructure teams instead of product teams will shift the way leaders consider their value and speed expectations. (Great thought, Jeremy!)
There is an intimate connection between the concept of pace layers and the concept that parts of the organization need to “invent” and parts of the organization need to “reuse”. I’ve been diving into this with a client recently—this tension exists in most companies but the way we balance it unique to the culture of the organization. In order to explain this, I sketched a rough quadrant diagram and added in the layers of a design system.

A screenshot from the FigJam file expressing the healthy tentions between invention and reuse as well as working fast working slow.

Finally, Jeremy shared the concept of a “paper cuts” team. This is a group of hybrid designer/engineers that help product teams solve product-specific problems using design system patterns. I (and others) were eager to hear more about how this team operates and the impact they’re having.

If you missed the deep dive, check out all the links from above and these additional resource shared by folks in attendance.

Additional resources

Thank you

Many thanks to all who participated.

If you missed out this week, sign up for The Question and be ready to answer next time.

Writing Design Systems The Question

Explore more of my writing and speaking.