Prioritizing work in your Enterprise Design System

You've got a backlog overflowing with requests. Different teams from across the business are asking you to build enhancements to components in the library or maybe even create brand new components. You're team is small, scrappy, and most definitely can't handle all the requests. How do you wade through the noise and find the work that matters? This post aims to guide you in that.

Determine your batting order

1. Product-led Growth
2. Pattern Asset Libraries
3. Product teams

At IBM, we're a hybrid cloud and AI company, which means that the business has determined that in order to win, we need to position our software in such a way that leans into Product-led Growth. I care about these products the most. I know that if I do right by them and the teams that support them, I will position our design system to make the greatest impact for the business and with any luck, business will good.

Next on the priority list, is our Pattern Asset Libraries, or PALs for short. These teams are the local systems of Carbon that drive our design system into their respective line of business.

As a maintainer of the Core components, if I can prioritize work that directly improves the quality of life for a PAL, that gives me a huge splash zone of products that we will have an impact on, thus making it worth our time and energy.

Lastly, is individual product teams, both internal and external. Unfortunately, not every product building with Carbon, is slated for Product-led Growth. We also have products that are being built, that don't rely on a PAL for bespoke patterns and components in their part of the business. These products and teams are the last on our priority list.

Tickets, please!

The life-cycle of an enhancement to the design system begins and ends with it's corresponding issue that has been created against it.

This touchpoint with your community of makers is a critical one and you'll want to make sure that your issue template reflects as such. Here are the prompts you'll want to have in your template:

• The problem - Provide a clear and concise description of what the problem this new feature is trying to solve.
• The solution - Provide a clear and concise description of what you would like to happen instead.
• Examples - Provide sample content, references, or audits of solutions solving the same problem in other applications/websites.
• Product - What application and/or PAL do you work on?
• Business priority - Self-assessed level of priority.

Here is Carbon’s issue template for enhancements. Feel free to copy it or make it your own.

Triaging requests

Ok, you’ve got your priority list, you have an issue template that makers can start drumming up issues against, now the backlog is starting to fill up, time to triage!

Have your team’s Product Manager (PM) create a standing meeting that happens once a sprint with everyone on the hook to deliver the design system, designers and developers alike. We call ours Backlog Cleaning. Use whatever language makes sense for your team based on your sprint rituals. It’s important that your PM runs this call. Have them go in for 30 minutes at some point before the meeting happens so they get a good idea of what kinds of requests are coming in. Often, you’ll find that the requests are very developer-centric, talking about how a random event handler does it’s job in React or something else. These kinds of discussions are great for your developers, but wasteful for your designers. The opposite can also be true. Use your team’s time wisely.

Here are the questions your PM should be asking as you make your way through the Backlog:

• Does this request align with our principles for what it means to be in the core components of the design system?
• Should this request live with one of the PALs? (local systems)
• Can they implement this as is, with a little customization on their end?
• Is this a good candidate for a community-driven contribution?

This line of questioning does wonders for sussing out what is truly a priority and what your team should be taking on. Remember, as the Product Manager, it’s the responsibility of the people making requests to convince you to say “YES”. And it’s your responsibility as the Product Manager to weigh that YES against all of your other competing priorities.

Clear, concise, & consistent

Prioritizing work for your design system can feel like a daunting task because being in the design system space can often feel like we’re constantly boiling oceans. At the end of the day, most makers building with your design system want transparency and communication. Anything you do that delivers on clear, concise, and consistent messaging will build strong bonds with your community and beyond.