Rethinking Component Libraries

Part One | Redefining Value

Intro

This is the first of three articles discussing aspects of shared component libraries, whether in a design system context or otherwise. Specifically, we’ll look at how we define value, understanding cost, and how to build for the future. This article will focus on how we think about the value of a shared component library. I find the value of shared components is often misunderstood and misrepresented, and it deserves a bit of redefinition before we can talk about the other aspects.

Redefining Value

When folks describe the value of a shared component library, they often talk about a few common attributes: UI consistency, development speed, efficient prototyping, etc. Those are certainly valid outputs of a well-built component library, but they are also a bit short-sighted. Why? Because while reducing the cost of initial implementation is an important aspect of development, it only represents a fraction of the lifecycle of any successful product UI. If we were building static interfaces or the lifespan of a product was relatively short, initial speed and consistency would be the absolute measure of a component library’s value. But active product UIs are dynamic environments that change continuously as teams respond to user feedback, test out new features, and deprecate old ones.

design systems @workday