Studios already had analytics tools, but the harder questions still went through a business analyst. A product manager could see that revenue dropped. Finding out why meant opening explore mode, breaking revenue down by country and platform, checking registrations and retention, and eventually calling an analyst for the KPIs they couldn't find themselves. Analysts weren't much better off. If the tool couldn't keep up, they'd fall back to Tableau or SQL for most investigations, and the tool became one more thing to maintain. The opportunity was to let more of the studio answer its own questions, and to leave analysts free for the hard ones.

I joined after the initial research. The data team had already written a thorough brief: personas, the terms the product would use, chart types and core use cases. The brief described four people, and in a small studio one person often plays several of these roles: - Developer implements events, builds technical dashboards (battery, frame rate) and checks events are tracked correctly. - Business analyst defines events and high-level KPIs, builds business dashboards, runs A/B tests, and wants to answer 80% of questions in the tool. - Product manager tracks the game’s key KPIs, wants to answer 80% of questions alone, and uses the analyst as a fallback. - CEO wants 90% of answers from dashboards. All four shared the same risks: the learning curve is too high, the tool is too complex for common cases, or it’s too slow. That became my design brief in one line.

The brief defined metric, dimension, user property, segment, cohort and group by. These words meant precise things to the data team and very little to a producer. I used the definitions to decide where each concept lived in the UI: metrics on the Y axis, dimensions in filters and group by, segments as named groups you could compare on every chart.

We tested the prototype with 12 participants: three business analysts, two game designers, three developers and four product managers. We wanted to check three things: - A product manager could go from an emailed dashboard to a likely root cause without help. - People could set a filter for the whole dashboard, then change it for an individual chart. - A developer could confirm an event was being tracked.

The comparison dates were too small and easy to miss. Participants weren't sure which period they were comparing against. We added the period beneath the Compare button and made the dates stand out more on the chart.

Participants understood how to give an individual chart its own filters. Only the settings they changed stopped following the dashboard’s global settings. After changing a global filter, they weren't sure why the chart kept its local value or how to make that setting follow the global filter again. We added clear override indicators and controls to restore global settings on that chart.

The KPI picker allowed multiple selections, but people were adding one chart at a time because they hadn't noticed that option. We added checkboxes to the KPI cards to show that more than one could be selected.

The studio worked on several games, but the dashboard didn't say which game the data came from. That left people unsure which one they were looking at. We added a game identifier at the top.

On crowded dashboards, resizing one chart made the others move around, and the layout became hard to follow. We kept the manual resizing people liked and added a dropdown with preset layouts and sizes, so they could also choose a size without dragging.

Product managers didn't open analytics every morning. Dashboards came to them by email, so the email report had to show what changed, not just send a link.

Dashboard highlighted a significant change and showed its size as a percentage, so nobody had to compare line charts with what they expected.

In explore mode (the KPI Explorer), people could build three kinds of chart: events over time, user KPIs such as DAU and retention, and cohorts. They could filter and group by any dimension. Harder KPIs defined by analysts sat behind a semantic layer, so a product manager could pick "retention" without knowing how it was calculated.

On a dashboard, every chart can be resized, so we built a layout engine that repacks it at every size. Each chart type has its own rules for widths, heights and the number of segments, which added up to hundreds of variants.

Finding the cause of a drop was only half the job. Stories turn an investigation into a short brief with live evidence that goes straight to the teams who can fix it, and it stays in the Hub until the problem is gone.

The Hub is GameTuner's home page and the place where everything else in the product comes together: dashboards, Stories, annotations and releases. Instead of everyone checking their own reports, the whole studio starts from the same picture of how the game is doing and what changed.

Who can define a KPI decides who can ask questions. Putting harder metrics behind names people already used did more for accessibility than any amount of UI polish.

Nobody wakes up wanting a line chart. Building the product around one real investigation, from the inbox to the fix, made it easier to decide what each screen was for.