Keeping the design system tools you love during budget constraints

The tech world is no stranger to volatility, and when things get rocky, design teams are usually affected. The most common impacts involve budget cuts, frozen headcounts, team reorgs, and at worst, team layoffs. For people managing the budget (whether at the corporate level or within your organization), tool consolidation and elimination is an excellent option on paper. But the impact of losing your favorite design system tools (or any tool) that makes you and your team’s day-to-day life productive can far exceed the short-term benefit of eliminating the tool.

In this guide, we’ll focus on how you can keep the design system tools (or really any tool) your team loves when they face budget cuts. Before your team concedes and surrenders their favorite tools, there are a few things you can do, including

• Identifying other tools to cut instead
• Finding allies and partners
• Showing why other substitutions aren’t adequate
• Demonstrating the impact of not having the tool

We’ll go through each one of these and discuss why you want to try this, things to consider, and how to try it.

Identify other tools to cut instead

This is probably the most straightforward approach compared to the others we recommend. If you have a Design Program Manager or DesignOps person, collaborate with them on this effort. If they’re handling the tooling or budget for your team, they’ll have a lot of great insight regarding budgets, contracts, and renewals. By partnering with them, you can help provide context around the value of how you and your team use the design system tools.

Before looking at other tools, identify the cost of the tool you want to keep and see if there’s a budget goal. For example, if your tool is $10K/year, you might just have to find $10K worth of tools to get rid of. More realistically, Finance may reduce the budget to a certain amount, and all tooling expenses must fit within that amount.

1. List all the tools your team can access.

When creating this list, think about the tools the team uses daily. Your list should include tools specific to your team and shared across the broader organization. For example, the whole product team may use Jira and Confluence, not just the design org. Also, consider the tools the team used in the past – are you still paying for them? (e.g., Your team now uses Figma, but people still have full Adobe CC subscriptions.) 

2. See what tools the team doesn’t actively use that the team is paying for.

Check to see if you can eliminate them instead. Sometimes, the company has signed a contract and already paid for using those tools until the contract expires. If so, determine the renewal date and ensure the team doesn’t renew it. Regardless of how immediately you can stop paying for the tool, ensure you have a transition/migration plan. 

3. Look to see if people and teams are using similar tools worth consolidating.

For example, are some people using Notion, while others are using OneNote, and everyone uses Confluence for notetaking as well? Consider how the team can consolidate to using just one type of notetaking tool. An excellent option is to use a tool the company provides everyone (e.g., everyone has access to Confluence) because that might not come from your team’s budget. But before going with the cheapest option, consider which tool meets your team’s needs the most and how much effort exporting/importing data will take. You might keep a tool that costs more because it meets your team’s needs better. Depending on the tool, your team might be willing to make a few sacrifices for a notetaking tool if this means keeping one they love. However your consolidation shakes out, don’t forget to create a transition/migration plan for these tools. 

Consider if everyone needs access to the tools, and if they don’t, only pay for those that need subscriptions. For example, maybe not everyone needs a subscription to user research or video editing tools.

Find allies or partners to share the design system tools

Another option for covering the cost of a design system tool is splitting it amongst multiple teams/departments. For example, could you share zeroheight with your Brand and Marketing teams? They could be using other tools, and it’s an excellent opportunity to see if consolidating and using your tool makes the most sense. Depending on your organization’s structure, you may have other business units with design teams. If you’re not in contact with them, consider reaching out to see if you can partner with them on tool usage.

Show why other tool substitutions aren’t adequate for your design system tools

From a business perspective, any manager or leader will want employees to use the standard tools teams already have before using specialized tools. On the surface, it looks cost-effective to do so. But specialized design system tools, like zeroheight and Figma, provide efficiencies across product teams, which as design system creators, make them worth the investment. 

However, only some realize this and may even ask why not document in Word and design in PowerPoint. They might not go that far but may ask you to use other tools instead. While you can work with other tools, it doesn’t mean you should. (Check out our series on “Should you document in…”). But merely saying it’s not a good idea isn’t helpful. Leadership people are business people, and you must explain why other tools aren’t adequate.

This is an excellent opportunity to leverage your UX skills. Consider what stakeholders are most concerned with – budget, employee workload, ability to create impact, etc., and “design” your case around their concerns. Demonstrate how the design system tool you want to keep provides value toward achieving their or the business unit’s goals. 

Considerations to build your case

• Case studies similar to your situation to present data to support your case. We have a great one where Eventbrite shares how zeroheight saved them over a year in engineering effort!
• Articles that back your case – e.g., “What is the value of a design system?”
• Identifying how long it takes to do repetitive workflows – e.g., update a component, document designs, etc.
• Dependencies on other parties – e.g., if you document in Storybook, then only engineers can push changes)
• Limitations of the product – e.g., features, efficiencies, etc.
• Industry standards – i.e., design system tools that everyone uses to stay competitive in the field and to retain top talent

As you build your case, think of the information that will show the most impact. Does it mean estimating how long or how many people it takes someone to update things in both tools? Does it mean creating a flowchart of all the steps in accomplishing a task with both tools? Consider what kind of UX methods and diagrams you can create to demonstrate value tangibly. Leadership and stakeholders rarely use the tools we use daily, so sometimes it’s worth showing how awful or efficient a tool is.

If you’re unsure what would resonate well with decision-makers, ask around. People are usually willing to share ideas on how you might want to approach your case to make the most significant impact.

Demonstrate the impact of not having the design system tool

You can do this independently or with the previous approach. Sometimes the impact of not having the tool is enough to justify its necessity. With this, consider the “worst case scenario” of not having the design system tool:

• What would happen to the process?
• What would happen to team morale, and how will that affect retention?
• Would things get done, or will using an inadequate tool cause too much friction?
• Would more bottlenecks occur?
• What are other risks – inconsistency in the product, lack of customer trust, etc.?
• What was it like before you had the tool? Would things revert to that state?

While this seems like a great way to paint an apocalyptic picture, lean more on the realistic rather than the hyperbolic side. If you can, talk to other people in the design community (like zheroes) to see if anyone has experienced this or something similar. Share those anecdotes to help crystalize the reality.

Ready? Not so fast.

Okay, we have some additional caveats to share before you use some of these approaches.

First, this is an excellent opportunity for you to actively understand how budgeting works at your organization – at the team and org level and across the company. Most people don’t expect individual contributors to take a vested interest in how business operations work. They might feel like you’re butting heads because they’ve identified a budget, and you’re pushing back. So try and partner with them to learn how finances work, build empathy, and brainstorm solutions that work out for all parties involved. You’re essentially using your UX skills!

Next, try to be negotiable with solutions. I speak from experience. You can build the most robust case in the world to keep your team’s favorite tool and paint a vividly scary picture of life without it, but consider that your stakeholders might be okay with that outcome. I know it’s shocking to believe because things seem so obviously wrong!

Sometimes they’ll agree that your case makes sense in isolation. Still, they have to think about the other things they’re being held accountable for, which could be more serious or urgent, including things they can’t always be transparent about. If that’s the case, this also means they’re saying they understand the outcomes and how it’s not ideal but that the team has to be willing to roll with it, given the circumstances.

You may still be able to negotiate an alternative solution, or even better– you can provide an array of options. Based on those options, stakeholders can pick which option seems most viable for the moment.

You got this!

Okay, we hope you feel more empowered to advocate for your favorite design system tools. Let us know how this goes, even if it didn’t turn out how you wanted (we’re here to lend an ear!). 

Did we miss any approaches that others can take? Let us know so we can revise this article. Losing a tool you love is tough, and I’m sure the community would love to try things you’ve been successful with. You can share on zheroes, our Slack community.