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.
- 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
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.