The brief
The brief
Oracle's expenses product was built for desktops and finance rules. Leadership wanted a mobile-first experience where corporate card charges arrive on their own, the system fills in what it can, and employees step in only when needed. The longer goal was to move customers off the legacy product entirely.
I came over from another team in the middle of the first build. The vision was well established and widely presented. The design behind it had years of reviews and several designers behind it, and still hadn't shipped.
What I found
The North Star screens were beautiful, but they relied on components the design system didn't have and behavior the frameworks couldn't support. Engineers were either filling the gaps themselves or unable to build to the design, and edge cases kept surfacing in build that the designs had never covered.
But there was also a more useful finding. Most corporate card charges need nothing from the employee: the card data is enough. So the work was focused on the exceptions. The app's real job is to sort expenses and ask only about the few that need human attention.
"Chris has shown an aptitude for being able to work very effectively across developers and PMs to design for all the corner cases our initial designs failed to uncover."
— Ray Weikel, DesignOps Manager
What I designed
Challenge: Every expense with an issue sent the employee to a full details page with possibly dozens of fields, the same pattern as the legacy product.
What I chose: A card that sorts each expense into Do Nothing (no human input needed), Do Little (three fields or fewer, fixed inside the card) or Do More (open the full details page). Cards cover each expense type, duplicates, and reversed charges, and let people skip or page through. Bespoke illustrations reinforced expense type recognition and trust.
What I rejected: Keeping the details page as the main path and adding shortcuts. It kept the legacy mental model and the legacy effort.
Result: Most issues resolve without leaving the card. Pilot feedback tuned messaging and actions, for example "Receipt needed" in place of "More info needed," and marking a charge personal from inside the card.
Challenge: The card that shows each expense, on nearly every screen, was a private branch of a component slated for design system adoption. It had deviated from the design system's approval pipeline, so it could only ship with a rare head-of-design exception, and no other product could reuse it.
What I chose: Rebuild it with the core design system team as an official component. I kept the basic structure people recognized and redesigned the rest: type size and weight, color, spacing, alignment, layout, icons and behavior. Each choice traced back to the parent component, design system guidelines, mobile constraints, and real data: long merchant names, optional values, indicators and badging rules. I designed much of it directly, guided the core team's designer on the rest, and had final say.
What I rejected: Keeping the private branch, which was fast for one team and costly for everyone after. In the design itself:
Extra spacing — rebuilt structure to reduce vertical spacing, in order to enable viewing of more transactions at a glance.
Multiple badges on one card — single badge improved focus and messaging consistency.
Out-of-pocket payment flag — replaced with more identifiable icon, and repositioned and reduced visual weight to allow expense amount to be easier to scan.
Prominent currency code — reduced size and visual weight to further improve amount scan-ability.
Result: After many rounds of review, it was approved as a standard component. It now shows transactions in Expenses and Approvals, and any product that displays a financial transaction can use it. The work also reopened an effective partnership between the core design team and product team, improving adoption of design system enhancements product wanted, including the receipt attachment chip, a mobile multi-select pattern, and mobile notification guidelines, which I guided to production with the same team.
"Through many, many rounds of iterations handed down by executive leadership, Chris was the steady voice of reason and technical guide throughout the project."
— David Topper, Creative Lead
Challenge: In the corporate-card pilot, about 13% of cards were past due and roughly 10% of early adopters had already paid late fees. The card program's administrators were hesitant to roll out more cards.
What I chose: I talked with a sample of late users. They weren't confused, just busy, and "touchless" had taught them nothing was required. I designed an overdue badge and a 14- and 21-day email prompt cadence, with one rule: the badge and the email always agree.
What I rejected: Two separate email designs, and softer labels like "Outstanding card charge." One consistent email was easier to maintain, and "Overdue" said plainly what was at stake.
Result: Email reminders shipped first, with push planned to follow. The broader lesson shaped the rest of the product: a "hands-free" system has to say clearly when it does need you.
How it earns trust
01
It says what it will do before it does it
"Will autosubmit on Friday" tells the employee the plan and leaves time to change it.
02
Defaults allow an easy exit
Marking a charge personal, deleting a duplicate, or undoing a merge are only one step away.
03
Warnings are obvious
In push notifications, meaning never relies only on an emoji or color. I flagged one risk early: a reassuring green check mark on a charge the system had auto-marked personal could lead someone to miss paying it.
04
We built in the signals
I partnered with the platform instrumentation team to pilot a pathing tool and shape telemetry practices for engineering. Usage data settled real debates: only about 11% of users touched filters, so filters gave way to sorting.
What happened
The first release shipped inside the design system's limits. From there I kept shipping improvements on every release while working on what came next: a messaging-based agent aimed at letting people handle 95% of expenses without opening the app.
What I'd change: I'd conduct additional user research to more fully explore the primary business and design hypotheses I inherited, push earlier for instrumentation capable of providing the signals we needed to test them, and ensure the findings were adopted early and given due consideration.
"Even amid shifting priorities, Chris stays calm, focused, and solutions-oriented."
— Tanya Rost, Senior Principal Technical Writer