Breaking a 3-Year Stalemate
2022–2025 · Enterprise SaaS · Financial Operations · Oracle
Shipped Oracle's first Redwood mobile experience after a multi-year design impasse
My last shipped designI 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. Five designers. Zero launches.
The product was caught between a platform team enforcing strict Redwood compliance and a product leader pursuing visionary concepts that might justify a native app—or at least push Redwood into mobile-native territory.
The PWA architecture was locked before I joined. The existing vision work wasn't buildable within it. And the team had a reputation for ignoring process.
I needed to figure out which parts of the vision were worth fighting for, which constraints were genuinely immovable, and what a path to production actually looked like when you stopped pretending otherwise.
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 hardest tensions in this product was that it ran on Oracle's Redwood design system, which was built primarily for desktop and had minimal mobile pattern support. We had to use Redwood's components as-is — for launch. But I laid out a roadmap of key enhancements that would get us closer to the experience people expected from their phones, while acknowledging the limits of an enterprise PWA.
The card idea itself was contentious. Stakeholders were firm in the belief that this pattern was the best way to 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. Monitoring usage demonstrated my concerns and resulted in product committing to a real solution for this and other sacrifices.
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 started as damage control became a model for how Redwood-compliant work could get done on this and all mobile projects. The team with a reputation for ignoring process ended up establishing a process others followed.
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
Leadership had legitimately competing priorities. Both were reasonable, but neither fully compatible. My job was to find the overlap where something real could ship and each side could see their work reflected in it.
One vision for what comes next↪ Coda
No one likes doing expenses — especially when outside the office
Years of resources were allocated to creating a consumer-grade mobile expenses app. Stakeholders were convinced that this was the best route to achieve the “touchless” vision.
When real usage data showed a consistent decline in mobile usage — the first users were stakeholders, so they were all-in on the mobile approach — it was assumed the usability sacrifices were the culprit. If we could just fix the design issues, people would use the mobile app.
Wrong.
Extensive user feedback, interviews, and guerrilla contextual inquiries made clear this was not a design problem. People simply had no interest in doing their expenses when away from their desk. Travelers were rightfully focused on their primary job, their customers, and their getting to their next destination. Others just saw expenses as work, a banal task to be done at the office.
In retrospect, it would have been valuable to have explored the mobile hypothesis more thoroughly from the git go. Next time.
Data visualization or usage chart showing the consistent decline in mobile expense app usage over time — the evidence that proved the core assumption wrong