back to work

GitHub's first code security dashboard, built to unblock enterprise adoption

Leading design and product strategy for the first reporting experience in GitHub Advanced Security, giving enterprise security teams a way to prioritize risk across their codebases and track remediation progress over time.

Problem

GitHub Advanced Security was a young product without reporting or analytics features. Enterprise customers couldn't meet compliance audits or prioritize risk across their codebases, and it was actively blocking acquisition and retention.

My role

Lead designer. I owned the design vision and co-led product strategy across the multiple GitHub product teams contributing data to the experience, from research design through launch. I also partnered with the design system team to define GitHub's first data visualization patterns.

Solution

A dashboard that gives application security managers a high-level view of risk posture and remediation trends, helping them prioritize where to focus remediation next.

Outcome

Launched at GitHub Universe 2023 as a keynote highlight. Year over year, monthly active orgs grew ~2x and the most engaged cohort (teams returning 10+ days a month) grew ~3x. Sales credits the experience with removing reporting as a top adoption blocker for GitHub Advanced Security.

Detection tab of the shipped Security overview: open alerts over time grouped by severity, plus cards for age of alerts, reopened alerts, and secrets bypassed, and an Impact analysis table of top repositories.

The final, tabbed dashboard design. View shipped demo further down.

The org-chart trap

Every security product team and stakeholder had their own goals and KPIs, and every one of them wanted their product's metrics to be the focus. We risked shipping our org chart instead of a tool that actually helped application security managers prioritize and track remediation.

Using data to gain alignment

I ran research with existing and prospective customers across every target role: an open card sort to rank the data and insights they cared about most, plus jobs-to-be-done interviews to capture how each role measured success. From then on, I led every internal proposal with those ranked findings.

Open card sort categorizing security data and insights into Most Important, Important, and Somewhat Important columns. Secrets blocked and Mean time to remediation sit in Most Important; CVE in Important; a stack of additional cards waits to be ranked.

To build buy-in across the org, I also ran an async brainstorming workshop where every product team shared ideas and ranked them together. Stakeholders felt heard and shared ownership of the direction, which improved buy-in.

Pushing back with curiosity

Our PM wanted a risk score as the dashboard's hero moment. It's a table-stakes feature our competitors ship and a real gap for GitHub, so I agreed with the ambition. But the data wasn't ready: without accurate inputs, we'd put a number in front of customers that they wouldn't trust or would be grossly inaccurate. Rather than pushing back head-on, I led with questions. What signals would combine into the score? Does GitHub have access to that data? By the third conversation, she'd arrived at the same conclusion herself, and we shelved the risk score until we build the foundation we need to develop a score that is truly useful.

What shipped, and what it changed

The MVP launched and was a keynote highlight at GitHub Universe. In the year that followed, the dashboard moved from a launch metric to a habit. Users consistently outpaced orgs, a sign teams were expanding usage within their accounts. Follow-up interviews matched what we had heard in prototype testing: the metrics, filters, and scoping we shipped lined up with how enterprise security leads actually triage risk and prove compliance.

  • ~2x
    growth in monthly active orgs
  • ~3x
    growth in teams returning 10+ days a month

Sales and field teams have since reported that reporting is no longer a top adoption blocker for GitHub Advanced Security.

Final design concept that shipped, as of July 2025.

Seeding GitHub's data-viz system

Because we were the first product team at GitHub shipping charts at this scale, I partnered with the design systems team to define the platform's first data-viz components and guidelines. What started as our chart library became a shared pattern other products still build on.

Data Card component sheet showing header, body, and footer variants, plus component APIs and example compositions for metric cards, progress bars, and trend indicators.
Figma screenshots of my collaboration with the design systems team on the Data Card components.
Overview of the Dashboard and Reporting UI Pattern Guidance deck I authored, with sections for Layouts, Headers & Sections, Data Visualization, Progressive disclosure, States, and more examples.
The Dashboard & Reporting UI Pattern Guidance I authored for the GitHub design system.

What people said

  • “This new screen is almost perfectly the report I want for my leadership.”

    Principal Architect, Platform Architecture and Security · enterprise customer
  • “One of the customers on the private beta is loving the new overview. They've been able to report burndown of alerts on their monorepo with it. This is going to help a lot of AppSec teams.”

    Field engineer · relaying private-beta feedback ahead of Universe
  • “Other teams across the company are now looking to these dashboards for inspiration and guidance.”

    Staff product designer · GitHub security products team

Takeaways

  • Even with clear evidence, your best ideas will struggle to land without a strong narrative and stakeholders who feel collective ownership.
  • When no single view can satisfy every role, filtering and scoping is the right answer. Letting each role cut the same data their own way served more people than one curated view would have.

What I'd redesign for the AI era

AI has changed how application security managers operate: At the Gartner SRM Summit in June 2026, analysts flagged that traditional application security metrics like MTTR and vulnerability counts are losing relevance as enterprises shift toward risk posture and security outcomes. If I were leading this work today, here's how I'd redesign the feature to address these evolving needs:

  • Make governance, visibility, and policy controls first-class views as AI accelerates application security risk.
  • Reframe prioritization insights around exploitability, runtime context, and attack-path analysis instead of ambiguous severity scores and counts.
  • Every company defines risk a little differently, so customizable reporting and analytics give application security managers the flexibility and control they need to deliver on their company's priorities.

On the GitHub blog