Designing trust
into a platform operators
feared to rely on
Pred4Infra monitors critical infrastructure using cyberphysical AI. The technology worked. The interface didn't earn the trust operators needed to act on it. I redesigned all five core modules from audit to handoff.
A disruptive product nobody trusted
Pred4Infra uses physics-informed neural networks, computer vision, LiDAR, and autoregressive AI to predict infrastructure failure before it happens. It monitors bridges, pipelines, dams, and industrial machinery — assets where failure isn't a bug report, it's a disaster.
The platform was technically ahead of every competitor. But it had been built engineer-first. Operators were ignoring alerts, misreading visualisations, and overriding AI recommendations out of habit, not evidence.
Not a features problem. A trust deficit.
I audited the prototype against one question: does this help the user trust and act on what they're seeing? Eight critical failures surfaced, all pointing to the same root cause.
"Restart Server" (system-wide, catastrophic if misused) sat next to "Auto Backup" (low risk) with identical visual weight. A client admin could trigger platform-wide changes without realising the scope.
A remote rendering session fired automatically on every page load. No user intent captured. Sessions took 10 to 20 seconds of apparent failure. Layer names were technical jargon with no meaning for operators.
Condition tags were applied with no shared definition. "Moderate Stress" could mean watch it next week, or call someone now. No timestamps meant operators couldn't tell if a reading was real-time or hours old.
No data freshness signals
Every reading could be real-time or hours stale. Operators couldn't trust any number on any screen.
Severity labels with no definitions
"Moderate Stress" and "Critical" with no thresholds or action guidance. Every operator read them differently.
Heatmaps without a legend
Thermal stress visualisations with no colour scale, no threshold, no baseline for normal.
Platform and org controls mixed
Client admins could access system-wide controls. "Restart Server" had the same weight as "Auto Backup."
High-compute sessions auto-loaded
Remote rendering fired on every page load. The platform's most powerful feature felt permanently broken.
AI outputs with no lineage
Predictions with no data sources or confidence scores. Operators ignored them. The most powerful feature wasn't being used.
Understanding the user before the interface
Infrastructure monitoring is not exploratory. People open it during incidents, under pressure, needing answers in seconds. The interface had to work at its worst before it could shine at its best.
Every element scored: does this help the user trust and act on what they're seeing?
Mapped user types, decision flows, and pressure modes across ops leads, engineers, safety inspectors.
Industrial HMI design, alert fatigue in process industries, enterprise governance patterns.
Benchmarked IBM Maximo, Bentley iTwin, AWS IoT TwinMaker, Siemens Teamcenter, Seeq.
Sole designer. End-to-end ownership.
I owned every decision from initial audit to engineering handoff. Several moments required leading the product thinking rather than responding to it.
Restructured the navigation model
Infra Dashboard and Operations overlapped in purpose. I reframed the model into a decision ladder where each module answers exactly one question — requiring stakeholders to remove features, not add them.
Split Admin into two separate layers
The brief was "improve the Admin screen." I identified the real problem as architectural: two completely different audiences sharing one interface. I designed the separated permission model from scratch.
Proposed Risk Velocity alongside Health Index
Health Index was a snapshot percentage. I proposed Risk Velocity to show rate of change. An asset at 85% dropping 4% per hour is more urgent than one at 70% holding steady.
Turned the 3D viewer into a 5-state experience
The original screen auto-loaded a heavy compute session. I designed Entry, View Selection, Connecting, Inspection, Exit. Not a UI fix but a product-level reframe of what the workspace is for.
One principle. Every decision tested against it.
Rather than solving eight problems independently, I reframed the redesign around a single governing idea: trust is the feature. Does this make the system more trustworthy, or just more capable?
Previously Infra Dashboard and Operations overlapped. One answerable question per module eliminated that ambiguity during incident response.
Every AI-generated insight carries source, confidence, and time window. A number without context is noise. A number with lineage is intelligence.
Each decision shows the before state, what replaced it, and why the change mattered.
Severity levels given a threshold, a response window, and a guided action
Status labels applied with no shared definition, no threshold, no action guidance. "Moderate Stress" meant something different to every operator. In incident response, that ambiguity caused real delays.
Each status carries a rule-based threshold, a response window (Stable: 72h, Moderate Stress: 24h, Critical: immediate), and a guided next step. Every row shows "Last updated: X seconds ago" with visual degradation at 5 and 30 minutes. The label tells you what to do, not just how it feels.
In critical infrastructure, ambiguity costs time. Time costs lives. Turning a status tag into an operational instruction reduced cognitive load at the most pressure-heavy moments in the product.
3D inspection workspace redesigned as a deliberate 5-state experience
A remote rendering session fired on every page load. No user intent. Layer names (GLB, IPO, Dense Cloud) were technical jargon. The team called it "the broken tab."
Users arrive at a View Selection state: four named modes with data source, reliability score, and estimated load time. User chooses. User connects. Intent captured. Resources spent deliberately.
Choosing a mode primes the user's interpretive frame. They're not just looking at a 3D model — they're conducting a specific type of inspection with clear expectations of what colours and overlays mean.
Admin split into Platform Admin and Organisation Admin — two separate views
One screen mixed system-wide controls (Restart Server, Remote Access) with org-level controls (user management, alert routing). A client admin could trigger platform-wide changes.
Platform Admin (elevated auth): system health, global config, critical controls with scope labels and 2FA. Org Admin: users, roles, alerts, asset access. Two views. Two audiences. Zero crossover.
Enterprise procurement teams ask one question before signing: Is this safe to govern? The original Admin screen failed that test. The redesigned governance layer made the platform enterprise-procurable and audit-ready.
All five modules redesigned to high fidelity. Each anchored to its single job in the decision ladder.
What I carry forward
A timestamp is a trust signal. A confirmation dialog is evidence that the system respects the gravity of the action. Designing for trust means asking "how does this make the user feel about the system's reliability?" at every layer, not just the product level.
Renaming "GLB Model" to "Digital Twin Viewer" changed how users mentally modelled the tool, which changed mode selection, which changed how they interpreted the data. The most impactful decisions in this project were taxonomic, not visual.
Get actual operators into usability sessions earlier. Bridge engineers, HSE managers, control room supervisors. The audit was rigorous but expert-led. Lived operator intuition under real pressure surfaces edge cases that structured analysis misses.
