Turning Game Data Into Self-Serve Decisions

Context

At a studio the size of EA, only the data analytics team had the access and skillset to query game data. That meant a designer or PM who wanted to test a hypothesis — "are payers in this cohort actually engaging with the new event?" — had to file a request and wait. Iteration speed on live games was bottlenecked by a team that wasn't in the room when the decision needed to be made.

Gamestate Labs' bet was that this didn't need to be true. If the underlying attributes and events were mapped once, anyone could build their own query, chart, and cohort comparison without touching a data pipeline.

Constraints

I was the only designer on the project, reporting straight to the co-founders with no other design or research support. There was no existing product, brand, or design system — everything from the information architecture down to the icon set had to be built from scratch. And the core object model was genuinely large: 1,000+ possible game objects (currencies, consumables, equipment, player attributes) that any given query might reference, all needing to be findable and distinguishable at a glance.

Process

The founders gave me a lot of latitude on UX direction, so the friction wasn't approval — it was scale. The query builder and chart/pivot-table experience had to stay usable even when the underlying list of attributes ran into the thousands.

A few decisions that mattered:

• Naming conventions over categories alone. With 1,000+ mapped objects, a flat category list wasn't enough to help someone scan and recognize what they needed. I worked through naming conventions and visual identifiers (icons, groupings) so a "currency" object and a "consumable" object were distinguishable at a glance, not just by label.
• Splitting point-in-time vs. interval attributes early in the flow. Rather than let a user pick any attribute and then hit a wall of disabled options, the query builder branches early — so the functions, time controls, and groupby choices a person sees are always valid for the attribute type they picked.

Solution

The shipped flow lets a user build a query from either an attribute or an event, branch through the right set of functions for that data type, choose granularity and time range (with a 6-month cap on custom ranges), layer in groupby cohorts, and stack filters — all before the query ever touches SQL. A second path lets users combine multiple metrics into a derived formula (e.g. (A+B)/100) for custom calculated metrics, without needing anyone else to write a query on their behalf.

I also built the design system this ran on — the first version of Gamestate Labs' visual language, componentized from that first project so the founders could keep building on it after I moved on.

Outcome

The MVP shipped, and the founders used it to secure funding — the strongest real signal that the self-serve premise held up outside the room I designed it in.

The time and self-serve figures are estimated, modeled against comparable self-serve analytics tools replacing a request-a-data-team workflow — not measured in production, since Gamestate Labs didn't have live usage data at MVP stage. The funding outcome is real.

Reflection

The naming/iconography work for the 1,000+ object list is the part I'd revisit first. It held up for the MVP, but a system that scales past a few thousand objects probably needs a more structured taxonomy than what a single designer can hand-craft — search and smart-grouping would carry more of the weight next time. I'd also push earlier for at least one round of user testing with an actual PM or designer persona before finalizing the query builder's branching logic — the flow was validated by founder intuition and my own reasoning, not by watching someone unfamiliar with the product try to use it cold.