Unified Assurance
A Redwood rebuild of Oracle's service assurance platform for telco NOCs, now extending into an agentic Network Operations Assistant.
Unified Assurance is the platform telco Network Operations Centers use to catch faults before customers notice them. I joined as the sole UX designer on a team that had never worked with UX before.
My job was to move an engineering-era platform onto Redwood. The first guided module has shipped and beat every time ceiling we set for it. But the harder half was building the UX practice the team needed to maintain it after handoff.
The situation
The platform was doing its job. The interface it did it through had accumulated a decade of patterns, and nobody could learn it quickly.
Imagine you've just opened a new office. Every router, switch, server and firewall in it is state of the art.
The office is in New York. The people responsible for keeping it running sit in Dallas, fifteen hundred miles away, watching dashboards around the clock. So when an interface drops at 3:47am, or a CPU spikes, how does Dallas know? Nobody can walk down the hall and look.
That's what Unified Assurance is for. Every device is monitored in real time, and the moment something changes it's captured, correlated and sent to the NOC as one view - the bridge between the equipment and the people accountable for it.
It sits downstream of device monitoring and upstream of ticketing, the layer where raw events become triaged signals. For years it did that job while the interface lagged behind: legacy screens built over time, patterns from different eras stacked next to each other, new engineers taking weeks to learn what each view did.
A NOC engineer works a quota of 50+ event resolutions a shift, against a screen of alerts with no clear prioritisation.
Oracle's decision was to rebuild UA onto the Redwood Design System. I joined as the only UX designer on a team that had never previously worked with a UX function.
What shipped
Guided Network Discovery is live. We set time ceilings for every task before designing, and the built experience came in at half of them.
Discovery is the first thing a customer does with UA, and the point at which the platform either earns trust or loses it.
The old experience was built around a single device type. A specialist worked down a pile of configuration steps and technical inputs, and the hard part was never any individual field - it was knowing where you were in the process and what happened next.
The redesign brings configuration, progress and job management into one journey. The guided flow breaks configuration into steps and surfaces the technical detail one task at a time. Once a job exists, its status, schedule, progress and history live in the same place. It stopped being a sequence of forms and became a job lifecycle.
Before any of it was designed, I set an explicit time ceiling for each task in the flow - the number we committed not to exceed. These are the results measured against the built experience.
Phase two added a filter builder ahead of monitoring. Specialists need to combine several technical conditions, and that logic becomes unreadable fast, so the filter previews its result before you commit - which removes the apply-it, wrong, start-again loop.
The remaining surfaces are in active design and development: Vision, Dashboard, Event Management and Device Management in build, Installation and Onboarding in design as the customer-handover surfaces.
The decisions that mattered
Three calls shaped the product, all made without a peer designer in the room to argue against.
The team had never worked with a UX function, so there was no shared language for arguing a design decision. I ran workshops on clarity of purpose: what is the user trying to do, what decision do they need to make, what information supports it. Once that language existed, we set the guardrails together.
So the decisions below were mine to own, but they weren't made in a vacuum. They were made with a team that by then had the context to hold me to them.
The intuitive order was to tackle the highest-traffic surfaces first - Event Management and the NOC Dashboard, where engineers spend most of their day. I argued for the opposite.
I sequenced Admin surfaces first, because those are the moments when a customer becomes a user. Get them right and adoption compounds; get them wrong and the most polished dashboard never gets reached.
Before any wireframe on UA, I wrote Shape of Data documents per surface - quantitative definitions of how much data each view would hold, how many events per minute, how dense the dashboard could get before it became noise. Engineering built against numbers rather than sketches. PM could scope with confidence. Every design argument had a reference point.
The obvious move was to bury it as a help icon. I made it primary navigation, sitting at the top of every UA surface - and the same pattern now propagates across the Unified Operations Suite: Assurance, Fulfillment, Service Design.
In a product surface this broad, users don't know which screen holds the answer. Conversational search wasn't a nice-to-have; it was the navigation model that made the suite coherent.
The six surfaces
Six surfaces, two personas, one sequence - designed so a customer is onboarded before they ever reach monitoring.
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 monitoring. The agentic layer sits across all of them.
That sequence came out of re-architecting the application's experience model. I mapped the current state and a proposed state for every admin journey - onboarding, landing, device management and discovery, and day-to-day fault operations. Discovery is the clearest example of the shift.
The agentic layer
The assistant correlates a hundred alerts into one situation, and shows its evidence for every claim so an engineer under pressure can act on it.
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 Network Operations Assistant helps an engineer investigate, prioritise and resolve a fault situation - AI doing the correlation, the engineer keeping the judgment. I own this design 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. The layout follows that sequence, so even a beginner can read a situation and act with confidence.
The agent assigns situations by skillset, and an engineer can request a different one if the assigned situation is beyond their depth. When they're ready to act, they can message the field or apply the recommended resolution without leaving the situation.
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.
Validation
With no design peer on the team, the work is defended quarterly to designers across Oracle who were never in the rationale.
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 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.
Two tighter loops follow: internal Communications syncups, and the Quarterly Infrastructure Design all-hands where UA is reviewed alongside other Oracle infrastructure products for consistency.