Custom Reporting for Pulse Talent Analytics

Overview

Pulse Talent Analytics was an in-house talent analytics platform at Gartner, built starting in 2017 and spanning survey writing, distribution, data collection, and analytics. As the product designer covering both design and research, I worked alongside a product manager and the client advisor stakeholders who used the platform’s output to guide their own clients’ talent decisions.

Clients could view survey results as charts, benchmarks, and raw data, then export that analysis into PowerPoint reports for their own stakeholders. By summer 2018, ongoing feedback had sharpened into a clear, recurring theme specifically about reporting.

Problem

The reporting dashboard let clients view and manipulate a range of charts and drill into individual survey questions. The breakdown happened at export: reports generated a slide for every question and chart type, producing decks that were long and unfocused.

HR leaders were not asking for more data. They wanted to choose which metrics appeared in their charts because they were spending time manually editing exports down to the results that mattered for the story they needed to tell.

Opportunity

[Add a concise opportunity statement that connects the validated reporting need to the product and business opportunity.]

Solution

The resulting solution was custom dashboard views with custom report exports. Users could build a named dashboard by selecting which questions appeared for trends, favorability, and demographic charts, then layer in filters and benchmark comparisons before exporting that specific view to PowerPoint.

Core flows

1. Create and name a custom dashboard.
2. Select the questions and chart types that belong in the view.
3. Add filters and benchmark comparisons.
4. Review the saved dashboard or export the focused report.

[Add approved flow diagrams or annotated product screens here.]

Research and insights

The team first picked up the need through anecdotal feedback during customer calls. Rather than act on that signal alone, we ran formal client interviews to understand what clients were doing with existing exports and what they needed to do instead.

The research showed that client advisor stakeholders wanted a live custom dashboard they could reference during results calls. Clients had different workflows: some relied more on the dashboard, while others wanted to preview a custom report before exporting it.

Exploration and iteration

[Add approved sketches, concepts, prototype rounds, and the feedback that changed the design.]

Design decisions

The central decision was whether customization should exist only at export time or whether a saved custom dashboard should become a first-class object. The team chose the saved dashboard.

An export-only flow would not support client advisors who needed a live reference during calls, clients who worked primarily in the dashboard, or clients who wanted to preview the report before exporting it.

Constraints and tradeoffs

Supporting persisted, user-built custom views required significant backend infrastructure work. That was a meaningful scope addition, but it followed directly from how both user groups actually worked rather than from an assumption about what would be easiest to build.

Outcomes or impact

After Custom Reporting launched, clients could build dashboards around the themes they actually reported on instead of manually reducing oversized exports. Client advisor stakeholders could review a client’s custom dashboard before a results call and prepare relevant research content.

Custom Reporting was adopted by over 85% of clients, reporting usage increased 50%, and post-launch customer satisfaction reached 90%.

Reflection

I would involve client advisor stakeholders earlier in the design process rather than validating primarily through the client-facing research track. Their perspective directly shaped the persisted-dashboard decision, and earlier participation might have surfaced that need sooner.

This project also taught me to treat indirect signals—emails, pitch calls, implementation calls, and results overview calls—as meaningful user research input, not merely a supplement to formal interviews.