
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