Beyond Launch: Nurturing & Sustaining Design Systems — Panel Recap

Missed our expert panel on maintaining your design system or just want to refresh your memory? Learn about the process, challenges, and strategies for success. Here are the main takeaways from the discussion.

Design systems follow a familiar product lifecycle — there’s an initial wave of excitement to build and launch a new product with early adoption and growth fueling your momentum. Then the dynamic shifts as you transition from building to maintaining your design system.

When you enter this maintenance mode, how do you ensure contributors are empowered and remain engaged to maintain, nurture, and sustain your design system? Our panel — which you can rewatch — featured three design system leaders to discuss this topic:

  • Bethany Sonefeld - Design Manager for Duo Authentication at Cisco Secure
  • Henry Daggett - Design Systems Lead & Product Designer at Societe Generale
  • Jeremy Dizon - Lead Product Designer, Design Systems at Disney Streaming

Here are the top five takeaways from the panel.

1. Communicate Early And Often

Communication, communication, communication. Did we mention communication? Comms is how people in your organization discover your design system and how you’re driving value across the company. Henry estimated, “20% of my week is writing comms, like writing release notes and things like that”.

Most designers aren’t writers, so this can be a difficult shift in tasks. That’s why it’s important to set up communication channels early and implement simple frameworks to make crafting and distributing your comms easy.

Jeremy provided a great messaging framework and communications timeline for deprecating a component or launching a new version of your design system.

For messaging, you should include:

  • A quick high-level summary of what’s happening and why
  • Provide a timeline and deadline if applicable
  • Share the actionable steps that folks need to take

For the communication timeline, plan to send multiple messages across several weeks.

  • First message: At least a month (for component deprecation) or a quarter (for new version)
  • Second message: A week before deprecation or launch
  • Third message: A week after deprecation or launch

While no communications strategy is one-size-fits-all, this is a great starting point for any design system team. Jeremy drove home the point that you should “communicate early and often to let everyone know” to drive visibility and adoption, help manage expectations, and showcase the value your design system provides across the organization. You can also find more communication advice from Lauren Beatty, Staff Engineer at Zapier, in her article Building Effective Communication and Collaboration for Design Systems Teams.

2. Create Processes, Templates, And Frameworks

Processes and frameworks — like the ones Jeremy shared for communicating changes — are helpful to structure how your design system team works and make things more efficient and scalable. Bethany noted, “When I think about the design systems that have been successful, they’ve set up processes really well to help with maintenance.”

Create processes and templates for things your design system team does consistently, such as deciding when to build a new component or communicating updates to product teams.

For example, Henry shared the framework the design systems council at Societe Generale follows to decide when to build a new component. Here’s how it works:

  • Gather all new requests (Henry’s team uses Github to centralize the requests) and discuss them with your design systems team.
  • Prioritize requests that have at least three different projects asking for it.
  • Consider how severe a bug is and if it’s affecting an important service or blocking a product release.

This framework helps his team prioritize requests consistently and ensure their work adds the most value and impact across the organization.

3. Prioritize Based On Value

Maintaining a design system is a careful balancing act between building new components and writing new documentation while maintaining what already exists. It’s impossible for your design system to be perfect and address everyone’s needs.

Henry emphasized that managing expectations and focusing on the most valuable component is important. He would go about doing this by:

  1. Making a list of every component inside the product
  2. See which ones are duplicated the most
  3. See which ones have the highest level of technical effort
  4. Correlate the two and focus on the components at the top of each list

He added that if you can’t work on something, be upfront about it. Give them an estimated date for when you can work on it (even if it’s ten months out) and end with, “Do you want to build it for us?”

When deciding whether to version or deprecate a component, Bethany recommended figuring out if what you have can scale and will continue to work or if it’s easier to go back to the drawing board and start from scratch. Sometimes, starting from scratch is faster and more effective than updating what’s existing.

4. Develop a Roadmap

We all discuss how a design system is like a product, but have you created a roadmap? A roadmap is a great tool that allows you to zoom out and plan time for different phases like building, learning, and maintaining. This helps you carve out time for activities that energize contributors and still fix and update your design system.

Developing a roadmap may sound like a large commitment when organizational priorities are continually shifting, so Bethany shared some insightful tips to help you get started:

  • Align your roadmap with what product teams are working on
  • Map out when specific teams will need certain components or support
  • Incorporate times for innovation, learning, and maintenance during sprints

Keep in mind that design systems roadmaps are flexible, living documents. You can adjust this on the fly when Figma drops a new feature, a team needs immediate support, or your team just needs some fun exploration time.

5. Celebrate All Contributions

Celebrate good times…come on! Let’s celebrate! Sing it with us. Recognizing and celebrating all contributions is important, especially in maintaining design systems. This is a great way to boost morale for everyone and motivate people to continue contributing their expertise in the future.

Recognizing contributions also plays an important role in the value your design system generates. Our panel shared a few ways celebrating wins can do this:

  • Creates career growth opportunities by tying back their contributions to business goals
  • Educates and levels up team members and contributors to thinking on a systems level
  • Highlights the effort and work that goes into maintaining a design system

Celebrations can be as small as calling out contributors in release notes, sending thank you emails (pro tip from the audience: CC their boss or manager!), or little Slack messages between team members. The main point is to give credit to everyone and maintain a positive culture while working on your design system.

Now’s a great time to say “Thank you!” to your design system maintainers!

Maintaining your design system is a shift in mindset from the excitement of creating to focusing on optimization and efficiency. Our panel shared a wealth of knowledge and experience on what maintaining a design system looks like and how to set a design system up for success by empowering contributors and team members. ‍

Get started with Supernova today

Unlock the full potential of your design system with Supernova, empowering you to drive innovation, collaboration, and seamless scalability.

How To Build A Multi-Branded Design System Using Supernova

Discover the potential of a truly connected design system that supports all your brands. Learn how to create your own multi-branded design system with Supernova.

Beyond Launch: Nurturing & Sustaining Design Systems — Q&A Follow-Up

We've brought back our panel of experts to answer your burning questions from the Beyond Launch panel.

Documentation Is a Living Thing: How We Talk Informs What We Make

Luke Finch, product designer and design systems consultant, joins us for a guest blog post explaining the relationship between documentation and communication.