Fraud Alert Detection
Designed a step-by-step disposition flow that replaced manual cross-referencing across disconnected systems.
Two systems. No connection.
One accountant stuck in the middle.
When applicants applied for credit, accountants had to manually cross-reference information across two separate platforms. No connection between the systems. No guided process. Just a person bridging the gap. That's what the team called swivel chair work.
Look at one screen. Remember something. Look at another screen to cross-reference. Slow, inconsistent, and easy to miss things. The accountant was doing the system's job manually.
The company had recently implemented a new fraud detection system capable of communicating with the existing intranet. The technology was there. The workflow wasn't. There was no guided process to help reviewers move through a disposition. No clear path for what to do next. No way to know if a critical step had been skipped.
Two types of alerts needed two completely different responses. The system treated them the same. Users didn't know what to do with either.
Required investigation and cross-system verification. Likely led to application denial. Needed careful documentation at every step.
Required acknowledgment before approval. Needed a fast, clean path. No investigation. Just confirmation and close out.
The new feature flow — bringing both systems together into one guided workflow
This wasn't a redesign. It was a new feature that had never existed before. The goal was to eliminate the manual bridging entirely and bring both systems together into one guided workflow.
What I owned
Influence without authority is still influence.-
Led UX on a new fraud detection workflow within the company's internal credit system
-
Mapped the existing process flow to understand how accountants currently handled fraud alerts
-
Collaborated closely with the Business Analyst to understand domain requirements and system constraints
-
Worked with the development team to map data fields, technical constraints, and business rules
-
Designed the step-by-step disposition flow and adaptive workflow for both alert types
-
Presented an alternative design approach to the BA and gained organizational buy-in
Understand the system before you design the interface.
Before designing anything I had to understand how the systems actually talked to each other. This wasn't a simple interface problem. It was a systems problem.
Working with the Business Analyst and the development team, we mapped the full ecosystem. Which data fields were needed to adjudicate. How the fraud detection system communicated with the intranet. What the business rules were for each alert type. Where the decision points were and what happened downstream from each one.
That mapping work was the foundation. Without it any interface we designed would have been built on assumptions. The complexity of the system required us to understand it fully before committing to any design direction.
Mapping the full user and system flow before any design work began
The BA came into the project with her own concept for how the interface should work. Her initial idea was modeled after an existing data management tool in the system. I raised three concerns directly with her.
-
01
Identity confusion. Copying the existing tool's UI would confuse users about where they were in the system. The data management tool has its own distinct identity. Making the new feature look like it would blur that boundary.
-
02
Cognitive load. The task page and the review page already had different interfaces. Adding a third pattern would increase cognitive load for users moving between them.
-
03
Design system violation. Her proposed behavior of opening actionable items in a new browser tab was outside the design system entirely.
I asked if she was open to seeing an alternative. She was. I walked her through a proposed flow that addressed all three concerns while meeting her business requirements.
She embraced it. Her endorsement was what got broader organizational buy-in. Sometimes the best design move is showing someone a better path and letting them choose it.
Four calls that shaped the workflow.
A stepper over a free-form interface
The disposition process had a specific sequence. Data review first. Disposition decision second. Close out third. A stepper made that sequence explicit and gave users a clear sense of where they were at all times.
Especially important when waiting 1 to 3 days for System 2 to return data on actionable alerts. Users needed to know the task was on hold and why. The stepper made that visible.
The 3-step disposition flow
Step 1 — Data Review
Step 2 — Disposition
Step 3 — Close Out
Two distinct paths over one universal flow
Actionable and non-actionable alerts required completely different cognitive modes. Designing them as two separate flows, while keeping the same three-step stepper structure, meant users always knew where they were. The interface adapted to the task. The task didn't have to adapt to the interface.
Progressive disclosure over upfront complexity
Not every reviewer needs to see every option. What appears on screen depends on the decisions already made.
Select Not Actionable in step 2 and the interface shows a list of reasons to choose from. Select Actionable and it shows a checklist of systems that were reviewed. The close out step adapts the same way. Each path only surfaces what's relevant to that specific decision at that specific moment.
This kept the interface from feeling overwhelming. It also made it harder to skip critical steps. The system guided reviewers through the complexity without showing all of it at once.
Alert list — items requiring disposition
Alert list — items completed
Design system consistency over a quick fix
The BA's original proposal borrowed patterns from another tool and introduced a new browser tab behavior. Both would have created inconsistency. Staying within the design system wasn't just an aesthetic call. It was a usability call. Users on this platform move between tools constantly. Consistency is how they stay oriented.
The swivel chairs are gone.
Reviewers no longer had to cross-reference systems manually. Both systems now talk to each other through one guided workflow.
Two distinct paths. No confusion about what to do next. The notification alert told reviewers when System 2 data was ready.
Progressive disclosure made it harder to skip steps. The system guided reviewers through complexity without showing all of it at once.
The new feature fits seamlessly into the existing platform. No new patterns introduced. No cognitive debt added.
For transparency, we never got the post-launch data. The dev team went quiet after handoff. But the workflow we delivered was validated before launch, tested with users, and built on a foundation of real system understanding.
Sometimes the outcome is the work itself. A complete, validated, system-integrated workflow that replaced a manual process. That's what we delivered.
What stayed with me
-
Understanding the system before designing the interface wasn't extra work. It was the work. Every good decision in this project came from that foundation.
-
Influence isn't the same as authority. I had no authority over the BA's vision. But by showing up with evidence, a clear rationale, and respect for her domain expertise, the design moved forward on its merits.
-
The best solutions don't just fix the interface. They fix the process underneath it.