The need for productized self-service data was identified through customer requests and the significant time Customer Success spent manually building reports for customers. The project was championed by the Design Director and Product Director with a shared goal of building a best-in-class analytics suite to rival competitors.

I led an iterative research and design process to answer the questions that would shape the product:

• What data matters most, and to whom? Research surfaced that admins and leaders had fundamentally different needs: admins wanted operational, actionable data to guide day-to-day program decisions, while leaders wanted roll-up, summary-level views to assess overall program health against organizational goals. This distinction directly shaped how we segmented concepts and dashboards by audience rather than by data type.

• What does "success" actually look like for a learning program? No single metric could answer that. Completion rates, engagement, time-to-competency, and other data points each told a partial story — and in isolation, could even be misleading. I worked to identify which metrics needed to be paired or sequenced to tell a credible success narrative (e.g., high completion paired with low engagement signals a different story than high completion paired with high engagement), and used that framework to inform dashboard structure, not just content.

• What data should prompt action, and how do we surface it? Beyond reporting on what happened, admins needed help recognizing when something needed attention. This shaped an early product principle: dashboards shouldn't just display metrics, they should help highlight anomalies or thresholds and nudge admins toward the appropriate next step — turning passive reporting into active guidance.

• What depth, control, and flexibility do users actually expect? I stress-tested an 11-section proposal through two rounds of prototype testing. The content largely resonated, but testing exposed a bigger gap: static views weren't enough. Admins needed to segment and filter data to answer their own follow-up questions, interact with visualizations to explore trends on their own terms, draw their own conclusions, and create custom reports to truly make this a self-service product.

• Did users actually understand what they were looking at? Testing surfaced a quieter but equally important gap: even when the right data was on screen, admins didn't always trust or understand it. Ambiguous labels, internal jargon, and unclear metric definitions meant some admins hesitated to act on what they saw or misread it entirely. Getting terminology and labeling right became its own design workstream, not an afterthought: every metric needed a plain-language label and definition an admin could interpret without a CS translator.

• What could we actually build first? Testing clarified which data was most critical to lead with and how to phase the rest. I narrowed the 11 proposed sections into a 2-phase, 4-dashboard MVP plan, balancing that research signal against technical reality: what data was already available via the API, what would require new API development, and overall engineering capacity.

Alongside the dashboard designs, I partnered with the Design System lead to define new data visualization components needed to support the hub.