I've built design systems for years. When engineering teams asked about progress, I'd say "we have 52 components ready." They'd ask when they could use them, and I'd walk them to Figma. Then they'd start building features and realize most components weren't in their codebase yet.
I was answering a different question than they were asking. I counted what existed. They needed to know what they could import and use today. The gap between those two numbers is where planning breaks down.
An MBA course on process costing gave me language for this. Manufacturers don't count half-finished work the same as completed work. A gallon of paint that's 40 percent mixed isn't a gallon. It's 0.4 gallons of equivalent completed output. They measure partial work this way because it affects cost per unit, inventory value, and capacity planning.
Design systems have the same problem. A component in Figma isn't the same as a component in the repo. But we count them identically and then wonder why engineering teams can't use half of what we say we shipped.
So I'd weight components by completion stage now. Built in Figma means 25 percent complete. Add documentation and it's 50 percent. Publish to Storybook makes it 75 percent. Integrated into the product codebase where engineers can actually import it? That's 100 percent.
Those 52 components become maybe 28 fully usable components when you measure this way. That's the number engineering teams care about. That's what they can build with today.
Stop celebrating partial work
I'd stop celebrating components that aren't integrated yet. A button that lives in Storybook but not in the main repo is three-quarters done. It's not shipped. It's not usable. I used to treat Storybook publication as the finish line. I'd now treat codebase integration as the finish line.
Plan roadmaps around weighted complexity
I'd plan roadmaps around weighted complexity instead of component count. A button takes two weeks. A data table takes two months. Saying we'll ship ten components next quarter is meaningless when component complexity varies by 10x. I'd now say we'll ship 15 equivalent units of work. Engineering teams can translate that into "three data tables or fifteen buttons" and plan accordingly.
Track velocity in equivalent units
I'd track velocity in equivalent units to make capacity predictable. Right now, I tell teams "we shipped eight components last quarter" and they have no idea if that pace continues. Were those eight buttons or eight complex form builders? I'd now say "we consistently ship 15 equivalent units per quarter." That's a number you can forecast with. That's a number engineering teams can factor into their feature timelines.
This isn't about measuring more things. It's about measuring the right thing. Engineering teams don't care how many components exist in Figma. They care how many components they can use without waiting for integration work.
The other benefit is it forces you to define what done means. Before, done was fuzzy. A component could be done in design but not in code. Done in Storybook but not in the repo. Done as a proof of concept but not production-ready. Weighting by completion stage makes you pick a definition and stick to it.
I'd still build design systems the same way. But I'd measure their value through engineering team readiness instead of component count. When teams ask what they can use, I'd give them a number that reflects actual availability, not theoretical inventory.
The shift is simple. Count what's usable, not what exists. Weight by completion, not by component. Measure output through the lens of the teams who depend on it. That's how you turn a design system into something engineering teams can plan around.