Getting Executive Buy-In and Proving ROI of Design Systems

How do you prove the value and impact of design systems? How do you get executive buy-in? We answered these questions and more in our expert panel "Building a Business Case & Proving ROI for Design Systems" with industry leaders Josh Clark (Founder & Partner at Big Medium), Lauren LoPrete (Design Manager, Design System at Cash App), and PJ Onori (Senior Design Manager at Instacart).

If you missed the live panel, you can watch the recording from the discussion. We got a lot of audience questions that we weren’t able to answer during the talk, so we followed up with Lauren and PJ to get their insights.

Let’s dive in!

Q: What data do you typically provide to senior management to defend your need for more design budget?

Lauren: Its important to map your roadmap and vision to company level priorities. Make sure you’re flagging things in your budget request that are mission critical or high priority in the eyes of senior management. The other effective tool is looking at support ratios. Right now my team is roughly 1 systems designer : 60 systems consumers, and we’re in desperate need of more head count. 

PJ: Nothing too out of the ordinary. We align with leadership on the goals/milestones they’d like our team to meet and ask for budget to meet those goals in the desired time. I’m also typically trying to show how the investment will net positive in overall business value. Meaning, if you give us the budget to hire one X designer(s), we aim to increase efficiency within design that would equate to X+Y additional designers in the org.

Q: Adoption, efficiency, consistency are lagging metrics - the results pay off in the long term. Any tips for keeping execs ‘appeased’ when they want to see the ROI in the short term? In our case, we have an established design system (5+ years), so I like to think we’re shipping ongoing value in every new feature launch by product teams - but there’s always this push for more ‘quick wins’ by leadership. How do we better educate about the long-term and ongoing value of the system?

Lauren: In previous roles I’ve owned quant metrics based on user sentiment… I've tracked metrics around “meets my needs” “helps me work faster” and shared those with leadership. If you can tie those back to efficiency and quality, it can be quite effective.

‍PJ: That’s a continual challenge. One thing I try to do is sell the long-term value a design system can bring and then estimate how that value should grow over time. So, no, you’re not going to get 30% efficiency gains in year one. But perhaps you can get a 5% efficiency gain. Even that can be a great “quick win” for leadership.

‍Q: Should we consider adoption when discussing the ROI of a design system? If so, should adoption be measured based on component inserts or instances?

Lauren: The most effective way to get buy-in is to find the thing that your executive is either 1. Tired of hearing about, 2. Super passionate about. Position your message to them as “why should you care” and keep asking yourself “why” until you get to their vantage point and can sell the right story. Engerineering leaders probably aren’t super passionate about design cohesion, but they’re probably tired of hearing about eng velocity. It might feel tedious, but you essentially will have to draft a different version of your story for every leader, across disciplines and altitudes. 

PJ: One thing that’s worked for me is tying the case to some big redesign or design push that would create a major fire drill from an engineering point of view. Once there’s a clear understanding of how this kind of infrastructure can save months of engineering effort, the lightbulbs begin to turn on.

Q: Can you share examples where Speed/Efficiency might have provided more value over Quality/Craft and vice-versa… or where a balance was the best mix? What qualities were different at those organizations? In what ways were you able to shift those differences?

Lauren: It really depends on who the company is run by, and what they’re up against. If design has a seat at the table, and is trying to improve quality and craft, it's easy for design systems to piggyback on that message. If the company is engineering dominant, or struggling with velocity, speed/efficiency are the right ways to approach it. Hot take: I’ve never worked at Google, but you can tell as a consumer that they’re eng dominant, and care little about design craft/cohesion. For them, Design Systems is likely a story about velocity, over anything else.

I’ve been at companies where we had immense buy in from design executives to improve the quality and craft. Design Systems is just one of many ways we can improve quality and craft, but it can’t improve it alone. In those times, I’ve found the more challenging part is explaining what design systems can’t solve when it comes to quality, rather than how it can solve for it.

PJ: The more thought I put into this topic, the more I focus on efficiency because there’s a clear case for how efficiency can improve quality. I haven’t found the same in the opposite direction. Efficiency is great because it unlocks time. And time can be used however one wants. So if leadership wants to put more focus on quality, higher efficiency provides more time for teams to focus on it. That doesn’t mean it’s OK to ignore quality, but if I had to bias towards one, it would be efficiency.

Q: Often we don’t have the luxury of comparing feature team velocity or speed of delivery in a pre and post-design system world. Any tips on defining metrics that show real-time efficiency gains?

Lauren: I don't think you can have a metric here. A quantitative approach to velocity or speed is a waste of time in my opinion. A better approach is to leverage your consumers teams as case studies, celebrate the wins they’ve achieved by leveraging the system and showcase their work across the org and to executives. Your most passionate users will want others to reap the benefits of using the system.

‍PJ: Real-time efficiency gains? No - I don’t have an answer for you. But to be honest, I’ve yet to see anyone answer that question. However, I wouldn’t shy away from asking designers and engineers how much time they estimate the system saves them per week. There’s a good chance the numbers will be all over the place, but as an aggregate, it can provide a useful view. Especially if asked repeatedly over time to see how efficiency is trending.

Q: How can a design system contribute to organizational transitions, such as mergers or acquisitions?

Lauren: I was leading our team at Dropbox while we acquired several products, and have supported many acquisitions and rebrands. It's not a simple answer, and it depends on the terms of the acquisition but here are a few examples: If the newly acquired product is getting rebranded, and has an established design system, there is relatively low lift to remap tokens and modify core components to match the parent brand designs system. If the newly acquired product is getting merged into the parent product, a design system offers training, documentation, componentry, and patterns for the team to leverage in order to quickly integrate the acquired features.

Q: How do you think about the cost of design system support? My team wants to be very supportive of our users, but sometimes they just need to read the docs, and support consumes a decent chunk of our team's resources. How do you balance user-friendliness with efficiency of support delivery?

PJ: The way I like to pitch this is to explain how reading the docs ultimately is in their best interest. We loosely measured how much time/focus was being pulled into Slack support and how that ate into daily work. And we were able to make the case that we’re not able to improve the system as fast as we’d like because we’re answering questions that are in the docs. So if teams want new/improved components, the best thing they can do is read the docs and allow the system team to focus on making the system better.

Another approach is to inject acceptable, but uncomfortable friction. Meaning, you can institute SLAs for design system response times that are reasonable, but take long enough to make reading the docs the most convenient option. Sure, you can wait 24 hours for a response, or you can just go to the docs and get an answer in 5-10 minutes.

Q: How consciously do you involve yourselves in corporate politics?

PJ: I consciously involve myself as little as possible. A fully operational design system can wield a fearsome amount of sway. It’s something design system practitioners should be very, very aware of. And if you wield that sway like a jerk, things are going to get contentious/political quickly. So, I really try to avoid this by letting research, evidence and information drive decisions. We need to make it abundantly clear that we’re not a partisan organization - we’re here for the benefit of our customers.

Q: How have you made the case for other teams (beyond the core team) to allocate resources for designers and frontend developers to do design system work (e.g. upgrading their DS version, refactoring old components out of design files that are being updated)?

Lauren: Yes, on a per project basis. During migration efforts it's critical to get dedicated support from the product teams who use the system. You want them to have shared ownership in how the migration shakes out, and it's an effective way to get skin in the game.

PJ: Never. My focus is to get those resources directly on the team. In my experience, that’s been the best path towards success.

Q: Do you have any suggestions for integrating design systems/ops/QA into feature development before handoff and how to add this into the design process?

Lauren: I don’t have a perfect way of doing this, its always a delicate dance because you don’t want to slow down handoff or implementation. But if the system is used improperly, that can slow down implementation on its own. I believe that through regular touchpoints with your feature teams, via formal reviews (live or async), office hours, or support channels can be the best way to integrate design systems into your development workflow. Oftentimes people suggest heavy handed/overly processed ways of doing this, such as “design systems sign off” before implementation. In my experience, when that’s required, design systems become a bottleneck and spend their whole time checking boxes. I think the most effective way to integrate design systems into the feature development process is through early training and support. Make sure you’re a partner from the beginning and seen as a teacher/enabler rather than a checkpoint that they must pass before shipping. 

Q: How do we emphasize to execs the value and need of development within design system teams?

PJ: Design systems for software is software. I think it’s important to hit home that design systems are, in and of themselves, a software deliverable. Ain’t no software gets built without developers. 

A huge thank you to Lauren and PJ for answering the questions from our panel audience!

Presenting your business base for design systems to executive stakeholders? Use our presentation deck template so you don't have to start from scratch.