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 tool 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 than whatever else is out there or even what you initially thought, depending on what your team needs. 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 and slide decks for product management. Your overarching goal should be to simplify and streamline design across the company and you should definitely start with interviewing all the stakeholders, scoping out the requirements and coming up with a plan how to satisfy your “customers”. The most important thing to remember is that you should not be building your design system to benefit only designers which means sometimes you'll have to include things you or your team disagree with. If you ignore that fact, you're setting yourself up for failure.

Examples of non-obvious artifacts that I've built or seen built and maintained as part of company-centric design system effort include:

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.

(photo: KML / Pexels)