Making a data warehouse legible
Redesigning an enterprise analytics platform for both the engineers who run it and the executives who pay for it

Role Lead UX designer and researcher
Client Enterprise data-management software vendor (name withheld under NDA)
Timeline Five months
Team Product manager, engineering lead, three front-end engineers
Delivered Research synthesis, information architecture, interaction design, high-fidelity UI, developer handoff

The problem

Enterprise data warehouses generate an enormous amount of operational data — query loads, job performance, storage utilization, bottlenecks — and organizations depend on it to make infrastructure decisions worth millions. The platform I was brought in to redesign had been built by engineers, for engineers. It worked, but only for people who already understood the underlying architecture. The insights it contained were effectively invisible to the people who most needed to act on them: operations managers, finance leads, and the executives who controlled the budget.

Two audiences, one product

The database administrators who lived in the system needed full technical depth — raw query counts, job elapsed times, HDFS byte metrics, side-by-side DB2 and Hadoop comparisons — and were openly skeptical of any simplification that might hide something they relied on. The executives needed the opposite: a clear read on how the infrastructure was performing, where the bottlenecks were, and what was sitting idle. The brief was to serve both without building two products.

What I learned

I ran fourteen interviews across the two audiences — eight DBAs and data engineers, six business stakeholders including two finance analysts and a VP of infrastructure — plus four observed working sessions with DBAs and a review of six months of support tickets. Three findings shaped everything that followed.

First, working context was the most consistent pain point. DBAs rebuilt the same filtered views from scratch every session because there was no way to save them; one had a text file of parameter combinations he pasted in by hand. Second, the executives weren't using the product at all. They were getting a monthly spreadsheet that a senior DBA assembled manually from the raw report, which meant the most expensive decisions were being made from a week-old summary filtered through one person. Third, the engineers' distrust of simplification had a specific history: an earlier "dashboard" attempt had dropped time ranges and units from its charts, and it had produced a misread that cost a weekend. They weren't against clarity. They were against losing the ability to verify.

Three decisions

1. One architecture, read at different depths. Rather than a "simple mode" and an "expert mode," I designed a single navigation that gets more technical as you go: a Summary tab for finance and operations, an Overview for daily monitoring, and Workloads, Query Analysis, and Jobs for engineers. An executive and a DBA are in the same product; they just stop at different floors.

2. Color as a frequency scale, not decoration. On the Workloads view, every database, schema, and table falls into one of six query-frequency buckets, and the same six colors run through the donuts, the legend, and the tables. The hot end of the scale is red because the DBAs asked for load concentration to be the loudest signal and that's where performance risk lives while managers learned to read the cold end as what's idle. Drill-down from any segment opens five dimensions: Users, Data, Applications, SQL, Last Visited all from a single interaction point.

3. Keep the engineer's depth, but off the primary view. Top Jobs plots every job by Maps against Reduces so outliers are visible before anyone reads a table; selecting one opens a detail panel with the full breakdown. Saved filter sets on Query Analysis let users name and reapply complex configurations which is the fix for the pain point research surfaced first.

Winning over the skeptics

The first prototype landed everyone on the Summary view, and the DBAs rejected it in the first session not because it was wrong, but because it was the wrong first screen for them. That objection became the role-based landing. The second round of pushback was about the Workloads donuts: two engineers wanted the raw frequency tables kept, not replaced. They were right. The tables sit directly under the charts in the shipped design because of them, and that pairing turned out to be what made the view trustworthy to both audiences; the chart tells you where to look, the table lets you check it. By the third round the same engineers were suggesting drill-down dimensions.

Outcome

The redesign shipped in the vendor's next major release. Within a quarter, the client's finance group had retired the manually assembled monthly spreadsheet in favor of the Summary view, and the senior DBA who had been producing it described that as "getting a day a month back." Saved filter sets became the most used new feature in the release, and the layered navigation pattern was carried forward into two subsequent modules. Adoption figures beyond that are under NDA.

The premise held: a system can be rigorous enough for the people who build the infrastructure and legible enough for the people who fund it.

Screens recreated for this portfolio; data is illustrative.