Unified Assurance

Imagine AT&T's Dallas NOC. A network engineer sees an alert: a regional router in New York is dropping packets at 3:47am local. The alert came from a sensor that pinged the device, found a threshold exceeded, fired an event into the service assurance platform. If the platform is doing its job, that event reaches the engineer with enough context to diagnose, triage, and fix before customers in New York wake up and notice their service degrading.

Unified Assurance is Oracle's platform for that work. It sits downstream of device monitoring and upstream of ticketing - the layer where raw events become triaged signals. For years the platform did the work but the UI lagged. Legacy screens built over time; patterns from different eras stacked next to each other; new engineers onboarding took weeks to learn what each view actually did.

Oracle's decision was to rebuild UA onto the Redwood Design System - part of a broader modernization of Oracle Communications' product surface. I joined as the only UX designer on a team that had never previously worked with a UX function.

Fig. 01 · The NOC reality - engineers monitoring a wall of undifferentiated alerts. The "sea of red" that framed the redesign.

On UA I am the only UX voice - there is no peer designer in project meetings. My peer review happens externally: in Oracle's quarterly Industry UX All-Hands, where designers across Oracle's industry portfolio review the work, and in internal Communications syncups with adjacent design groups. Inside the project, the decisions below weren't argued against competing UX positions. They were calls I made because the team didn't yet have the context to frame the tradeoffs - and trusted once I made the reasoning visible.

Fig. 02 · The same platform, rebuilt on Redwood - dashboard, event management, device discovery and the Vision coverage map.

UA isn't a single screen - it's a set of surfaces that together form the NOC's day, split across two personas. The Admin sets the system up and keeps it healthy; the NOC engineer lives in monitoring and triage. I designed them as one coordinated system, sequenced so a customer is onboarded before they ever reach the monitoring surfaces. Sitting across all of them is the agentic layer - the Network Operations Assistant - which is where this work is heading next.

A NOC engineer's hardest moment isn't seeing that something is wrong - it's deciding what to do about it, fast, while alerts pile up from every direction. The newest and most current work on UA is an agentic operations experience: a Network Operations Assistant that helps an engineer investigate, prioritise, and resolve a fault situation, with AI doing the correlation and the engineer keeping the judgment. I own the design of this agentic experience end to end.

A situation isn't one device fault. It correlates many events across multiple devices into a single working hypothesis anchored to one device - so instead of reading a hundred alert rows, the engineer reads one story. The design challenge was never "add AI." It was making AI output something an engineer under pressure can actually trust and act on.

I structured each situation around the six questions a NOC engineer asks, in the order they ask them: what's broken (root cause), how bad and who's hit (service impact), how long have I got (SLA impact), what's the evidence (event pattern), is it getting worse (affected metrics), and can I act (readiness). The layout follows how an engineer reads and works a page, so even a beginner can understand the situation and act with confidence.

The agent assigns the right situations to the right engineers by skillset - and an engineer can request a different situation if the assigned one is beyond their depth. When they're ready to act, they can send a communication to the field or apply the recommended resolution directly from the situation, guided by an AI action summary.

The principle I kept returning to: an AI finding has to be accountable. Every card shows its work - the claim, the signal behind it, the evidence it came from, and the action it enables - so a recommendation reads as "here's why," not "trust me." I also cut things that failed that test: an evidence balance bar that implied a weighting the data couldn't support, and any language suggesting the system had acted when it hadn't. That honesty is the difference between an engineer acting on the AI and quietly ignoring it.

Fig. 04 · The Network Operations Assistant - the engineer's briefing home, surfacing open situations and forecast risks with recommended priority actions.

Fig. 05 · One situation open - each card answers a question the engineer asks and shows its evidence, so the AI recommendation reads as "here's why."

UA has no dedicated design peer inside the team. Validation happens across three venues, all external to the project itself.

Oracle's quarterly Industry UX All-Hands is where I present the work to designers across Oracle's industry portfolio. That venue forces me to defend Shape of Data numbers, IA principles, and the "Ask Oracle" suite-nav decision to designers who weren't in the rationale. Each round sharpens the argument.

Internal Communication syncups with Oracle Communications' broader design groups are the second loop - same register, tighter cadence. The third loop is the Quarterly Infrastructure Design all-hands, where UA's surfaces get reviewed alongside other Oracle infrastructure products for consistency.