May 18, 2023

How are you going to pay for that?

Now that you’ve talked with the people who build products across your org, you’re probably starting to form a rough idea of what your design system needs are. But you must consider a key question:

How are you going to pay for that?

Let’s be honest. You’re probably not asking that question. If you’re a practitioner advocating for a design system, you probably already know their value. But stakeholders not involved in operations will be, rightly, doing some math in their head: the future promised value of a design system vs. the real today cost required to do the work.

This is why I advocated for a minimum viable product approach a few emails back. A good MVP usually involves a solid value proposition, a clearly defined scope, and quick feedback — stakeholders are trying to reduce risk as much as possible. This is also why I suggest attaching early design systems work to a project that’s already gotten sign-off. Less work to secure funding, and typically easier to prove value.

Here are a few talking points for discussing design systems value with a business-focused stakeholder:

• Solutions created by one team can easily be shared with other teams
• Components can have accessibility tests, increasing customer base and reducing legal - liability
• Components can be set up with unit tests, preventing errors and rework
• Components can standardize naming org-wide, reducing confusion and mistakes
• Documentation can be part of onboarding process, saving at least a week of "getting up-to-speed"
• A reference site can prevent teams from doing duplicate work or work that doesn't - match guidelines;
• A design system makes it faster to bring in vendors to build products for your company;
• More usable sites are proven to increase conversions;
• Inconsistent design increases support requests.

This is a big topic. Here are what some other folks have had to say about selling design systems:

• Nathan Curtis provides a simple formula of component build cost x number of digital products — when you consider design, dev, and testing and the cost of each person involved, this adds up quickly, especially for larger organizations. Though this approach can be a bit simplistic, It’s a useful heuristic, and it’s the one I use the most often.
• Maximilian Speicher & Guido Baena Wehrmann provide a more complicated formula that is filled with some assumptions (e.g. a design system is good for 5 years, it takes 6 months to build a design system) and feels too heavy to support the MVP approach I argue for, though their explanation may provide some good insight for what you should be thinking about.
• Ben Callahan takes an approach that’s less formula-heavy and more conceptual, and definitely worth the read if you’re trying to convince stakeholders on the value of design systems.
• Dan Mall takes a more persuasive approach — printing out designs across all products in order to communicate the inconsistency problem at scale to stakeholders.

A few more practical tips to consider:

• If teams are skeptical about the DS work, focus less on marketing your efforts and more on education and problem solving. When people see you solving real business needs, they’ll get interested quickly. Then you can come up with a cool name and some marketing behind the work you’re doing.
• If you’re not in leadership, find a sponsor in leadership than can advocate for your design systems work;
• Incorporating design systems into legacy products is always a hard sell as they only usually get maintenance funding. But they’re often still used by a considerable number of users. Make the case for de-risking ongoing maintenance, especially for parts of the app that may get updated frequently (like brand colors or a global site header or footer lockup that get updated frequently);
• Can’t get funding? Build your next product in such a way that parts of it could benefit other teams, if it were integrated (like a standalone repo of color variables, or components common to other products pulled out into a separate library, etc.)

As I said, this is a big topic. If you've got any questions or can't seem to get support for design systems work at your organization, let me know.

—
Cheers,

Up Next: Discount design systems…

← Full Archives