Gemini Data Studio

The Stakes

Gemini Data Studio is the internal tool DeepMind researchers use to debug Gemini's training data — running evals, tracing conversations, isolating examples that failed quality thresholds.

When I joined, researchers were exporting to spreadsheets to do real work. The filtering system, the tool's most-used surface, didn't scale: filters scattered across the UI, no save state, full reset every session. A workflow over hundreds of thousands of examples with no shortcut for repeat analysis.

That makes it a model-quality problem, not just a UX one. Bad examples slipping through eval are upstream of every regression downstream.

I came in as the only designer on a sub-20-person engineering team. No PM. No design system. The previous designers had pitched rebuilds and left before shipping. The eng manager had stopped expecting much from design.

So I didn't pitch a rebuild. The first month I shipped two small filter improvements. After that, he asked if I wanted to drive the surface.

The Approach

Research as leverage

I audited 30+ tools — Datadog, Langfuse, Google's internal observability stack, anything dense and research-shaped. I looked past landing pages: docs, target users, specific interaction patterns.

Reddit was more useful than vendor sites. Researchers there talk about what they actually reach for. Langfuse kept coming up; it became my benchmark.

For the harder design problems — filters, tracing — I narrowed to 30 implementations of just that pattern across categories. The library didn't make decisions, but it gave the team three things they were missing: shared vocabulary, evidence for non-obvious calls, and a backlog of references I could reintroduce when the timing was wrong the first time.

The Decisions

Vertical filter panel over horizontal filter bar

The existing horizontal bar fit 3–5 filters comfortably and broke at the scale users needed. Researchers were rebuilding the same complex filter set every session because nothing persisted.

The default move would've been to fix the bar. The audit pushed me toward a vertical panel: more filter types, native grouping, save and reuse, room to grow as the dataset added dimensions. Not a common pattern in AI research tools — most ship the bar — but the evidence held.

Tradeoff was eng cost. The bar was an afternoon; the panel was a sprint. We shipped the smaller bar improvements first so researchers weren't blocked, and the panel landed before I rolled off.

Saved views: persistence and shareability

The filter panel solved the layout problem. It didn't solve the memory problem. Even with cleaner filters, researchers were rebuilding the same configurations every session because nothing held state. And once someone figured out a useful set, they couldn't hand it to a teammate — it lived in their head.

The fix was named, persistent view configurations: filters, layout, and parameters captured in a saved object that one researcher could share with the team via link. Repeated per-person setup work became a single click.

The harder call was scoping. Full collaborative editing (multiplayer, real-time) was out of reach for a team this size and would have committed engineering to maintaining a sync layer indefinitely. We shipped the simpler version — per-user saves with sharing as a one-way handoff. Good enough to remove the friction without taking on infrastructure we couldn't sustain.

Full-page tracing view over constrained table

Tracing was crammed into a small table row — like debugging code through a keyhole. The eng manager had the same intuition; what was missing was a concrete proposal backed by evidence.

The lead engineer wasn't sold at first. The table worked, from his perspective. Influence isn't about having the best argument — it's about building a case patiently. I gathered competitor examples, waited for user signals to converge, listened to what he wanted to preserve, and reintroduced when the evidence was undeniable.

How it moved

Working rhythm

Engineers on this team preferred short demos to presentations, so I matched that cadence. Two-option video walkthroughs with surrounding context blurred — focus stays on the actual decision. Filters took a 15-minute alignment and shipped the next day. Tracing needed more upfront work — FigJam diagrams of entity relationships, then mocks.

When ideas don't land

The vertical filter panel sat for months — bigger eng lift than the team wanted to absorb. The tracing rework had a skeptical engineer who liked the existing table. I didn't push. I gathered more references, waited for user signals to keep pointing the same direction, and reintroduced when the case had built itself. Both shipped before I rolled off.

A good idea with bad timing is just noise. The job is reading when the team can absorb the work.

The Impact

Three surfaces shipped — vertical filter panel, saved views, full-page tracing view — covering the researcher workflow from filter setup through example-level analysis. Together, they removed the friction that had pushed researchers out of the tool and into spreadsheets.

Selected screens available to walk through in conversation (work is under NDA).

Learning and reflections

I'd ship code from day one. The eng manager said it plainly: a designer who can land CLs in the codebase isn't just helpful on a 20-person team without dedicated frontend — they're a force multiplier. I started late. With AI-assisted coding tools from the start, I'd have moved faster. The line between design and engineering is dissolving on lean AI teams; the designers who'll do well aren't just thinking about what to build — they're helping build it.

What I want more of: lean AI teams where design is embedded, not consulted. High trust, high autonomy, fast feedback. AI products where the problem space doesn't have an established playbook — debugging model quality through data quality is exactly that kind of problem, and where design has the most leverage.

When I started, the engineering manager was skeptical of design. By the end he was sending people to me as the UX lead. The path there was the same one I'd take again: come in with research, ship small things first, earn the bigger calls over time.