2 min read
the documentation trap of design systems

most teams treat design system adoption like a knowledge problem
> write better docs
> add more examples
> build a Storybook
> make the component library easier to discover

the component library already has 200+ components. engineers aren't using them because they don't know they exist, right?
wrong. they know. they just don't care.

It's about incentives!!!
Engineers don't get promoted for using your component library. they get promoted for shipping features fast. And sometimes, building from scratch IS faster than:
> learning your 47 prop configurations
> debugging why the component doesn't work in their specific edge case
> waiting for the design systems team to approve their modification request
> getting blocked because the component they need doesn't exist yet

your process rewards feature velocity // your design system optimizes for consistency ->these goals are in direct conflict.

  • What actually works?
    Stripe's design systems team tracks "time saved by reuse" as a metric that feeds into performance reviews.
  • Shopify gives engineers a "component reuse bonus" in their performance evaluations.

some teams go the other way: every custom component requires a design review that takes 2 weeks. suddenly, using the existing component is the faster path.

I'm not saying either approach is right. i'm saying they both acknowledged the incentive mismatch and fixed it structurally, not with better docs. AI era has anyways solved for the documentation problem, the only friction is adoption.

do you see any other incentive/adoption structure that worked?