Skip to main content
Anna Schumacher
Component health dashboard with four metric cards (Overall 70%, Design 83%, Code 62%, Docs 57%) and a table listing components like Accordion and Alert with their scores.

Automating component health measurement

Creating a self-updating Component Health Dashboard powered by MCP-based checks that measure components against a set of defined component norms.

Company
Heineken
Timeline
2026
CHALLENGE
Growth exposed the limits of tightly built components.
Our original component set was built quickly to support immediate business needs and worked well at the time. But as the product ecosystem grew, this led to: πŸ‘Ž Increasing complexity πŸ‘Ž Structural constraints πŸ‘Ž Limited scalability πŸ‘Ž Frequent detachment πŸ‘Ž Lots of support requests This was especially true for our Product Card, which is the 2nd most used component in our ecosystem. Yet for something so fundamental, it was not designed with system-level scale in mind, so...
How might we create components that allow for greater flexibility for designers and developers to adapt to emerging use cases and ensure the system evolves into an enabler as our platforms grow?
APPROACH
Trying to fix what was already there would only recreate the same problem in a new shape.
So I stepped back, took a more holistic approach and started thinking… πŸ’­ What is a Product Card in our system? πŸ’­ What should the Design System define? πŸ’­ What should be left open by design? Just because it's not available in the Design System, doesn't mean it should be impossible to create. At this point the focus shifted from the Product Card itself to defining a generic Card that enables the composition of Product Cards.
SOLUTION
From static to smart: introducing a content-agnostic Card that separates structure from context.
To support scalable growth, the way Cards exist in our system was restructured. The core decision was architectural: separating the foundation from the product.
Card, Design System-owned πŸ‘‰ Content-agnostic πŸ‘‰ Accessible by default πŸ‘‰ Flexible within constraints
Product Card, Platform-owned πŸ‘‰ Layout variations πŸ‘‰ Business logic πŸ‘‰ Feature-specific behaviours
Now the Card defines the structure and quality, but makes no assumptions about any product logic.
Designed for composition and autonomy: defining less to build more with slots
With the use of flexible slots, each Product Card becomes a composition built on a shared foundation. βœ… Configurable layouts, safely to extend βœ… Endless options through structural building blocks βœ… Composition rules instead of fixed variations βœ… Accessible and performant by default The Design System evolved into an enablement layer that supports teams through structure rather than restriction.
IMPACT
Less repetitive manual auditing work
Better roadmap prioritisation based on real system health
Progress becomes measurable