In my daily practice I have noticed that design systems are often misunderstood, because they’re mostly not about design.  What starts as a mission to unify the design language across products  usually ends up a large cross-disciplinary initiative, or — in cases of  larger teams — a dedicated design tooling or design ops team.

This stems from the fact that most of the work when creating a good design system is making sure you’re building a language that creates shared understanding and shared language for product teams.  What good is a design system that nobody outside the dedicated design  team uses? Probably not good. Design systems, depending on dedication of  people leading the charge, tend to eventually end up in two places —  one is almost-useless artifact of design that has nothing to do with the  actual product development, the other is the ultimate tool for breaking the silos. What’s the difference between those two vastly different outcomes?

Design Systems as Products

In  the first case, the design team, while scaling, internally decides that  they need a tool to operationalize and simplify their work and starts  building sticker sheets, components, even elaborate style guides —  without involving the rest of the team.

This is a big mistake. What you should do instead is treat your system as a product for building other products,  with end users being the teams that are involved in daily development  of the product. Therefore, your solution might be vastly different  depending on the target group. You might end up creating design  libraries for design team, a custom front-end framework in partnership  with engineering or even templates for marketing and Omnigraffle  stickers for product management. If your overarching goal is to simplify  and streamline design language across the company, you should  definitely start with interviewing all the stakeholders, scoping out the  requirements and coming up with a plan how to satisfy your “customers”.  Examples of non-obvious artifacts that I’ve built or seen built and  maintained as part of company-centric design system effort include:

• illustration systems, templates and assets for marketing
• diagramming systems for engineering
• meta-layers of design tokens that are able to generate variables needed for many applications that the company has
• Visio & Omnigraffle sticker sheets
• Spreadsheet templates for finance
• plugins for different sort of applications used by teams that help them do it right
• IntelliSense suggestions for VS Code that help engineering choose the right components when building UI

You  should make sure you set an overarching, ambitious goal and a rough  path how to get there. As with every product, getting there will be a  process.

Marketing and Sales

Part  of every good product is getting it to your market. If your design  systems has all the frills but nobody uses it, you’ve failed — wasted  time and effort on creating something that doesn’t impact the bottom  line. How do you make sure this doesn’t happen?

• Run  workshops, explaining the benefits and showing people how to include  design system components in their daily process. Bonus points if you can  show proven productivity gains after switching to the design system
• Show progress early and often and build advocates within the teams that you want to switch to using your system
• Respond to feature requests and bugs, like a good customer success person would

Learn how to sell. You’re going to do a lot of selling.

Measuring the Success

Since  we’re treating our design system as a product, we should consider how  we’re measuring success. Every good product has a set of metrics that  can help the team track progress and design system shouldn’t be any  different. Those can be usage-centric, like adoption rate across all  teams within the company, or even user success-centric, like  time-to-market of new features using design sysmtem vs before using  design system. Some interesting metrics I’ve seen in the last couple of  years include:

• velocity  of product teams using design systems vs before using it — this ties  directly into productivity of the teams, that I mentioned earlier
• adoption rate across product teams, akin to monthly active users in a SaaS application
• amount  of UI-related engineering QA tickets — when you include design system  and standard components within your code, there’s a significant chance  that you’ll see a drop in inconsistencies and UI-related engineering  tickets
• NPS  & SUS — yes, really. You can definitely run surveys within teams  that use your design system and see how well it performs and how  satisfied people are with it.

TL;DR:

• Design systems should be considered products that are used to build other products and the customer is your product team
• Creating more design artifacts that don’t impact the larger team is largely a waste of resources
• As with any product, you should consider doing constant user research and gather requirements and requests
• Set goals, build problem-based roadmaps and take it one step at a time, adjusting as you go
• Come up with metrics that will help you see if you’re getting closer to your goal
• Enjoy!

That’s  it! If you’re working on a design ops or design systems team, I would  love to hear your feedback how you make sure you’re not a liability, but  an asset. If you have any tips, tricks or feedback, feel free to reach out on Twitter.