Work / Reporting & Analytics

Sign In EnterpriseTurning complex event data into clear, actionable insights

Reporting dashboard

A feature gap that impacted product value

The existing reporting experience was limited, hard to find, and not useful. Customers exported raw data and built reports manually.

  • Time-consuming workflows
  • Low confidence in data interpretation
  • Missed insights across roles
  • Weaker product compared to competitors

Objective

  • Replace manual workflows with self-serve reporting
  • Enable users to answer real-world questions
  • Support multiple roles with different needs
  • Create a scalable analytics foundation
Previous reporting dashboard experience

Previous reporting experience: limited visibility, minimal filtering, and hidden within settings, forcing users to export data and analyze it externally.

The existing experience made it difficult to answer even basic operational questions. Users had access to data, but no effective way to explore, filter, or interpret it within the product.

My role

I led product design for reporting and analytics, defining the data structure, interaction model, and user workflows in collaboration with Product and Engineering.

Understanding how users think about data

Users weren’t asking for dashboards. They were trying to answer questions.

  • Security teams needed compliance visibility
  • Reception teams needed operational insights
  • Leadership needed summaries and trends
User research notes

Research showed users needed answers, not raw data.

Designing the data structure first

The challenge wasn’t UI, it was structuring the data in a way users could understand and manipulate.

I mapped the product data model to identify relationships and define a usable filter structure.

Data model diagram

Mapping the product data model helped define relationships and structure.

I then translated this into a filter taxonomy aligned with how users think about their tasks.

Filter mapping

Transforming the data model into a usable filter structure.

Defining the interaction model

I created a conceptual model to structure reporting as a system, not just a feature.

  • Reports as reusable objects
  • Filters as flexible inputs
  • Data visualization as output
Conceptual model

Conceptual model defining how reports, filters, and data interact.

Key design decisions and tradeoffs

  • Predefined reports over blank dashboards: Helped users start with meaningful insights
  • Flexible filtering over rigid views: Allowed adaptation to real workflows
  • Scalable structure over quick UI fixes: Enabled long-term growth
  • Simplicity over full customization: Balanced usability for non-technical users

Iterating on filtering and report creation

Filtering was a critical part of the experience. Users needed flexibility without complexity.

I explored multiple approaches to:

  • Allow users to add filters dynamically
  • Maintain clarity in filter logic
  • Reduce cognitive overload
Filter iterations

Iterating on filter patterns to balance flexibility and usability.

Structuring the reporting experience

I used a master-detail layout to allow users to explore and modify reports without losing context.

  • Quick switching between reports
  • Inline editing and filtering
  • Reduced navigation overhead
Reporting UI

Making data usable

The goal was clarity, not complexity.

  • Used bar charts for comparison and trends
  • Reduced visual noise
  • Focused on decision-making, not exploration

Impact

  • Replaced manual data export workflows with self-serve reporting
  • Increased product value by making data usable
  • Enabled role-based reporting across teams
  • Contributed to ARR growth through improved capability
  • Established a scalable foundation for analytics

This work transformed reporting from a hidden, limited feature into a meaningful product capability.

Back to top