Design Systems Aren't Cheap
Tags: designsystems, webcomponents, css, javascript
Published: 2022-03-21 14:54:00

Buttons are one of my favorite components. On the surface they seem simple, but in practice, they tend to be much more involved. In a post by Nathan Curtis entitled [And you thought buttons were easy?](https://medium.com/eightshapes-llc/and-you-thought-buttons-were-easy-26eb5b5c1871), he demonstrates how costs can quickly skyrocket to $1,000,000 when one arm of the organization isn't aware of what the other is doing.

This is easy to brush off as an extreme example that only applies to really large companies. But how much does a design system actually cost?

## A Real Life Example

Before joining Microsoft, I did a short stint at a company with more than 10,000 employees. I was on a dedicated design system team that included five engineers, four designers, and two design technologists. Over the course of 12 months, they had built about 30 components for their design system.

Many of those positions paid six figure salaries, and that doesn't account for benefits and HR costs. Let's pretend the average salary for each position was only $100K USD. That's 11 <abbr title="Full Time Employees">FTEs</abbr> working for a year, _totaling $1.1M in salaries_. Again, this doesn't include stock grants, health insurance, and additional benefits.

All that to build buttons, dialogs, form controls, tabs — nothing proprietary. Just every day components that have been built many, many times before.

## The Cost of Frameworks

I forgot to mention that the components they were building were for React, which means that only React teams can use them. As a result, either the entire company must agree to use React or non-React teams will have to duplicate effort by building the same thing in _their_ framework, running the price up even higher.

In large orgs, these costs tend to fly under the radar, but they're tangible expenses if you know where to look.

Many design system teams I've spoken with are rebuilding or preparing to rebuild "legacy" design systems. The story usually goes something like "we're phasing out Angular 1.x" or "we're evolving from a Bootstrap-like design system."

And a lot of them want to build in React.

This leads to more costs that aren't being realized. Just like jQuery dominated the front end yesterday, React dominates it today. There will be something new that dominates it tomorrow. Your design system team will continue doing the same work and incurring more and more costs to keep up with framework churn. And let's not forget the cost of updating tomorrow's legacy apps, who are consumers of your soon to be legacy design system.

## The Platform Outlives Frameworks

A modern design system's component library — the foundational elements from which all your apps are built — are excellent candidates for [Web Components](https://developer.mozilla.org/en-US/docs/Web/Web_Components): a standard technology that's built into all modern browsers. Web components are used by [some of the world's largest companies](https://arewebcomponentsathingyet.com/), including Adobe, Amazon, Apple, Ford, GM, Google, Microsoft, NASA, Salesforce, SpaceX, Visa, and many, many more.*

If you care about longevity and cost, the platform is simply a more logical choice because browsers have committed to supporting Web Components for a long time.

It's astonishing to me that so many engineers fail to see that doing the same work over and over again isn't productive nor cost effective. How many times do you have to rebuild a button before you think "maybe this isn't the best way forward?" Imagine how much more productive an organization could be if those design and engineering hours were spent elsewhere.

Now imagine if you didn't have to build all those portable UI primitives yourself. What if you could just apply some of your own styles and start building patterns and apps? 🤔

## Jump Starting Your Design System

Every design system is different, but how much would you save if you could kick things off with a solid set of accessible, well-tested components? Imagine _not_ spending $1,000,000 on buttons. Imagine jumping right in and building more useful components for your organization. Imagine telling your engineers to use whatever framework they want because it will work just fine with your design system.

That's one of the reasons I built [Shoelace](https://shoelace.style/), an open source web component library that serves as a design system starter kit.**

Shoelace solves real world problems by offering accessible, intuitive, and interoperable components that save teams and individuals tens of thousands of dollars or more. It's totally free, by the way, although [sponsorships are always welcome](https://github.com/sponsors/claviska).

There's no need to roll your own buttons anymore.

---

<small>

*There's a longstanding misconception that Web Components aren't ready for mainstream consumption. This is a stale argument that held more water many years ago when the standards were less mature. These days, companies such as Adobe are embracing Web Standards by [migrating flagship products to web components](https://web.dev/ps-on-the-web/). Web components aren't just ready for mainstream — they _are_ mainstream.

**One of my followers told me they didn't want to use a third-party library as a basis for their design system. I suggested they fork the project if they want to have complete control of it. Their reply was something like, "but then I have to maintain it myself!" That argument wasn't well thought out, because you'll still be maintaining it yourself if you build it from scratch!

</small>