Enabling Design System Observability Using Honeycomb

Enabling Design System Observability Using Honeycomb

4 Min. Read

At Honeycomb, we’re actively growing our design system, Lattice, to ensure accessibility, optimize performance, and establish consistent design patterns across our product. One metric we use to measure Lattice is the adoption of components across the product. Adoption is about understanding how, where, and why they’re being used. To address this, we’ve developed a tool that leverages Honeycomb to provide deeper design system observability, offering critical insights into Lattice’s adoption trends across our ecosystem.

Measuring adoption

As our team and product suite continue to grow, effectively measuring Lattice’s adoption has become increasingly complex. Traditional observability methods for design systems, such as static code analysis, often fall short when it comes to capturing real-world usage patterns in production. This limitation leaves critical questions unanswered—how consistently is Lattice adopted, and are its components being leveraged to their full potential? Without actionable insights, identifying gaps in adoption and opportunities for optimization becomes an ongoing challenge.

Traditional code-scanning tools focus on detecting whether a component is included in a file. Our automated tool goes a step further by monitoring the rendered UI in real-world environments. Instead of just identifying components in the codebase, it analyzes the live application, calculating the actual number of components rendered on each page. This approach provides unparalleled visibility into which components are most frequently used across the user interface, enabling teams to make data-driven decisions to optimize and scale Lattice effectively.


RUM can leave questions unanswered.
Honeycomb for Frontend Observability doesn’t.


Breakdown of how this works

Setup

  • Leverage Puppeteer to automate browser actions and simulate user interactions.
  • Navigate through targeted pages within the application to ensure comprehensive coverage.

Data collection

  • Capture and count all elements rendered on the page to establish a baseline.
  • Identify and count Lattice components specifically, using unique attributes.

Data transmission

  • Format the collected metrics into Honeycomb-compatible event structures.
  • Send the data to Honeycomb for visualization and analysis, enabling actionable insights into component adoption trends.

Why monitoring the live application matters

One of the goals of Lattice is to enhance accessibility across our product suite, and achieving this depends on widespread and effective adoption of its components. Static code analysis often provides an incomplete picture of how those components are actually used in production. 

For example, static analysis might reveal that a button component accounts for only 10% of elements used on page. However, when the UI is rendered, that same button could represent 50% of the elements on the page due to being rendered multiple times in a loop or dynamically generated content.

This gap in understanding can have significant implications for prioritizing accessibility improvements. If an accessibility violation is identified in the button component, static code analysis would fail to capture the full scope of its impact on the user experience. 

In contrast, monitoring the live application provides a more accurate view of how often and where the component appears, enabling teams to focus their efforts on fixing the most impactful issues first. By prioritizing the components that are most frequently used, we can ensure that all our component improvements deliver the greatest benefit to users.

Real-world monitoring is key

Real user monitoring empowers us to make data-driven decisions that are directly aligned with how users interact with our application, providing the clarity needed to drive meaningful change.

While this tool has aided in helping us understand Lattice’s adoption and usage, our approach to design system observability is constantly evolving. Stay tuned for more updates on how we’re using OpenTelemetry and Honeycomb for Frontend Observability to gain even richer insights into how our design system is used in real-world applications.

Don’t forget to share!
Grady Salzman

Grady Salzman

Senior Software Engineer

Grady is a Chicago-based Software Engineer who enjoys navigating front-end intricacies & crafting component libraries. Beyond the screen, Grady enjoys cobbling (shoemaking), training his English Springer Spaniel, and trying new food with family and friends.

Related posts