ASAP
Moving Oracle's twenty-year-old service-activation platform onto Redwood, redesigned around the three people who use it every day.
ASAP - the Automated Service Activation Platform - is Oracle Communications' provisioning engine, translating customer work orders into the commands that turn services on. For two decades the operator's window into it has been OCA, a Java applet whose design vocabulary predates the web.
Oracle's decision was a full redesign, not a reskin. I joined as the sole UX designer on a team that had never worked with a UX process. The hardest work wasn't the screens - it was bringing the team into that process, and earning the trust to drive IA decisions from it.
The situation
ASAP turns customer orders into network changes thousands of times a day. The window onto it was built twenty years ago, by engineers, for engineers.
Four things hurt. The experience is chaotic - to find a single order, a CSR fills in ten technical fields. The workflow is fragmented - people move across several screens to complete one order.
Decision points are unclear - nothing tells you what happens if you retry, abort or change something. And there's no operational visibility - nobody can see order health, progress, or where failures are happening.
Fallouts surface as raw switch commands. CSDL Information, Global Parameters and Work Order Details each open as blank tabs with no guidance about what to do next.
The landing page is an empty session log. The interface is recognizably twenty years of engineering-era additions layered on a Java applet whose interaction vocabulary predates most of the web.
ASAP sits in the middle of the chain. Upstream, OSM and UIM generate work orders and send them in. ASAP translates them into network commands, and as those commands run it sends events and responses back so the calling system knows what happened. Downstream, CSDLs and ASDLs configure ports and bring services live.
It isn't a supporting system. Every improvement to this experience pays off across the whole orchestration stack.
Three very different people rely on this tool every day.
Frank is a CSR. A customer is on the phone asking why their broadband isn't live. He needs to find the right order fast and explain it in plain language, with no technical screens and no jargon.
Stephanie is the Order Admin. She sits inside the system for hours diagnosing fallouts, editing parameters and retrying CSDLs, and needs to see the whole life of an order to correct it safely.
Parker manages operations. He isn't looking at individual orders - he's watching whether SLAs are at risk, where failures are clustering, and what tomorrow needs to look like.
The business driver for the rebuild is architectural: Redwood is where Oracle's product surface is heading, and two decades of accreted UI patterns need to be rethought from the user outward, not retrofitted.
The decisions that mattered
Four calls shaped the product, each made once the team and I had agreed what we were optimizing for.
ASAP had no peer designer inside the team, so my peer review happened externally at Oracle's quarterly Industry UX All-Hands. Inside the project the decisions below were mine to own, argued through a team that by then knew what good looked like.
The obvious answer was to build three apps. I argued against it.
Three apps would fragment one product, add downstream cost in engineering and training, and force the business to maintain three roadmaps against a single data model.
What I arrived at was one product with a shared data spine and three persona-specific surfaces on top - same work orders, same CSDL data, three different first screens.
Most teams jump from personas to wireframes. I inserted a step in between: a question-and-answer document per persona, defining the quantitative shape of their screens.
For the CSR, 5-7 fields per card, and 20 work orders per search page typically, capped at 200. For the Admin, a worklist of 50 before grouping kicks in.
For the Manager, 4-8 KPIs grouped Volume, Quality, Speed and Risk, on a 7-day trend window by default with 24h, 30d and 90d alternates. Across the product, 60 events a minute before the UI groups them.
These numbers determine whether a screen feels calm or chaotic. By making Shape of Data an explicit artifact, the team acquired shared vocabulary for density decisions. Engineering could build against the numbers; PM could scope with confidence.
Three performance and three satisfaction criteria per persona, each with a benchmark from observed OCA behavior and a target for the new build. These are design hypotheses, not shipped metrics - but they force every subsequent decision to answer: does this move the benchmark?
An earlier persona set treated Network Operations Engineer and Order Admin as two separate people. Engineering - who had lived with this product for years - surfaced that in practice they are the same user, with overlapping access and lifecycle responsibilities.
The collapse simplified role-based access control and gave that user a single coherent surface. Design leadership on domain-heavy products depends on listening to the team that has lived inside the data.
Four signature design moves
Four principles, four screens - each one turning a daily frustration into something the product now does well.
The IA rests on four principles: stepwise journey, information grouping, guided decision-making, operational awareness.
Frank used to ask which field he should even search on. He now has one search that returns the order, its status and the reason it failed - the right order inside thirty seconds, and a customer-ready answer inside a minute.
Stephanie used to fight six tabs to find the cause of a fallout. The CSDL timeline, the suggested fix and inline validation now live in one panel, so she can diagnose and correct in the same place.
Parker finds out about spikes after they have already breached SLA. The dashboard gives the Admin a live picture of failures; the proactive layer above it - configurable alerts, so a CSR escalation notifies the Admin and the Manager while there's still time to act - is designed and scheduled for phase two.
The moves below are what shipped. Parker's alerts are still ahead of us.
What I learned that changed how I designed
The process didn't exist inside the product before ASAP. Building it was the work that outlasted the screens.
My job wasn't only to produce screens. I ran collaborative working sessions where the engineers and I walked through each persona's day, one at a time.
I introduced Redwood not as a component library but as a shared language - conventions for guided processes, smart search, data tables and page shells the team could build against confidently.
Co-ownership is what made the process hold. Because the team was inside the work from day one, alignment wasn't adversarial - conversations focused on content feasibility rather than whether the IA was right. My job was to earn that trust by making rationale visible at every step.
Validation
Two loops: the team I worked with daily, and a room of Oracle designers who had never seen the project.
Internally, regular syncups with PM and engineering captured feedback and iterated on rationale.
Externally, Oracle's quarterly Industry UX All-Hands forced me to defend the Shape of Data numbers, the IA principles and the four signature moves to designers who hadn't been inside the project. Each round sharpened the argument.
Status
Three artefacts complete, the build in active development.
What the design is targeting
Design hypotheses grounded in observed OCA behavior, not measured outcomes. They become real metrics when the build reaches customers.
What I'd change
Two things I'd do differently: get real users in front of it sooner, and map the systems around it earlier.