Design Systems as Shared Product Language

Mariusz Ciesla
Nov 17, 2019 · 4 min read

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:

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. If you liked the post, you can support me by buying me a coffee ☕️.

(originally posted on my Ghost blog, photo: KML on Pexels)

The Startup

Medium's largest active publication, followed by +730K people. Follow to join our community.

Mariusz Ciesla

Written by

Design generalist, almost-a-developer, tinkerer. I break stuff a lot. Co-founded Lifetramp.com in a past life.

The Startup

Medium's largest active publication, followed by +730K people. Follow to join our community.

Mariusz Ciesla

Written by

Design generalist, almost-a-developer, tinkerer. I break stuff a lot. Co-founded Lifetramp.com in a past life.

The Startup

Medium's largest active publication, followed by +730K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store