So you’ve gotten buy-in, you’ve made an inventory of designs and components, and you’ve set up your team’s first design system. What happens next? This talk will explore maintaining a design system, as well as new challenges that arise once your design system matures.
Design systems have grown significantly in popularity. Design systems are the new "must-have" for any company that intends to scale. According to UXPin, "A design system is a set of standards for design and code along with components that unify both practices. Think of it as the same instructions and Lego kit for everyone."
There are plenty of talks, blog posts, workshops, etc. that cover what a design system is and how you build one, but not enough about what you do after the fact. We all have a lot of knowledge about how to make the product, but not enough knowledge about how to maintain the product, and what pitfalls might occur two to five years down the line. On top of that, because design systems are very new, there are only a few that are truly mature.
My talk, "What Happens Next? Everything That Comes After Setting Up Your Design System," covers what you can expect to deal with as your design system matures. Over the past 3 years of building, launching, and keeping up with the Lightning Design System, the team learned to focus on certain key areas in order to sustain the design system as it sophisticated. During this talk, I go into detail about those areas that the Lightning team decided were important to scale. The areas I reference include: maintaining components, adoption, support, documentation, tooling, and strategy/architecture. Additionally, I share case studies from Lightning to illustrate how exactly the team chose to tackle scaling those areas.
I did a version of this talk at Clarity Conf 2017, a conference focused on design systems, organized by Jina Anne.
If you're interested, you can check out the slides for the talk (pdf, no speaker notes).
At Clarity Conf 2017, I asked the audience an open question: "What is a good way to communicate changes that happen to your design system to all of your users? These changes can range from component additions, to component updates, to design modifications." As this is something that the Lightning Design Systems team has found challenging, I wanted to know what strategies others might be using and finding success in when it comes to communicating change to their broader range of design systems consumers. The audience responded via a Twitter thread I started, and here are the responses:
off the top of my head — descriptive changelog w/ dev/design notes, denote breaking changes, new components, modifiers. auto publish changelog to email lists, a feed to slack/etc. also on style guide site.
— elyse @ #clarity2017 (@elyseholladay) November 29, 2017
We use Facebook at Facebook to communicate (surprise!), so we have groups to share and discuss system changes. We also rely a lot on system advocates within product teams to organically share those changes with their team. #clarity2017
— Daniel Eden (@_dte) November 29, 2017
Every sprint ending with a release has a JIRA subtasks for:
— Nathan Curtis (@nathanacurtis) November 29, 2017
1. Compose Release History & Announcement (and get it edited)
2. Publish Homepage & Release History Updates
3. Release
4. Announce in 2-4 Slack & other channels
We have several slack channels specifically for our system. Its a way for our users to ask us questions anytime and for us to make announcements (roadmaps, version launches, polls). We also use github to publish release notes and talk with users about questions, bugs, & requests.
— Carbon Design System (@_carbondesign) November 29, 2017
We send out newsletters. Easy to reach different types of users (design, eng and pms).
— Tina 🇨🇭🇯🇵 (@tinastsh) November 29, 2017
Automate sending changelog as newsletter with every major release. Communicate all breaking changes on Slack. Always on Design systems page History section. Always include info for support.
— Niko Laitinen (@laitineIO) November 29, 2017
If you're interested in sharing what your team does, feel free to respond to the original thread, and I'll add it here as well.
Thanks to all of the smart people who were willing to share their insight!
If you're interested in chatting with me about this talk, or design systems in general, please DM me on Twitter and we can take the conversation from there. If you DM me on Slack, I might not respond :/