The Equinor Design System (EDS) serves many product teams, but the order in which components got built was not grounded in evidence of what teams actually needed or used. I designed a repeatable framework that turns three independent signals into a defensible priority list, and built the analysis tooling for it in Node with Claude Code.
Build order was decided by opinion rather than data. The goal was a repeatable, data-driven way to prioritize which components to build next.
The demand signal was also noisy: issues filed by the internal design-system team were mixed in with issues from the product teams the system is meant to serve, which obscured genuine external need. And in production files, designers were copy-pasting "shadow components" instead of using the library, while some components looked "missing" only because they existed under a different name.
Rather than trust any single source, the framework combines three, each answering a different question:
Demand: GitHub issues filed against the design system, what teams are asking for.
Supply: the Figma component library, what already exists.
Usage: production design files, what designers actually build with, including the shadow components they rebuild by hand.
Across 500 analyzed issues, the framework segments internal design-system-team issues from product-team issues (366, or 73%, internal versus 134, or 27%, from product teams) so prioritization tracks genuine external demand rather than the team's own backlog.
Inventorying 924 Figma components surfaced a key insight: many components that appeared to be "missing" actually existed under a different name. Cross-referencing the library against demand reframed several gaps as a naming problem, not an absence. Components teams thought they lacked were already there, findable once the vocabularies were aligned.
The Phase 1 analysis ranked product-team demand by mentions and bug load. Highest-demand components (mentions / bugs):
I designed the framework itself (the three-signal model, the weighted formula, and the internal-versus-product-team segmentation) and authored the written protocol so it could be re-run. I built the analysis tooling in Node with Claude Code (the scripts that pull GitHub issues, inventory the Figma library, and combine the signals). This is design work that reaches into its own tooling rather than stopping at a recommendation.
Phases 1 and 2 (demand analysis and the 924-component Figma inventory) are complete. Phase 3 (a full scoring matrix) and Phase 4 (automation and a dashboard) are planned.
A baseline of 237 EDS instances was captured at the framework's creation as the reference point for future measurement. The framework's growth figures (thousands of instances, dozens of components, and adoption percentages) are defined as 6- and 12-month targets, not measured outcomes. Whether the findings have since reshaped the roadmap has not yet been measured; re-running the analysis against the 237 baseline is the intended next step.