Productize Your Design System

I'm trying to write at least once a month, so I figured I'd try a slightly different format for this topic to save myself some time. I decided to have a little more fun with it and it's a bit more loose than usual. Let me know what you think!

Productize it. That's probably the most important piece of advice I'd offer to a team or individual starting a design system today. This goes for both startups and large organizations. You may be wondering "but why"?

A gif of Ryan Reynolds asking 'but why?'.

If the design system is a side project, it'll never reach its full potential. Instead, it could quickly become a burden, rather than being a jump start for designers and engineers.

Too many times at places both big and small, I've seen design systems start out as a grassroots effort. A couple of individuals (it's me, hi, I'm the problem it's me) get really excited about building one, so we go off and begin chasing our dreams (don't let your dreams be dreams). I don't think being a grassroots effort is a bad thing necessarily. People don't always understand the value of something until it's tangible. Simply speaking about the benefits without proof isn't enough. So you do what you must: make something tangible.

There's a lot to be said about building something and letting folks get their hands on it. It's even better when you convert people who are skeptical about your project by showing them how much your solution brings them value on a day-to-day basis.

"Oh, I don't have to build all of these components myself? I can slap these existing elements together to build a feature? Far out!".

That's been my experience building design systems full time since 2017. Sometimes discussing the advantages isn't the same as someone experiencing it for themselves - and that's okay! In fact, I think being able to prove your thing does what you said it would is extremely important. It's how you build credibility and trust with others.

At some point you need buy-in from leadership to ensure the design system remains successful. Otherwise you'll find yourself getting swamped with feature work and never have time to maintain, improve, or further develop the design system. This means you and your pals who were previously very excited about the design system end up becoming stressed due to needing to ship things elsewhere and no longer having the time to work on it. This is the danger zone when it comes to side projects. We can fix this though! Pitch your design system as a real product.

Not sure how to get leadership buy-in? Design Systems University has you covered with a slide deck. I was actually sent this a day or two ago as I began writing this article. Great timing!

The Drake no/yes meme with the text for Drake No as 'building your design system as a side project' and the Drake Yes as 'building your design system as a product'.

What will productizing get you? Sustainability, stability, and focus. Pitch your design system as a real product, because it is! Your customers are your internal users and team members. Your job as a design system contributor is to make design and engineering lives easier. You provide the Lego building blocks and your "customers" construct a feature or product. There's a ton of value in that - you are helping the organization ship faster, at a high quality bar. It also means you can hunker down and focus, rather than bouncing around between completely different concepts.

By productizing your design system, it means you'll also have the opportunity to form a real team around it. To me, an ideal team looks something like the following, which is pretty similar to the Design System University recommendation with a few minor tweaks:

  • Engineering Manager
    • Frontend Engineers
  • Design Manager
    • Designers
  • Accessibility Expert(s)
    • For both Design + Engineering
  • QA folks
  • Researcher(s) / Producer(s)
  • Content Writer(s)
  • Product Owner

Looks familiar, eh? One might say, it looks similar to a product team - because it is!

By having a real, dedicated team it means the design system can flourish. Bugs can be addressed in a timely manner rather than being thrown into an abyss that never gets looked at. New features can be added to the design system, which further improves the lives of the people using it. Components can be properly documented and given the time and care they deserve, rather than pumping something out as fast as possible due to a deadline. Researchers can help provide data-driven metrics on your design system and patterns in your products to help ensure you're making the correct decisions. Your applications will have visual UI/UX consistency. The list goes on and on.

That's my 2 cents on the topic! Productize it. Have a good one and see you next time! I've started my next article which will be about measuring success in design systems.