Well Optimization Platform : Predictive Intelligence
Role
Lead Designer · Enterprise B2B SaaS
Year
2026
01 — The Context: High Stakes at Scale
The platform is an enterprise system used by operators to manage thousands of high-value assets simultaneously. At its core is a predictive alarm system: machine learning models analyze behavior and fire alerts when they detect patterns associated with future equipment failure.
In this domain, these alarms provide a 60 to 90-day window to act before a failure becomes critical. This isn't just a buffer—it's the entire margin. A single undetected failure can cost millions in lost production and emergency repairs.
02 — The Problem: Three Layers of Failure
The challenge wasn't just a missing tool; it was a chain of compounding failures that were invisible until we mapped them.
Surface (Fragmented Investigation): Engineers investigated alarms by navigating across disconnected pages while maintaining personal Excel sheets to document findings. Every case started from zero.
Structural (A Model with No Feedback): The predictive model fired alarms but had no way to receive outcomes. If an alarm was wrong, the data simply disappeared. The model never learned it was wrong.
Strategic (Stagnating Intelligence): If the system can’t learn from past outcomes, it stops getting better. Over time, that creates real risk for the people relying on it.
03 — Discovery: The Confusion Matrix Reframe
Through working sessions with Subject Matter Experts (SMEs), I analyzed the manual Excel workarounds engineers were using. I introduced the Confusion Matrix as a design framework to map the gaps.
This reframing shifted our goal from "building a better form" to "building a system that participates in the investigation." We realized that "False Negatives"—where the model misses a failure entirely—had to be treated as a first-class problem, even if scoped for future development.
04 — Design Principles
The system carries the load: If the system knows the data, the engineer should never have to find it. Context is surfaced automatically.
Evidence over speed: A checkbox produces a decision, but an investigation produces evidence. We designed to "slow engineers down" enough to be right, rather than making it easier to be wrong.
Design for the ceiling: Every architectural decision was made for future scale, ensuring we didn't build ourselves into a corner.
05 — Design Explorations: Defending the Architecture
These weren’t just visual decisions, they shaped how the system would work over time.
Designing for signal, not just input
There was an early suggestion to handle “Alarm Valid” as a simple checkbox. But in practice, marking something as “invalid” without context doesn’t add much value, it creates noise. For the system to improve over time, we needed to understand why an alarm was incorrect.
What I proposed instead:
A structured workspace where users could capture reasoning alongside their decisions, turning isolated inputs into something the system could learn from.Making sure critical failures could actually be captured
Another decision point was where investigation should live within the system. Placing it inside the “Alarm Hub” was the more straightforward option. But that structure only works when an alarm exists. Some of the most important cases—false negatives—don’t show up there at all.
What I proposed instead:
Moving investigation to a global level, so users could capture and analyze issues even when the system failed to surface them.
06 — The Solution: Closing the Loop
The final system consists of an Investigation Grid (the team's shared memory), an Adaptive Workspace, and an Analytics Dashboard.
Screen 01 (The Grid): Answers the question: "Has someone already investigated this?"
Screen 02 (The Workspace): A three-panel layout providing context-aware telemetry (directional deltas vs. daily averages) and "Similar Cases" that the engineer never has to search for.
Screen 03 (The Dashboard): The Confusion Matrix moves from a design framework to a live operational
metric, tracking True/False Positive rates over time.
Designed for What’s Next
While the current system closes the loop for detected alarms, one critical area was intentionally scoped for a future phase: capturing failures the system misses entirely. These “false negatives” represent the most expensive and high-risk scenarios, but they don’t naturally surface within an alarm-driven workflow.
Addressing this requires a dedicated failure logging mechanism—one that allows engineers to manually record missed events and feed them back into the system. Rather than forcing this into the initial release, we designed the architecture to support it as a natural extension in a future phase, ensuring the system can evolve without restructuring the core experience.
06 — Outcome & Reflection
This work shifted the platform from a system that generated alerts to one that could learn from them.
Instead of treating each alarm as an isolated event, the system now creates a continuous loop, where every investigation contributes back to improving future predictions.
More importantly, it changed how engineers interact with the platform. Work that was previously fragmented, manual, and undocumented is now structured, shared, and reusable.
Scope of Work
