All case studies6 min read
UX Case Study · Enterprise · Delivery Operations

Designing Operational Intelligence

Helping delivery leaders catch operational risk before it turned into delivery failure.

RoleProduct Design Consultant (UX Lead)
Duration3 Months
PlatformEnterprise web application
Approved · Moved Into Build
01 / 15At a Glance
At a glance

Approved by Leadership · Moved Into Build

A single platform replaced the manual interpretation of scattered operational data.

50+Spreadsheet ColumnsSome ran past 50, and every director read them differently
6Core MeasuresNarrowed down from dozens of candidate metrics
4Health SignalsThroughput, quality, timeline and capacity, blended into one read
4Warning LevelsOn Track → Off Track → At Risk → Delivery Failure
What changed

From Manual Interpretation to a Shared Read

BeforeLeaders judged the health of dozens of campaigns by hand.Stitching together spreadsheets, QA reports and revenue sheets.Each director interpreting every one their own way.
AfterA single platform turned scattered data into one clear answer to "what needs my attention today?"The first version was reviewed and approved by leadership.It moved into build.
A clear operational readReplaces manual interpretation of spreadsheets, QA reports and revenue sheets.
One shared way to judge campaign healthReplaces every director having their own method.
Risk surfaced earlyReplaces guesswork about where to look first — while there is still time to act.
Context

The Problem Was Never Missing Data

The company already produced enormous amounts of operational data — project status, delivery metrics, quality reports, revenue — but it lived across different systems. The problem was never missing data. It was turning scattered data into a decision.

Some spreadsheets ran past 50 columns. Every Delivery Director built their own way of reading them, which made reporting inconsistent and decisions slow.

The framing

The platform wasn't built to replace spreadsheets. It was built to replace manual interpretation.

Research

Two Kinds of User

Research showed people worked at two very different levels — and one interface couldn't serve both without overwhelming one group or oversimplifying for the other.

Decision

Design around the decision someone is making, not their job title.

Campaign ViewRunning a single campaign day to day; needs to investigate issues.
Portfolio ViewWatching the health of many campaigns at once; needs to compare and prioritise.
Discovery

Discovery Under Constraints

Reducing uncertainty, not collecting requirements

I couldn't shadow directors — these were live operations — spreadsheet access was limited, and most of the real knowledge lived only in people's heads. So discovery wasn't about collecting requirements. It was about reducing uncertainty before making product decisions.

Instead of asking "what should the dashboard show?", I asked what questions directors needed answered to run delivery well. Those questions became the product.

The questions that became the product

1
Which campaigns need me today?
2
Why is this one falling behind?
3
Is it quality, throughput or staffing?
4
Can it still recover?

How Leaders Actually Decide

Discovery revealed leaders didn't simply monitor campaigns — they ran the same investigation every time something looked wrong. The product was built around that pattern.

01Detect
02Investigate
03Diagnose
04Intervene

The product wasn't designed to monitor work. It was designed to support decisions — mapping directly to the mental model leaders already used every time something looked wrong.

Definition

Defining Health, and Early Warning

One signal from four

Everyone talked about "campaign health," but no one defined it the same way — delivery progress to some, quality to others, revenue to finance.

Rather than pick a single number, health became a blend of four signals: how much work got done (throughput), quality, timeline, and available capacity. That combined signal drove a simple early-warning ladder, so problems showed up while there was still time to fix them.

Off Track is an early warning, not a failure. The real job was to buy leaders time between the two.

The early-warning ladder

1
On TrackAll signals healthy.
2
Off TrackEarly warning — time to act.
3
At RiskEscalating concern.
4
Delivery FailureCritical — intervention required.
Prioritisation

Deciding What to Measure

Discovery surfaced dozens of possible metrics. The hard part wasn't collecting more — it was keeping only what changed a decision. Every candidate passed three tests.

1
Does it change a decision?Only metrics that directly influenced a director's next action were kept.
2
Can engineering realistically capture it?Data had to actually exist in the systems before it could be designed into the product.
3
Is it a business-agreed definition?Metrics needed shared meaning across teams, not individual interpretation.

That narrowed dozens down to six core measures. One definition reshaped the whole product: when is a task "complete"?

My UX instinct said after review approval. But the business planned around trainer throughput — even rejected work still consumed time and budget — so completion measured output, and quality became its own separate signal.

Lesson

Understand why the business measures something before designing how it's shown.

Data visualisation

Choosing the Bubble Chart

Why the obvious charts failed

The toughest visual problem: compare many campaigns across several dimensions at once, without burying the reader.

Tables were great for investigating but slow for comparing. Bar and pie charts showed too few dimensions. Scatter plots showed only two.

Chosen because it represented the problem best — not because it looked modern.

What the bubble chart encodes

1
Position (across)Operational status across campaigns.
2
Position (up)Progress toward expected completion.
3
SizeBusiness impact — revenue, or team size where revenue wasn't available.
4
ColourGreen, yellow or orange status.
Interaction

Progressive Investigation

The real challenge came after spotting an Off Track campaign: getting to the exact pod or trainer responsible without making users restart their thinking. The obvious option — a new page for each level — reset the user's mental model on every click.

Instead, selecting a campaign didn't open a new page. The same table simply went deeper. Filters narrowed the data — throughput below expected, a specific pod, a delivery stage — and extra explanation like campaign names, metric definitions and chart periods appeared only on hover, keeping the screen calm.

Users should think about the problem, not about navigating the product.

1
Campaign ViewOverview of all campaigns and status
2
Pod ViewTeams within the campaign, and their metrics
3
Trainer ViewIndividual root-cause details and actions
Editing

Every Element Had to Earn Its Place

Enterprise dashboards tend to become a pile of charts and widgets. Here, Product and Design challenged every measure, chart and icon with one question: does this help a director make a decision? If not, it went.

KeptThe bubble chartThe investigation tableA few critical measuresFilters and trends
CutSecondary metricsDuplicate chartsDecorative iconsLow-value columns
Simplicity wasn't a visual style.
It was the result of hard prioritisation.
Scope

Validate First

Doing less, on purpose

The long-term vision included recommendations and automation — but the first version deliberately did less. Its only job was to prove one thing: does clearer operational intelligence actually help directors decide better? Only after proving that would automation be worth building.

  • Engineering confirmed the data actually existed before anything was designed — validate the data before the dashboard.
  • Refresh ran hourly: enough to test the idea, without the cost of real-time.

Phasing

1
Phase 1Prove operational intelligence helps directors decide better.
2
Phase 2Build recommendations and automation on a validated foundation.
Walkthrough

The Product in Action

A Delivery Director opens the platform on Monday with one question: which campaign needs me today?

01Open PlatformAsk: which campaign needs me?
02Scan Bubble ChartOutliers surface — a large Off Track bubble
03Drill DownCampaign → Pod → Trainer, context preserved
04ResolveIdentify root cause and act

Because size reflects business impact, the top priority is instantly visible. Selecting it drills the same table from Campaign to Pod to Trainer, narrowing to the root cause without ever losing context. Operational intelligence reduces the time it takes to decide where to look first.

Result

What Success Looked Like

Success here wasn't screen time or visual polish — it was less effort to reach a decision. The questions that defined it:

Spot Issues FasterCould directors identify at-risk campaigns without manually reading every row?
Investigate Without SpreadsheetsCould they investigate without opening five separate spreadsheets?
Read Health With Less EffortCould they read campaign health with less manual interpretation work?
Act With ConfidenceCould they make intervention decisions with greater confidence?

Because this was a first version, the long-term proof — faster intervention, better delivery outcomes, fewer escalations — still needs real-world use to measure.

Leadership approved the direction, and the next phase was build, followed by roughly three months of use to evaluate.

User Interface

Selected screens from the first version.

Like how I work? Let's build the next one.

You've just read how I think — the research, the trade-offs, the decisions I defended and the ones I'd make differently. I'm open to Lead and Senior Product Designer roles, remote, hybrid or in-office. Tell me what you're building and I'll tell you where I'd start.

UXUXChronicle

Lead Product Designer turning complex systems into clarity. 13+ years, 11+ products shipped.

Open to Lead / Senior Product Designer roles
© 2026 Huseini IndorewalaCurrently reading: Refactoring UI
Indore, India · IST (UTC +5:30)