top of page

Meta · Evolving one design system · 02 of 03

Analytics Decision System

Collaborators

Platform Engineering, UXR, PMs, and teams across Meta Ads and analytics surfaces

My focus

Reframed the design system's role in analytics from chart delivery to decision support — prioritizing reusable patterns that could serve a wide range of literacy levels while unlocking the greatest number of product teams given the organization's direction and constraints at the time.

 

Drove the shift from a DS bottleneck model to a contribution model by consolidating fragmented documentation, pushing back on independently built vertical solutions, and shipping reusable analytics patterns as operational proof points. The patterns launched in production and began scaling across Meta's business products.

Overview

After Geo 2.0 established the shared visual foundation, a gap remained — data-heavy workflows were still being built outside the system. The work reframed the design system's role from chart delivery to decision support, defining reusable analytics patterns and the contribution model that enabled product teams to build within the system rather than around it.

Challenges

The design system operated reactively — the backlog grew, vertical teams designed analytics components independently, and engineering deprioritized data visualization because simpler local solutions existed. Without shared patterns or governance, analytics experiences diverged across teams and products.

 

At the product level, the data was there, but the decisions were not. One-size-fits-all charting patterns could not support the range of literacy, flexibility, and guidance needed across advertiser workflows. The system lacked a shared model to help users move from data to action.

Diagnosis & Strategy

The core reframe was strategic, not visual. Instead of treating analytics as a charting problem, the work reframed data visualization as a decision-support problem — recognizing that users received data but often lacked clear guidance on what it meant or what to do next.

 

That reframing changed both the product model and the organizational model behind the system. Rather than continuing to scale isolated analytics components, the strategy focused on establishing reusable decision-support foundations that product teams could adapt across workflows while still operating within shared behavioral boundaries.

 

In parallel, the work shifted the design system from reactive bottleneck to scalable platform by consolidating fragmented documentation, aligning teams around shared frameworks, and using reusable analytics patterns as operational proof points for broader adoption.

Screenshot 2026-05-16 at 4.43.25 PM.png

System Evolution

The architectural move was to redefine what a component was supposed to do. A flexible component gave teams building blocks; a decision pattern gave teams a reusable structure combining data visualization, insight, and action around a specific workflow need. That three-zone structure — data, insight, action — became foundational to the system. Variation was not an override, and a decision pattern was not a one-off UX solution.

 

From 15 potential analytics patterns evaluated, the system focused on two that could support the widest range of data literacy levels, adapt across the largest number of product surfaces, and support the greatest number of product teams. The Bar Chart + Radio List pattern resolved a recurring workflow problem where comparison data and decision controls were disconnected. The Insights Popover established reusable structures for turning passive analytics states — previously solved through one-off tooltip implementations — into persistent, action-oriented workflows.

Screenshot 2026-05-18 at 12.08.36 AM.png

- Decision Pattern Anatomy - 

The system also established a clear boundary between platform responsibility and product flexibility: the design system governed structural integrity, behavioral consistency, spacing, and visualization logic, while teams configured workflow-specific content, density, and data connections. That boundary system governs, teams configure is what made the patterns scalable without becoming fragile.

Screenshot 2026-05-18 at 12.40.40 AM.png

- Popup Framework Pattern Anatomy -

Getting teams to build within that boundary rather than around it required organizational changes alongside the system itself. This means pushing back on vertical teams building outside the system, consolidating fragmented documentation into a single live reference, establishing direct feedback channels with product teams to track how patterns were adopted and where they broke down in practice, and running rollout workshops with analytics teams to build the capability for product teams to contribute rather than just consume.

Data viz_popup framework in product.png

- Three-Zone Decision Architecture Across Business Products -

Impact

  • Design system shifted from bottleneck to standard-setter — product teams building within the system rather than around it

  • 8 standards · 17 reusable patterns co-developed across 18 product teams

  • 6+ analytics surfaces unblocked through shared infrastructure

  • 200+ designers and engineers building on shared infrastructure

  • Decision patterns launched in production and began scaling across Meta's business products

View other case studies →

bottom of page