Building Cloudflare's First Data Visualization Design System

Overview

Led the consolidation of Cloudflare Analytics' fragmented visualization patterns into a scalable charting design system adopted across dashboards, products, and teams. Audited five existing design systems, identified behavioral and interaction inconsistencies, prioritized the highest-impact component, and established reusable standards for data visualization, accessibility, responsiveness, and localization.

• Audited 5 independent design systems across analytics experiences
• Standardized interaction patterns, chart behaviors, and accessibility specs
• Built 30+ reusable charting and supporting components
• Established scalable documentation and component specs for engineering handoff
• Drove adoption across 50+ engineering teams; bottoms-up momentum earned a top-down company-wide mandate, with every team required to adopt by Q1 2027
• Designers completed new dashboard designs ~50% faster; engineering adoption led to a significant reduction in QA for small UI issues

A Fragmented Visualization Ecosystem

Cloudflare's analytics ecosystem had evolved organically across multiple teams. By the time I joined the Design Systems team, there were five separate design systems in use across analytics experiences; each built independently, with no shared foundation, no consistent interaction patterns, and no unified approach to data visualization.

Without shared standards, each dashboard introduced its own filtering behaviors, visualization decisions, and interaction patterns. Designers repeatedly solved the same UX problems independently, creating inconsistent experiences for users and mounting technical debt for engineers.

The issue wasn't just visual; it was behavioral

Users couldn't rely on predictable interactions across analytics experiences, while teams lacked a shared foundation for building scalable products. Similar workflows behaved differently between products, forcing users to relearn patterns from dashboard to dashboard and increasing cognitive load at every context switch.

My Role at Cloudflare

I joined the Design Systems team specifically to address the fragmentation across analytics experiences. This was one chapter in a longer journey at Cloudflare, spanning nearly two years and multiple teams, but the design systems work was distinct: it required thinking at the system level, not the product level.

The Design Systems work (highlighted) was the foundation that informed all subsequent work across Platform, Zero Trust, and Security teams.

Discovery & Audit

Before designing anything, I needed to understand the full landscape of what existed; and what was broken. The audit drew on four distinct sources: customer feedback, support ticket analysis, frontend engineering interviews, and product interviews.

Audit categories

• UI Audit:chart types, color usage, spacing, typography, layout structures
• UX Audit:hover behaviors, drilldowns, filtering, sorting, empty and loading states
• Pattern Audit:legends, tooltips, section headers, date range pickers, filter structures
• Technical Audit:existing libraries, component duplication, variants, responsiveness gaps

Audit framework

Area	What I evaluated
Consistency	Did similar charts behave the same way across products?
Scalability	Could teams reuse patterns without reinventing them?
Accessibility	Keyboard navigation, color contrast, screen reader labeling
Localization	Date and time formatting, label truncation, RTL considerations
Responsiveness	Dense dashboards across mobile, tablet, and large display breakpoints
Learnability	Could users predict interactions based on prior experience in other products?

The audit artifact covering use cases, section header patterns, interaction states, and component behaviors cross-referenced with customer feedback and internal team interviews.

Product discovery

Alongside the documentation audit, I reviewed existing analytics pages in-product to understand real-world usage, edge cases, and the gap between intended and actual behavior.

Key insights

• Users struggled most when charts of the same type behaved differently across products
• Filtering patterns were inconsistent between products; creating friction in investigative workflows
• Dense data visualizations lacked visual hierarchy, making it hard to identify what mattered
• Hover and tooltip interactions became unreliable at smaller screen sizes
• Teams were reinventing chart behavior independently, slowing delivery and compounding inconsistency

The biggest issue wasn't visual inconsistency; it was interaction inconsistency. That reframing shaped every subsequent design decision: the goal wasn't to clean up the UI, it was to establish a shared behavioral foundation.

Prioritizing for Adoption

With five design systems and dozens of divergent components to address, a full system rewrite wasn't realistic. The strategy was to start with the component that would deliver the greatest visible impact fastest; and use that early win to build organizational buy-in for broader adoption.

Why Top N?

Rather than redesigning the entire ecosystem at once, I focused on the most widely used visualization pattern: the Top N chart. It appeared across nearly every analytics surface at Cloudflare, making it the fastest opportunity to create visible impact, validate the system approach, and drive cross-team adoption.

Targeting a high-visibility component used across products allowed me to quickly standardize interactions, demonstrate the value of a shared system, and build organizational buy-in for broader adoption.

Designing the Top N Component

The Top N component design followed a structured methodology that became the template for every component in the system; from requirements and interaction states through anatomy, properties, dark mode, responsiveness, accessibility, and usage guidelines.

Defining requirements

Each requirement represents a distinct user need or open design question that needed resolution before component design began.

Interaction states

All four interaction states, plus the expanded on-click view that reveals all data points rather than the default Top 5.

Anatomy

The anatomy documentation broke down every sub-component, the Data Visualization Header, the individual Top N rows, and the parent container, with explicit spacing, sizing rules, and Figma auto-layout settings to remove ambiguity at handoff.

Layout & spacing

Alongside anatomy, explicit layout specifications covered padding, item spacing, minimum and maximum widths, and how the component behaved when expanding from compact to full-width views.

Dark mode

Localization

Responsiveness

Accessibility

Accessibility was specified alongside the component design; not retroactively applied. Keyboard navigation patterns, focus management rules, ARIA roles, and screen reader support were all documented as part of the component spec.

Mobile interactions

Mobile-specific touch targets, tap behaviors, and interaction patterns were specified separately from desktop to ensure the component worked correctly across all device contexts; not just scaled down.

Usage guidelines & edge cases

A system only works if teams know how to use it correctly. Usage guidelines covered nuanced edge cases: labels as internal or external links, info tooltip rendering on hover, behavior when data is unavailable, and how the component handles truncated or overflowing content.

Before & after

The result of consolidating five independent systems into one shared foundation: a consistent, predictable analytics experience across every Cloudflare product.

Scaling Beyond the First Component

Top N was the wedge; but consolidating five design systems required building a foundation every team could build on. This meant establishing shared color tokens, typography scales, spacing systems, and a comprehensive library of chart and supporting components covering the full range of visualization needs across Cloudflare's analytics surfaces.

Chart component library

The system grew to 30+ reusable components, organized into four categories based on the type of analytical question they help users answer.

• Foundational:Top Metrics, Tables, Line, Bar, Stacked Bar, Horizontal Bar
• Comparative:Distribution, Histogram, Scatter plot
• Flow & Relationship:Sankey, Funnel
• Geographic:Choropleth map, Point map, Proportional symbol map

Supporting components

Charts were only part of the picture. Standardizing the surrounding analytical experience, the containers, controls, and contextual elements that frame every visualization, was equally critical.

• Chart containers and section headers
• Legends and tooltip patterns
• Filter structures and date range pickers
• Loading, empty, and error states
• Data export controls

The distinction matters: the system didn't just standardize charts. It standardized the entire analytical experience.

Driving Adoption Across Teams

A design system that teams don't adopt is just documentation. Getting 50+ engineering teams onto a shared system required more than good components; it required finding the right moments to get in front of teams, making it easy to say yes, and building enough visible momentum that skeptics became advocates.

Finding the right moment

One of the biggest adoption challenges with any design system is timing: reaching teams when they're already motivated to change, not when they're heads-down shipping something else. We solved this by building a custom automation; an OpenCode skill that monitored project activity and sent the PM, EM and me a notification whenever a PM was spinning up a new dashboard project or an engineering team was beginning a cleanup cycle.

Those two signals were the highest-leverage adoption moments: a PM starting fresh had no legacy debt to untangle, and an eng team in cleanup mode was already primed to reduce inconsistency. Rather than making teams come to us, we showed up at exactly the right point in their workflow reaching out, walking through the value, and offering hands-on onboarding help. Teams started with the system instead of discovering it mid-project.

Onboarding and visibility

• Presented the system at all-hands meetings to establish broad visibility across design and engineering
• Gave monthly updates to keep momentum visible and communicate what was new or improved
• Hosted company-wide data visualization office hours where teams could give feedback, ask questions, connect with others using the system, and collaborate directly with engineering
• Worked with multiple PMs to scope cleanup epics into upcoming quarters, making adoption a planned workstream rather than an interruption

The cleanup epics became the tipping point. As momentum built, leadership formalized the initiative top-down: every team is now required to adopt the system by Q1 2027. What started as a bottoms-up effort to demonstrate value had earned the organizational weight to become a company-wide standard.

Outcomes & Impact

Product impact

• Designers completed new dashboard designs roughly 50% faster with solved patterns in the system, teams spent time on the actual design problem rather than re-litigating micro-decisions
• UI and UX consistency improved significantly across analytics surfaces, giving users predictable interactions regardless of which product they were in
• Faster comprehension across dashboards, reducing investigation time for users navigating complex data

Team impact

• As engineering adopted shared components, QA cycles saw a significant reduction in small UI detail issues fewer one-off implementations meant fewer inconsistencies to catch
• Shared interaction standards eliminated duplicated design and engineering work across teams
• Cleaner handoff through standardized specs reduced back-and-forth between design and engineering
• Adopted as the shared foundation across the broader design organization

The project evolved from a chart redesign initiative into a shared analytical platform used across products and teams. The bottoms-up momentum ultimately earned a top-down mandate: every team at Cloudflare is now required to adopt the system by Q1 2027.

Reflections

The wedge strategy works

Starting with Top N rather than attempting a full system overhaul was the right call. One highly visible, high-quality component built more organizational trust than a roadmap of 30 promised ones. Teams adopted it quickly because it solved a real pain they already felt; and that early momentum made everything that followed easier.

Documentation is the product

The Figma components were only half the work. The usage guidelines, edge case documentation, accessibility specs, and responsive behavior tables were what made the system usable at scale. Investing in that documentation upfront saved far more time than it cost; and made the difference between a component that gets used and one that gets forked.

Behavioral consistency is harder than visual consistency

Consolidating five design systems revealed that the visual differences were the easy part. The harder problem was the behavioral inconsistencies; divergent interaction models, conflicting filter behaviors, different keyboard navigation patterns. Those required cross-team alignment, not just design decisions. That alignment work was as much the job as the design itself.

Balancing flexibility with standardization

A system that's too rigid gets forked. A system that's too flexible provides no real consistency. The right balance was to standardize the behavioral and interaction layer, how charts filter, how states transition, how keyboard navigation works, while leaving teams room to configure within those constraints through well-defined component properties.

Meet teams where they are, not where you want them to be

Waiting for teams to discover the system would have meant catching them mid-project, after patterns were already set. Building an automation to detect the right adoption moments; a PM starting a new dashboard, an eng team beginning a cleanup changed the dynamic entirely. The outreach felt helpful rather than disruptive because we showed up when teams already had a reason to change. Proactive timing mattered as much as the quality of the system itself.

Systems work creates compounding returns

Every component added to the system made the next one cheaper to design, implement, and maintain. By the time the system included 30+ components, teams were shipping analytics features faster than before; not despite the shared system, but because of it.