Designing Operational Intelligence
Turning scattered operational data into one clear answer: which campaign needs my attention today — and why?
What Was Established
Leadership reviewed and approved the first version, it moved into build, and the product launched internally.
- A shared campaign-health model
- A decision-oriented portfolio view
- A visual prioritisation model
- Progressive investigation without losing context
- A product direction that could be validated before adding recommendations and automation
The Problem
TMS was shaped as an internal intelligence surface for operational teams. The initial ambition covered Trainer, Pod Lead, PM and Delivery Director, but the design started with the Delivery Director because the problem sat at the portfolio level: comparing campaigns and deciding where attention was needed.
Delivery leaders already had operational data across spreadsheets and systems, but interpretation was inconsistent. Some spreadsheets contained more than 50 columns, and each Delivery Director had developed their own way of reading campaign health.
Which campaign needs my attention today — and why?
Discovery Under Constraints
This was not a conventional research environment. I could not freely shadow Delivery Directors because they were running live campaigns, and I did not have access to the latest operational spreadsheets.
I used two historical Excel sheets and conducted 1:1 interviews with Delivery Directors to understand their goals and day-to-day activities.
I also used stakeholder workshops to establish the operational decision model and the signals needed to support those decisions.
That shifted the framing from what information belongs on a dashboard to what information helps a Delivery Director make a decision.
The discovery focused on four questions
Turn Operational Data Into a Decision Model
The product was structured around a simple decision pattern, expressed through the interface, and backed by a shared meaning of campaign health across three dimensions. Capacity was treated as a possible decision or intervention after diagnosis, not as a health dimension.
| Layer | Model |
|---|---|
| Decision pattern | Detect → Investigate → Diagnose → Intervene |
| Interface | Scan → Prioritise → Investigate → Decide |
| Campaign health | Throughput · Quality · Timeline |
| Early-warning ladder | On Track → Off Track → At Risk → Delivery Failure |
Make Portfolio Risk Comparable
There were dozens of possible measures. Each candidate was tested against three questions.
This narrowed a much larger operational dataset to six high-level diagnostic signals: AHT, Quality, Deliverable Count, Completed, Timeline and Redo. These were the first troubleshooting layer rather than the complete measurement system; deeper metrics remained available for investigation.
Why a bubble chart
For portfolio comparison, a table was useful for investigation but slow for scanning many campaigns. To reduce adoption friction, Delivery Directors could switch between the bubble-chart and table views using a toggle beside the company name; the selected view persisted until manually changed.
The bubble chart combined four dimensions in one view.
The visual was chosen because it represented the problem — not because it looked modern.
What the chart encodes
Prioritise, Then Investigate
The bubble chart created an initial prioritisation layer. A large Off Track campaign could warrant different attention from a small campaign in the same state because their business impact differed.
Once an outlier was identified, the user could move through Campaign → Pod → Trainer without leaving the investigation surface.
The design explored richer table interactions, filters, configuration and date-range controls. Implementation constraints later required the table experience to be simplified, while preserving the underlying investigation goal.
The Final Product
The resulting Delivery Director surface brought the decision journey together: Scan → Prioritise → Investigate → Decide.
TMS sat above the internal Labelling Tool, where trainers were assigned tasks and updated their work, so this surface focused on intelligence and decision support rather than task execution.
The final dashboard gave leaders a portfolio-level view, surfaced exceptions, and allowed investigation into campaign, pod and trainer levels without losing context.
What Was Established
The first version was reviewed and approved by leadership, moved into build, and launched internally. A quarter of operational data was then collected before the final product decision. The design established:
- A shared campaign-health model
- A decision-oriented portfolio view
- A visual prioritisation model
- Progressive investigation without losing context
- A product direction that could be validated before adding recommendations and automation
Post-launch business outcomes such as faster intervention, fewer escalations or improved delivery performance were not yet established at the point documented in this case study.
Interested in the long version?
This is the short read. The full case study goes deeper into the discovery constraints, the metric definitions, the table and filter explorations, and the trade-offs made for build. Email me and I'll send it over.