1. The Products & The People

Oracle Financial Crimes Compliance Management — FCCM — is a suite of four products built to protect financial institutions from some of the most consequential risks in banking: money laundering, fraudulent transactions, bad actors slipping through onboarding, and customers who aren’t who they say they are.

Each product serves a different analyst with a different job:

• Emma investigates suspicious activity patterns to detect and prevent money laundering. 
• Andrew evaluates flagged names and entities to identify the real bad actors — not just noise. 
• Alice reviews transactions in real time to eliminate fraudulent ones before they clear. 
• Nikki verifies customer profiles before onboarding or when risk flags surface later.

Same suite. Same compliance stakes. Four completely different workflows, mental models, and definitions of “done.”

That’s what made the audit both necessary and complex — the goal was never to make these products look and behave identically. It was to find what they should share, fix what was broken through drift, and build toward a coherent system without flattening what made each one distinct.

2. Understand the Users

Before auditing the products, I started where I always do: the people using them.

Each of the four iHub products serves a different analyst with a different definition of success. Emma needs to detect suspicious patterns before money moves. Andrew needs to separate real threats from false alarms — fast. Alice needs to clear her transaction queue without letting a fraudulent one slip through. Nikki needs to verify who a customer actually is before they’re onboarded, or when risk surfaces later.

Same compliance stakes. Four different mental models. That distinction mattered — because coherence across these products couldn’t mean sameness. It had to mean alignment.

3. The Problem

Each of the four iHub products had been designed and evolved independently. The result was a suite that felt fragmented: inconsistent layouts, divergent component usage, and interaction patterns that varied without clear reason. Analysts moving between products had to mentally re-orient each time — an unnecessary burden in a domain where speed and accuracy carry real compliance stakes.

The mandate wasn’t to redesign from scratch. It was to diagnose the system — identify what was broken through drift, what was legitimately distinct, and what a coherent foundation could look like across all four products without flattening the differences that actually mattered.

4. The Audit

The first move was making the scope visible.

I mapped the anatomy of each product’s primary case summary — identifying every section, flagging what was shared, what was inconsistent, and what was missing entirely. The result was an interactive Figma inventory linking every finding across all four products, used as the shared reference artifact throughout design reviews.

The four products represented four very different starting points. AML (Anti-Money Laundering) had been built by PMs and developers without a designer — functional, but with little design system foundation and significant drift from Redwood patterns. 

CS (Customer Screening) was leaner and more focused, but missing a critical interaction its core workflow demanded.  

TF (Transaction Filtering), which I had previously designed, had already established a strong pattern through the collection details page template — one of the most complex flow templates in the Redwood Toolkit — requiring analysts to compare each flagged transaction against watchlist details before taking action.  

KYC (Know Your Customer) was the most recently redesigned product, the most complex in scope, and the most coherent — but with six sections, several unique to its workflow, it had grown in ways the other products hadn’t kept pace with.

What connected TF and CS wasn’t just structural similarity — it was a shared judgment model. Both products ask analysts to evaluate multiple items side by side and make a high-stakes compliance call. TF requires analysts to compare flagged transactions against watchlist details before blocking or releasing. CS requires analysts to compare multiple screening events against a customer’s details to determine whether a match is a true positive or a false positive. Same judgment model. Different data. And in CS, no design system template existed to support it.

To go deeper, I analyzed each shared section field by field. The Case Overview — displayed in the header of every product — became a clear illustration of how far the drift had gone. The same core fields appeared across all four products, but their treatment was inconsistent: Case ID appeared as a title in two products and as contextual info in the other two. Status was a badge in three products and a read-only label in one. CS, TF, and KYC all surfaced too many fields at the header level, creating visual overload at the exact moment analysts needed to orient quickly.

Each finding fed directly into a design consideration. For the Case Overview alone, the path forward was clear: standardize the header pattern, limit contextual info fields, and move secondary information into a Case Details drawer.

One gap, however, had no existing solution anywhere in the Redwood design system.

5. The Design Solution

From Audit to Architecture

The audit findings pointed to a clear direction: the four products needed a shared structural foundation — not identical layouts, but a common template flexible enough to accommodate each product’s unique workflow without fragmenting the experience further.

Before moving to high-fidelity design, I explored four layout concepts in box wireframes, stress-testing how to balance shared structure with product-specific needs. The core tension was information density: analysts need enough context to make confident decisions, but too much on a single page creates cognitive overload at exactly the wrong moment.

The resolution was a foundational Case Summary template — a flexible structure built on Redwood components, with a defined set of common sections every product would share, and designated areas where product-specific sections could live without disrupting the overall pattern.

With the template established, I applied it to each product, plugging in real data and product-specific sections. AML received a redesign grounded in the new template — bringing design system foundation to a product that had previously been built without one.

KYC, already the most coherent product, was refined to align with the shared structure while preserving its unique sections: High Risk Events, Adverse Media Scan, and Associated High Risk Entities. TF, which I had previously designed with the collection details template, required no structural changes — it had already set the standard the others were now reaching toward.

That precedent mattered beyond TF itself. The collection details template had already solved a core interaction challenge: how to present multiple items for sequential review within a single case flow. When the audit surfaced CS’s missing interaction model, I recognized the same underlying pattern. TF had already proven it was solvable. CS needed its own version — one built around customer screening events rather than transactions, with a different data model and a more explicit judgment prompt. That recognition is what made the CS solution possible.

6. The Invention

The Gap No Template Could Fill

Customer Screening had a problem the general template couldn’t solve on its own.

Andrew’s core job — identifying real bad actors — requires comparing multiple screening events against a customer’s details and making a True Positive or False Positive call on each one. This isn’t a passive review. It’s an active, sequential judgment with direct compliance consequences. And no template existed anywhere in the Redwood design system to support it.

I designed the CS Comparison flow from scratch — a net-new interaction pattern that became a Redwood design system contribution.

The flow works like this: when a case is flagged, the system surfaces the number of possible matches and frames the task clearly — “We’ve flagged 3 possible matches. Decide whether each is a True or False Positive.” The analyst works through each event one at a time. Customer details stay fixed on the left. Each screening event loads on the right, with AI-surfaced match quality — High, Medium, or Low — guiding where to focus attention first. Matched attributes are highlighted with visual confirmation. The analyst decides: True Positive, False Positive, or Skip. The progress counter updates in real time. When all events are resolved, the system confirms completion and prompts the analyst to make a final case-level decision.

The design solves three things simultaneously: it structures a high-stakes judgment task into a clear sequential flow, it surfaces AI confidence signals without making them prescriptive, and it contributes a reusable template to Redwood that any product with a comparison interaction can now build on.

This flow was showcased at Oracle Design Week 2025.

7. Outcome

The audit delivered what it set out to: a clear diagnosis of what was broken across four products, a shared structural foundation to move forward from, and targeted interventions that respected each product’s distinct workflow. All four redesigned products are now live in production as iHub — Oracle’s Investigation Hub for Financial Crime and Compliance Management.

The contribution that traveled furthest was the CS Comparison page template. Designed to solve a specific gap in Customer Screening, it was reviewed and accepted into the Redwood design system — making it available not just to Oracle’s internal product teams, but to any organization building on Oracle’s public Redwood design system. Teams across Oracle have already expressed interest, and a use case file is actively growing.

On opening day of Oracle Design Week 2025 — Oracle’s largest annual gathering of designers, held across 12 cities globally with approximately 30,000 attendees — the CS Comparison flow was hand-picked by Jenny Lam, SVP of Oracle Design, to be showcased as an example of design excellence. It was one of the first things the global Oracle design community saw that week.

The Financial Crimes team requested me back for a subsequent project — the Scheduler product — a signal that the work had earned trust, not just approval.

8. Reflection

What made this project consequential wasn’t the number of screens redesigned or the number of products audited. It was the decision to treat a product consistency problem as a systems problem — and to solve it at the system level.

The audit made the problem legible. The template made the solution scalable. The CS Comparison flow filled a gap that no one had formally identified as a design system gap until the audit surfaced it. And the chain of impact — from a single finding to a Redwood contribution to a global showcase — is what Principal-level work looks like when the framing is right.

The constraint I was given — bring coherence without erasing what makes each product distinct — turned out to be the most useful design brief I could have received. It forced precision over uniformity. That’s a harder problem, and a more honest one.