Why and how to make your design system public
Jules Mahe
It is in our nature and our roles as designers and developers to display our work because we are proud of it and want to share it with others. However, when it comes to your design system, you may have been stopped by your boss because they feel that it is a project too sensitive to be shared. You start wondering if they’re right. But what if it’s not?
Let’s break down all the arguments you come up against when you make your design system public so that next time the question pops up, you’ll have them all on hand.
Why make a design system public?
It is not so much to prove the value of your design system in the end; it’s about showing the value of your organization. A design system is a good indicator of how mature design is at your company. Maybe you should ask why they don’t want to make it public. Aren’t they proud of their work? Do they fear being ridiculous? Are they not confident enough?
Brad Frost is an advocate of open design systems. As he explains, making your design system public is crucial for managing and maintaining it:
“Publishing your style guide for the world to see increases its visibility, increases accountability, and serves as an amazing recruitment tool.”
Visibility
By increasing its visibility, you increase the likelihood of your design system being used. Adding restrictions to access limits visibility and burdens your team and partners, reducing your design system’s effectiveness and potential.
Ellis Capon from News UK explains how their teams were much more open to adopting their NewsKit design system once it was open-sourced:
“With us open sourcing it, it meant that there were zero barriers for anyone picking it up. It being open sourced was a more appealing proposition to engineering leaders in other business units, due to the transparency it brought.”
He also adds how making it public has been rewarding for teams to be recognized for their hard work:
“It was also a good demonstration of the tech we have. We’re super proud of our design system, so we want to show it off. It helps our engineers and designers feel like they’re getting some recognition”.
However, you’ll probably face this obstacle against visibility: phishing. It is one of the most frequently used arguments against public design systems. But the fears of spilling sensitive content are completely groundless: we are talking about UI patterns, not credit cards, client databases or nuclear codes. It is true that by giving hackers free access to our component library and documentation, they might believe that we make it easier for them to replicate our websites. Although, this is not a valid argument as hackers can still use your components and patterns by grabbing the relevant elements directly from your current website. Show the reluctant people how easy it is to display and access the source code of one of your sites. You might even claim that there is less material to exploit on your design system than on your company’s official website the next time someone uses the phishing argument.
Moreover, considering sharing your work as making a gift to competitors is an absurd and old way of thinking. For instance, everyone knows about Paul Rand’s work at IBM. It is even taught at schools and it’d be crazy to think you could learn about his work by requesting access. It’s time to live in the digital age.
Accountability
Design systems that are open to the public help organizations be more accountable and provide valuable documentation to the public.
However, LinkedIn’s UX Lead Nate Whitson makes it clear in an interview about public vs. private design systems by saying that sharing information outside of a company requires additional context for the uninitiated. It adds to the expense of what you have to write, design, and document and provides a helpful bit of pressure to keep it current and relevant.
On one hand, you demonstrate your organization’s commitment to the design system by publishing it; on the other hand, it certainly puts some pressure on your team to maintain it. Making your design system public is a good excuse to force you to release content that is always up-to-date and of high quality. You may consider it as a constraint, but instead, see it as an opportunity to raise your standards and goals.
There is also another interesting alternative shared by Ryan DeBeasi in his design systems and relationships article. He explains how he’s split the difference in the past: rather than making their design system public, they treated it as a small open-source project within the organization, reaffirming that the concept of making a design system public has many facets.
“We didn’t have permission to make our design system public, so we did the next best thing: we treated it like a small open-source project within the organization. (…) We found that teams were under pressure to learn new technologies and deliver a complete product quickly. In other words, they were already operating under a pretty considerable cognitive load. As a result, the teams agreed to focus on making the system easy to use. That meant sidestepping the whole web components debate, focusing mostly on CSS, and ensuring that our documentation was clear and friendly.”
Ellis Capon seems to confirm this cultural shift by saying that, “it also helped with establishing more of a culture, as now we have to be more careful about what goes into the system, so we have set up a cross-business unit ‘design system working group’ who decide on what ascends to the core system.”
This pressure to publish your design system is an excellent way to create a good dynamic. It sets a certain level of expectations that will force you to have a solid design system. Ultimately, not publishing your design system may even lower your standards and negatively impact your products.
Recruitment
This is probably the most practical reason for making your design system public. Showcasing modern digital best practices is an industry-wide recruiting trend. Designers, developers, and people in other disciplines want to work for organizations that leverage cutting-edge best practices. This will help you recruit by promoting values that motivate like-minded individuals should join your company. For this reason, you should publish design systems so you can attract top-notch individuals with the same shared passion as you and your organization. It goes without saying that if you are recruiting directly for your design system team, making your design system public makes even more sense.
Brad Frost also refers to his Styleguide Podcast explaining that almost every guest mentioned how helpful having a public design system was for attracting talent. He takes Jina Anne’s example who went to work at Salesforce and helped creating the famous Lightning Design System after seeing their Salesforce1 style guide:
“When I saw [Salesforce’s style guide] I thought it was beautiful and it’s why I wanted to join this team.”
All that means having a public design system makes your organization more competitive, not less.
Community
The community aspect is often forgotten when it comes to opening your design system. Yet, it can be very powerful for growing your design system and improving it.
Publishing your documentation and/or source code opens the door to external contributions, whether as simple feedback comments or direct contributions to the code. The downside is that you might incur overhead if your system becomes popular, but the advantage is getting feedback and insight from a wider range of people.
Moreover, from a more ethical point of view, you can also consider it a fair trade-off to give back to the community all that you have been able to enjoy for years thanks to Open Source, W3C, Material and all the different resources around design and software engineering.
Consider this as your small contribution to this vast and exciting world of free software, without which you would not have been able to build everything you have today.
By sharing more public design systems, you’re contributing to increasing community skills: we learn from each other, inspire, and share solutions.
How to make your design system public?
The answer to this isn’t one-size-fits-all, it should be based on your team’s preference. Making a system public doesn’t have to be all-or-nothing; there are various ways to break it down and determine what’s public.
Multiple versions of “public”
Sharing your design system publicly doesn’t mean you have to be completely open and transparent. You can also choose what you show and what you want to keep private. Invision’s Design Better Handbook has an interesting vision about how granular a design system can be public:
- Public documentation only
Sometimes, you might not want your source code public, but you do want your documentation public. Here we talk about an accessible reference site, but the code itself is hidden. - Open-source design systems
Besides being public, the code can also be requested for feature requests and contributed to (at the maintainers’ discretion).
There are several open-source design systems on GitHub, including the US Web Standards, Patternfly, Buzzfeed’s Solid and GitHub’s Primer (obviously).
Vitamin by Decathlon is also a great open-source example made with zeroheight. You can download their UI libraries on their Figma Community page and their workflow is publicly available on their GitHub Board. - Open-source documentation
Here, changing and contributing only to the documentation is allowed, but not to the design system code. You could publish the docs via GitHub pages. The documentation on GitHub can be shared this way easily. You don’t even need to create a crafted documentation website. You just need to write a markdown and GitHub will handle it. - Downloadable
Typically, the code is downloaded as a .zip file, which is different from the version the maintainer actually uses. This will allow you to keep the source code and the npm packages private. Using this option may be a good option if you don’t wish to make in-progress work public on your system, or add the burden of managing open-source contributions, but are still willing to share the code for others to use. Lab by Compositor, for example, uses the releases feature on GitHub to share release notes and .zip files for their software. Additionally, the repository is used to host documentation and user issues. - Publish the component library
A read-only version of your component library could be published to a URL that could be accessed by all users.
Other tools provide documentation and code examples like Storybook including Brad Frost’s Pattern Lab, Fractal, and React styleguidist. You can use all of these tools without sharing your design system’s source code, and you get to choose the level of documentation you want to share.
Because there isn’t just one way to give access to your design system, zeroheight offers multiple ways to control your design system’s access.
You have different levels of security to restrict your design system’s access such as password or SSO. But you may also need a more precise security level and don’t want to lock your whole styleguide; it is then possible with zeroheight to restrict access to only some specific pages to get the right version of “public” that fits your design system.
Check out our security documentation if you want to know more.
Show the right examples
Another argument you can use is showing all of the other brands that already have a public design system. Maybe even some of your competitors have one?
Many pioneering teams have developed and published beautifully designed documentation in the past decade, such as Google’s Material Design, Salesforce’s Lightning Design System, IBM’s Carbon Design System, Adobe’s Spectrum or Shopify’s Polaris.
If you need to get more inspiring examples, you can check Adele by UX Pin and Design Systems Repo to find great design systems references. But be careful with your examples; you shouldn’t assume that the solution that worked for one company will be right for everyone. For instance, companies like Google, Salesforce or Shopify invest a lot in design systems as their broader goal is to encourage external developers to build on their platforms using these systems. Pick the right ones that match your company’s business, size or area if you want to get impactful arguments.
Use the organization’s goals to your advantage
You, your team or even your boss probably have some goals to achieve for this year or later. Whether you are based on OKR, OGSM or Hoshin Kanri strategy methodologies, there are certainly some goals that you can use to your advantage. Maybe it’s about hiring X new designers/developers, representing the company on the outside or getting more involved with third parties or partnerships. You can even consider using your annual review to define new goals that match with your design system. For instance, you can say you aim to get X downloads for your UI library, have X different teams using the design system by the end of the year or X regular views. Moreover, it’d be a smart way to start measuring your design system.
So, should I make my design system public?
The short answer is yes.
The more nuanced answer is that you should define what public means to you and what could be beneficial to share at your company level, your team level, and even yourself. You can get many benefits and rewards by sharing it publicly. Just ask yourself what you want to improve at your company: new business opportunities, hiring new talents, leveling up your design culture, increasing your visibility…
Find what your current needs are and you’ll know what you’ll need to share from your design system to help you get it.