The Shared Language Your Team Is Missing
Most design libraries fail quietly. They launch with a burst of enthusiasm—a polished Sketch file, a Figma project with neatly named components, maybe even a developer handoff doc. Six months later, the buttons have five padding variants, nobody knows which card style is current, and the documentation reads like an archaeological record of good intentions.
I’ve watched this happen inside product teams, agencies, and in-house studios. The problem is rarely the tools. Figma, Storybook, and Zeroheight all do what they say on the tin. The problem is that we build libraries as final artifacts instead of living systems that fit how people actually work.
A design library that gets used is not a collection of components. It is a shared language that reduces the cognitive cost of making consistent interfaces. When a developer grabs a button and knows it will behave correctly across states without a Slack thread, or when a junior designer ships a form that matches the visual rhythm of the rest of the product without needing a critic, the library has earned its place.
Start with the Work, Not the Widget
Too many library projects begin with an audit of every UI element in the product. That produces an inventory, not a system. An inventory tells you what exists. A system tells you what should exist and how it relates to the tasks people perform.
Instead of cataloging all 47 button styles, sit with the people who build features. Watch a developer implement a typical screen. Note where they stop to ask a designer for a decision. Observe which components cause the most rework during QA. Those friction points are your library’s real requirements.
Hans Krell, the persona behind this blog’s voice, approaches engineering challenges by tracing the physical path of a signal or a load. I do the same with design systems: trace the path of a design decision from concept to shipped code. Where does it get blocked, misinterpreted, or silently overwritten? That’s where the library needs to intervene.
Name Things for Recognition, Not Classification
Naming is the quiet killer of adoption. A component called ModuleCardHorizontalWithThumbnail might be technically accurate, but it forces everyone to learn a taxonomy before they can find anything. People don’t search for a “ModuleCardHorizontalWithThumbnail.” They search for “the card we use on the dashboard.”
Name components by what a person would call them in conversation. DashboardCard, UserAvatar, PricingTable. Use the language of the domain, not the language of the DOM. If your team says “the hero banner” during standup, call it HeroBanner in the library. Alignment between spoken vocabulary and library vocabulary removes the translation step that makes people abandon the system.
This principle extends to variants and properties. A property named variant with values like primary, secondary, and ghost is easier to recall than a Boolean called isOutlined that interacts unpredictably with another Boolean called isElevated. Reduce the mental model to the fewest concepts that cover the real use cases.
Ship Small, Ship Often, Ship With Evidence
There is a temptation to wait until the library feels complete before releasing it. Resist that. A library that takes nine months to ship will be out of date on day one. The product has moved on, the team has built workarounds, and the library becomes a compliance burden rather than a productivity tool.
Release the library with exactly three components that solve a current pain point. Maybe it’s the form inputs that cause accessibility bugs in every sprint. Maybe it’s the modal that gets rebuilt from scratch on three different pages. Ship those three, instrument them, and measure whether they actually reduce rework or speed up implementation.
Instrumentation does not need to be complex. A simple tally of how many times a component is inserted from the library versus built from scratch tells you whether adoption is happening. If the library version of a modal is used 12 times in a month and the hand-built version appears 40 times, you have a signal. Either the library component does not meet the need, or nobody knows it exists.
Make the Library the Path of Least Resistance
Every extra step between “I need a component” and “I am using the component” is a place where people will invent their own solution. If the designer has to export assets from a separate file, they will copy-paste from another screen. If the developer has to read a wiki page before importing the right package, they will write a quick inline style.
Integrate the library into the tools people already inhabit. For designers, that means the Figma file should be the source of truth they work in, not a reference they consult. Turn on library publishing so components appear in the Assets panel. For developers, the component code should live in the same repository as the product, with clear import paths and a Storybook that runs locally.
Documentation matters, but it should be as close to the component as possible. A prop table and a one-line description inside the code file or the Figma component description field will be read more often than a dedicated docs site. If you do build a docs site, make sure the answer to “How do I use this?” appears above the fold and includes a copyable code snippet.
Governance Without Gatekeeping
A library that nobody can change becomes a museum. A library that anyone can change becomes a mess. The middle path is a lightweight contribution process that welcomes additions while keeping the system coherent.
Set clear criteria for what belongs in the library: used in three or more places is a good starting threshold. A component that appears once is a snowflake; a component that appears five times is a pattern worth codifying. Require a short proposal before any new component is added—one paragraph describing the use case and why existing components do not cover it. That filters out most one-off requests without blocking genuine needs.
Assign a steward, not an owner. A steward reviews proposals, helps contributors follow conventions, and makes sure changes don’t break existing usage. A steward is approachable and sits within the product team, not in a separate architecture group. The role is about enabling, not guarding.
Testing the Library Against Reality
Components that look right in isolation often break when composed into real screens. A card component with generous padding might look elegant alone but overflow a dashboard grid. An input field with a fixed width might fail when a label gets translated into German.
Test the library in context. Build a reference screen that combines multiple components at realistic data volumes. Run that screen through the same QA checklist the product uses. Check it on a phone, on a large monitor, with screen zoom at 200%, with keyboard navigation. The bugs you find will reveal gaps in the library’s API or its assumptions about content.
This is where the engineering mindset pays off. Think of the library as a set of materials with known tolerances. A steel beam has a load rating; a button component has a maximum label length before it wraps. Document those tolerances. When someone pushes past them, the library should either handle the stress gracefully or clearly indicate that it cannot.
Retiring Components Without Breaking Trust
Components age. A design direction shifts, a platform constraint changes, or a pattern turns out to be less accessible than intended. Removing a component from the library is a breaking change for every screen that uses it, and teams will resist that change if it creates rework.
Deprecate before you delete. Mark the component as deprecated with a note pointing to the replacement. Keep it functional for a defined migration window—one or two sprints is usually enough. After the window closes, remove the component and let the build process flag any remaining instances as errors. That gives teams a concrete deadline and a clear path forward, rather than a surprise on Monday morning.
Communication is the hard part here. A deprecated component notification that lives only in a changelog will be missed. Send a direct message in the team channel, tag the screens that still use the old component if your tooling allows it, and offer to pair with anyone who needs help migrating.
Measuring What Matters
Adoption metrics are useful, but they are a lagging indicator. By the time you see a usage graph trending down, the library has already lost relevance. Lead indicators are more actionable: the number of support questions about a component, the time it takes a new hire to ship their first UI change, the count of visual inconsistencies caught in code review.
Set up a lightweight feedback loop. Every quarter, ask five people who use the library a single question: “What’s the one thing that slowed you down this month that the library could have prevented?” The answers will tell you what to build next more reliably than any roadmap exercise.
Frequently Asked Questions
How small can a design library start and still be useful?
A library with three well-chosen components—say, a button, a text input, and a typography scale—can prevent more inconsistency than a library with 50 half-baked ones. Start with the components that cause the most rework or the most accessibility defects. Add new components only when they meet the threshold of being used in three or more places.
Should the library live in the designer’s tool or in code?
Both, and they must stay synchronized. The design file is the source of truth for visual properties, states, and behavior specifications. The code repository is the source of truth for the implemented component. A mismatch between the two is a bug. Use the same naming conventions in both environments so designers and developers can reference the same component without translation.
What if the product team keeps building custom components instead of using the library?
This is almost always a signal that the library component does not solve their actual problem. It might be missing a necessary variant, it might be too rigid, or they might not know it exists. Pair with one team to understand what they need. Fix the library component based on that conversation, then show them the result. Adoption spreads through demonstrated usefulness, not through mandates.