Building Design Systems That Teams Actually Adopt

I've built two design systems and used three others. The failure mode is almost always the same: a small team builds a beautiful component library, publishes it to npm, announces it in a company all-hands, and then watches adoption plateau at 30%.

The problem is never the components. The components are usually well-built and well-documented. The problem is that the design system team optimized for completeness instead of adoption. They built 50 components when the consuming teams needed 12 really good ones.

At CARS24, I audited our codebase before building a single component. I ran a script that counted how many times each UI pattern appeared across our product. Buttons appeared 847 times. Cards appeared 312 times. Modals appeared 156 times. Custom date pickers appeared 3 times.

We built the top 15 components first and shipped them as an npm package. Within two weeks, adoption hit 70% because we'd built exactly what teams needed. The remaining 50 components we'd originally planned? Most of them never got built because they weren't needed.

The lesson: a design system is a product, and like any product, you should start with the highest-impact features. Don't build a date picker until someone asks for one.

At Flipkart, the design system's success was directly proportional to how easy it was to use. We obsessed over the API surface. Every component had sensible defaults, clear prop names, and TypeScript definitions. You could render a functional button with a single prop: label.

We maintained a Storybook instance with interactive examples for every component and variant. But more importantly, we added a 'Copy Code' button to every story that gave you a ready-to-paste snippet. This reduced the friction from seeing an example to using it in your code to approximately five seconds.

Documentation is necessary but not sufficient. What matters is the time from 'I need a component' to 'it's working in my code.' Every minute of that journey that you can eliminate is a minute where an engineer isn't tempted to build their own version.

The CARS24 design system used semantic versioning with a strict policy: no breaking changes in minor or patch releases. Every breaking change required a major version bump, a migration guide, and a two-sprint deprecation window.

We also maintained two major versions simultaneously — the current version and the previous one. This gave teams time to migrate without being blocked. The cost was maintaining two versions, but the alternative — forcing immediate migration — would have killed adoption.

One thing I'd do differently: codemods. At Flipkart, we ship automated codemods for every breaking change. You run a script, it updates your imports and prop names, and you're done. This reduced the migration cost from hours to minutes and made teams far more willing to stay on the latest version.

You can't improve what you don't measure. We tracked three metrics for the CARS24 design system: adoption rate (percentage of UI elements using design system components), consistency score (how many custom one-off components exist that duplicate design system functionality), and developer satisfaction (quarterly survey).

The consistency score was the most actionable metric. When it started creeping up, it meant teams were building custom components instead of using the design system. That was our signal to investigate — sometimes the design system was missing a variant, sometimes the documentation was unclear, and sometimes a team just didn't know the component existed.

We published these metrics monthly in an internal newsletter. Visibility created accountability, and teams started taking pride in high adoption scores. Gamification works, even for engineers.

The biggest mistake companies make with design systems is treating them as a side project. You need dedicated engineers — at least two full-time — to maintain a design system. At CARS24, we started with one engineer dedicating 20% of their time, and the result was predictable: slow progress, outdated docs, and declining trust from consuming teams.

At Flipkart, we have a dedicated design systems team of four engineers and two designers. They treat the design system like a product with a roadmap, sprint planning, and stakeholder reviews. The difference in quality and adoption is night and day.

If you can't dedicate full-time engineers to a design system, you're not ready for one. Use a third-party library like Radix or Shadcn and customize it. A well-configured third-party library is better than a half-maintained internal one.