Oracle’s First Agentic Expense Experience
2022–2025 · Enterprise SaaS · Financial Operations · Oracle
Shipped Oracle's first Redwood mobile experience after a multi-year design impasse
I established the decision framework that reset this product's direction—auditing design-system constraints, evaluating tradeoffs with engineering, and defining what to preserve, simplify, or cut so the product could ship.
↪ Impact
✓ Shipped to first enterprise customers within 9 months
✓ Scaled from 26-user pilot to 450 cardholders within 6 months — 1,200 within 2 years
✓ First Redwood mobile product in production + integrated telemetry
✓ Rebuilt platform-product trust while delivering targeted innovation
↪ The Problem
Three years. Multiple explorations. One product vision still looking for a shippable path.
The product sat at the intersection of two valid priorities: a platform team committed to Redwood compliance and a product vision pushing toward a more mobile-native, touchless experience. The PWA architecture was already set when I joined, and much of the existing vision work had been created under a different set of assumptions. My job was to identify what to preserve, what to adapt, and how to move the product into production without losing the ambition behind it.
Three years of vision work. None of it shippable within platform constraints.↪ The Pivot
Long Live Chat
The long-time vision had been for users to interface with expenses via mobile notifications and an enhanced chat UI. However, just after joining the team, that vision hit a wall. Design leadership cancelled all work on chat components, leaving us to quickly reimagine the experience. Without chat, the responsive app would have to take center stage.
Only months away from the planned pilot launch, my task was to bring as much of the polished “touchless” experience to the PWA — quickly.
Sacrifices would have to be made, but that’s okay. By shipping we could collect real data to map a realistic route to our product vision.
The chat vision that hit a wall. Without it, the responsive app had to carry the entire "touchless" promise.↪ My Approach
♠︎ Diagnosed
Mapped six non-compliant patterns across hundreds of instances to understand exactly where the real friction was.
♣︎ Rebuilt
Restored cross-functional trust by demonstrating compliance and adopting the platform team’s own established process.
♦︎ Negotiated
Identified ten innovations scoped for platform adoption. Showing the vision with real constraints was more persuasive than pure aspiration.
♥︎ Delivered
Shipped the core touchless flow first. Delivery earned far more credibility than any vision decks of mocks.
Example blocker — expense receipt attachment↪ The Design
1. Phone screen density
The core interaction surface is the expense card — the thing users see most and tap most. It needed to carry merchant name, amount, date, category, receipt status, and policy flags without feeling like a data table shrunk onto a 375px screen.
I used a clear visual hierarchy: merchant and amount dominate (they're what the user cares about first), status sits in a chip component that changes color and label based on state, and policy information stays hidden until it's relevant.
The goal was a card you could glance at and know "this one needs attention" or "this one's fine" without reading anything.
The expense card and list of expenses at a glance2. Making enterprise feel mobile-native
One of the central tensions in this product was that it ran on Oracle’s Redwood design system, which at the time was still evolving its mobile support. For launch, we worked within the available component model while also identifying the enhancements needed to better support mobile usage over time. That work helped clarify where Redwood could expand, where the product needed stronger native support, and how enterprise mobile patterns could mature going forward.
The card idea itself was contentious. The belief was the pattern would help us achieve a consumer-grade experience. However, Redwood had no such component. To get across the finish line, I devised a short-term workaround — one with usability tradeoffs. Usage data and implementation learnings gave the team a clearer basis for prioritizing future improvements in both the product and the design system.
Usability issues identified and prioritized to determine what needed to be resolved for launch and what could be scheduled for future design and releasePhased release plan for design improvements aligned with availability of features and Redwood enhancements3. What "touchless" actually means in practice
The product's name — Touchless Expenses — makes a promise: minimal manual effort. But the reality of expense management is messy. Receipts come in different formats, OCR isn't perfect, and policy rules vary by expense type, currency, and geography. The design challenge was making the system feel effortless when automation succeeds while providing clear, non-punitive paths when it doesn't.
When a receipt is automatically matched to a credit card transaction, the user sees a clean, resolved card — no action needed. When there's a mismatch or a missing receipt, the card surfaces a gentle prompt with a clear action. I was careful to avoid the trap of making error states feel like the user did something wrong — in most cases, the system failed, not the person. The tone of every status message reflects that.
When automation succeeds, the card is clean. When it doesn't, the prompt is gentle. The system failed, not the person.4. Telling users they might be in trouble — without making the app feel punitive
Expense policy is the third rail of this product. Employees need to know when their spending might not be approved, but nobody wants to use an app that feels like a compliance officer looking over their shoulder.
I partnered closely with our own policy team to understand where we had room to smooth the process and where we were limited by regulation. We also surveyed customers to understand their policy considerations.
I used progressive disclosure to layer policy information: the card shows a simple status indicator, and only if the user needs to take action does the interface present an edit or justification flow, revealing related policy info. This keeps the happy path clean — most expenses are fine, and users shouldn't have to wade through policy language for every coffee receipt. But when something does need attention, the information is there, clearly written, and the required action is obvious.
Exception handling had to be as touchless as possible, while remaining fully compliant with corporate policy and government regulations↪ The Outcome
From Stuck to Flagship
What began as a difficult delivery challenge became a useful model for how Redwood-compliant mobile work could move forward. The product launched, telemetry was integrated, mobile patterns were pushed further inside Redwood, and the work created reusable learnings for other teams exploring similar constraints.
The pilot launched in April 2023 with 26 users, growing to 450 in six moths and over 1,200 by the two-year mark. Redwood adopted new mobile patterns and other teams leaned on our work for their own mobile initiatives.
↪ The Takeaway
This work sat at the intersection of platform discipline, product ambition, and delivery reality.
My role was to find the version that could ship, generate learning, and preserve the larger intent behind the vision.
One vision for the next evolution of the mobile app↪ Coda
Mobile or not, the product was a success
The mobile product generated an important kind of value beyond adoption. It gave the team a live environment to validate the touchless model, test AI-assisted flows, reduce technical variation, and gather real usage data instead of relying on assumptions.
What we learned was useful: employees did not consistently want to manage expenses away from their desks, but they did benefit from stronger automation, clearer status communication, and more accurate handling of expense data.
Those insights strengthened the desktop direction on the new Fusion platform, improved the underlying product and AI capabilities, and helped expand Redwood’s ability to support more sophisticated enterprise workflows in the future.
In that sense, the mobile effort was not a dead end. It was a proving ground that clarified where the product created value, where usage naturally belonged, and which platform and design-system investments would matter most going forward.
Data visualization or usage chart showing the consistent decline in mobile expense app usage over time — the evidence that proved the core assumption wrong