What is ACME Phoenix?
ACME is a decision analytics company that helps credit card companies detect fraud. Phoenix is their flagship platform : a SaaS console used by fraud investigators and their managers to review AI-flagged transactions and resolve them.
transaction
flags it
console
resolves it
Meet Adam Johnson
Adam is a fraud investigator. Every shift, he opens Phoenix to a queue of flagged cases : each one a real person, a real transaction, a real judgment call.
The Design Challenge
I owned the end-to-end investigator experience. Every screen Adam touches, from the moment he logs in to the moment he closes a case.
The Product Requirements Doc (PRD) had two layers to solve for:
Give Adam everything he needs to prioritize and work through his cases with speed and accuracy. The core challenge was information architecture: figuring out exactly what Adam needs to see, in what order, so every decision he makes is fast and confident. The cases Adam works are AI-surfaced, so the design had to account for how a human acts on, evaluates, and feeds back into an AI system.
Fraud investigation is repetitive, high-pressure work. Investigators burn out. They disengage. They leave. ACME needed a way to keep Adam motivated, growing, and invested in his own performance.
The five surfaces I designed
Designing for AI
ACME Phoenix is an AI-driven product. Every case Adam sees was surfaced by an ML model, and every decision he makes feeds back into it. I designed the human side of that entire loop.
Explainability and Trust in AI Output
- AI flags a transaction. Adam sees not just the flag, but the confidence score, flagging reason, and assigned queue.
- Designed the Case Details page to surface AI context prominently so Adam evaluates the prediction, not just acts on it.
- This is designing for explainability, helping a human decide when to trust the model and when not to.
Human-in-the-Loop Judgment Surface
- Adam's disposition (Confirm Fraud, Not Fraud, Unable to Confirm) is the ground truth signal the model learns from.
- Designed the full judgment surface: disposition controls, fraud type selector, confirmation flow.
- Every resolution Adam makes tells the model whether its prediction was right or wrong.
Model Monitoring and Oversight
- "Flag an AI Model" is one of Adam's four core jobs-to-be-done.
- When false positives spike, Adam can open the Flag Model flow, which surfaces FPR trend over time as a line chart.
- Adam submits a flagging reason directly to the data science team, a direct feedback channel from investigator to model owners.
The Full Loop
console
& repeat
Adam isn't just a user of AI. He's a check on it.
How I Designed It
Not just screens. A system. Before any interface decisions, I mapped out what Adam needs to do, what information supports those jobs, and how every surface connects.
I used Jobs-to-be-Done instead of user stories because Adam's core jobs don't change, even as the system around him does. Four target jobs emerged: resolve a case, flag a fraud pattern, flag an AI model, and manage his workload.
JTBD 01: Resolve a Case
JTBD 02: Flag a Case
JTBD 03: Flag an AI Model
JTBD 04: Manage & Prioritize Workload
The Object-Action Matrix translated Adam's jobs into the grammar of the system: every object he interacts with, and every action he can take on it. This became the foundation for consistent labels, controls, and navigation across every surface.
Object-Action Matrix
| Object | Resolve | Flag | Escalate |
|---|---|---|---|
| Case | ✦ | ✦ | ✦ |
| Queue | ✦ | · | · |
| Model | ✦ | ✦ | · |
| Investigator | · | · | · |
Transactional Attributes
- Case ID
- Case Status New · Open · Active · Closed
- Case Disposition Fraud · Not Fraud · Unable to Confirm
- Fraud Type First Party · Third Party
- Case Level Service · Account · Customer
- Created Date/Time
- Last Updated Date/Time
- Queue ID / Queue Name
- Assigned Investigator
- Priority Level High · Medium · Low
- ↳ Transaction
- Transaction ID
- Amount · Date/Time · Merchant · Location
- ↳ Customer
- PAN · Account ID · Name · Address
- Phone · Email · Fraud History
- Transaction History · Chat History
- ↳ Model (case generator)
- Model ID/Name · Confidence Score
- Queue ID · Queue Name
- Queue Priority High · Medium · Low
- Case List IDs of cases in queue
- Assigned Team / Investigators List
- Model ID / Name
- Model Version Number
- Model Creation Date
- Model Last Update / Training Date
- Investigator ID · Name · Photo
- Role / Seniority Level
- Shift / Work Hours · Team ID
- Cases Assigned · Queues Assigned
- Current Rank / Level
- Current Points (This Quarter)
- Lifetime Points · Badges Earned
- Active Challenges · Completed Challenges
- Training Assigned · Training Completed
- Kudos Given · Kudos Received
Analytic Attributes
Not everything Adam does carries equal weight. The priority matrix separated high-frequency tasks from occasional ones, ensuring the dashboard surfaces what Adam needs most, not everything at once.
Priority Matrix
| Priority | Tasks |
|---|---|
| High |
|
| Medium |
|
| Low |
|
Before touching Axure, I sketched the key surfaces to work out information hierarchy and layout logic on paper first.
Sketch 01
Sketch 02
Sketch 03
Sketch 04
Sketch 05
Every chart on the dashboard earned its place. The choice of chart type was always driven by the nature of the data: comparison vs. trend vs. progress.
| Metric | Chart Type | Why |
|---|---|---|
| Resolution Rate vs Queue Avg vs Dept Avg | Horizontal Bar | Comparing Adam's performance against two benchmarks; bars make comparison instant |
| Team Mission Progress | Progress Bar | Single metric tracking toward a goal; progress bars show completion most clearly |
| Case Timeline | Timeline / Stepper | Sequential events in order; shows causality and chronology better than any other format |
| Investigator Rank and Level Progress | Progress Bar | One metric, one goal; progress bar is the clearest choice |
| Merchant Fraud Count | Bar Chart | Comparing counts across merchants; bars not lines, because there is no trend, just comparison |
| False Positive Rate (AI Model) | Line Chart | Trend over time; line charts are correct for continuous change |
| Customer Spending Trend | Line Chart | Spending behavior over time; trend data needs a line |
| Leaderboard | Ranked List | Comparison across investigators; a ranked list with filter options (coins, accuracy, amount saved) lets Adam control what he's comparing |
Designing the System
Adam's day starts here.
Every shift, Adam logs into Phoenix and lands on his dashboard. This is his home base: a single screen designed to give him full situational awareness before he touches a single case. He can see his progress, his team's status, and his performance at a glance. No hunting, no clicking around. Everything he needs to orient himself is right here.
"Hello Adam" isn't just a nice touch. Showing his coin balance immediately connects his daily work to his progress, before he's even opened a case.
Cases resolved, fraud prevented, accuracy. Three numbers that answer the question every investigator asks mid-shift: is my day actually making a difference?
Adam works in a live system. Knowing when his dashboard was last refreshed means he can trust the numbers he's looking at.
Before he works, he understands where he stands.
The three cards at the top of the dashboard weren't placed arbitrarily. They're designed around the three questions Adam asks himself at the start of every shift, in exactly this order.
Where do I stand? Adam sees his current level, his progress toward the next one, and how many badges he's unlocked this quarter. Progress is visible before the work even begins.
What does my team need from me? The team mission card shows the goal, the deadline, the team's progress, and Adam's specific contribution. His work isn't invisible, it counts toward something bigger.
How am I performing? A horizontal bar chart comparing Adam's resolution rate against his queue average and department average. Not just a number, context that tells him whether that number is good or not.
Now he knows where he stands. Time to pick his cases.
The My Cases table is where Adam spends most of his time on the dashboard. It's not just a list. It's a fully structured workspace designed around every state a case can be in.
Each tab represents a different case state. Open cases are the default because that's where Adam's attention should go first: cases waiting to be worked.
Every column in the table earned its place. Each one answers either "should I work this case next?" or "what do I need to know before I open it?"
The most complex tab in the table. Assists has three nested tabs of its own, because assist relationships have three states that matter differently to Adam.
When Adam's ready to claim new work, the Queue Backlog shows every available case in the system. One button, Claim Cases, and it's his.
Cases where teammates are asking for Adam's expertise on a flagged transaction.
Cases Adam has accepted and is actively working on behalf of a colleague.
Cases where Adam has sent out his own assist requests and is waiting on a response.
A case ID is all it takes.
From anywhere in the dashboard (his My Cases table, the Queue Backlog, even a search result), Adam clicks a case ID and lands on Case Details. No extra steps, no navigation hunting.
The Case Details page is the most important surface in the entire console. This is where Adam does the actual work of fraud investigation: reviewing all the evidence, understanding the full picture of a case, and making a final call. Everything on this page was designed around one goal: give Adam everything he needs to make a confident decision without ever leaving the screen.
The first thing Adam sees is the priority and status of the case (High Priority, Active) as visual badges. Not buried in a table column. Right at the top, impossible to miss.
The action controls are also at the top of the page. Adam doesn't need to scroll to take action. The decision point is visible the moment he lands on the page.
Created date, last updated, last modified by. Adam always knows the history of a case before he reads a single piece of evidence.
Everything Adam needs. Nothing he doesn't.
Scrolling through Case Details, Adam moves through a carefully ordered sequence of information, each section building on the last, guiding him toward a decision.
Why was this case flagged? How much money is involved? Who is the merchant? These two cards answer the most urgent questions first, before Adam goes any deeper.
A chronological record of everything that has happened on this case. Adam can see the full history at a glance and add his own notes as he works.
Who is this customer and what did they say? The AI model's conversation with the customer is surfaced directly on the page. Adam doesn't need to go anywhere else to read it.
Has this customer been flagged before? Is the AI model behaving correctly? These two sections help Adam spot patterns and give him the tools to act on them if something looks wrong.
Is this transaction out of character for this customer? Is this merchant a repeat offender? The data visualizations here answer both questions without Adam having to do the math himself.
Adam's reviewed the evidence. Now he has to make a call.
Every case ends in one of four ways. Each path has its own flow, its own popup, its own outcome.
Assist
Adam selects a case disposition (Confirm Fraud, Not Fraud, Unable to Confirm Fraud, or Unable to Confirm Not Fraud) and if fraud is confirmed, specifies the fraud type. One click of the confirm button and the case is closed.
The confirmation popup does two things at once: confirms the case is closed and tells Adam exactly how many coins he just earned. The resolution is rewarding. Literally.
Adam decides the case needs to go higher. He hits Escalate, fills in the reason and any additional comments, and submits.
Escalation isn't just a button. It's a structured handoff. The reason field ensures the next person who touches this case has full context from Adam.
Adam spots something worth flagging: a pattern, a suspicious detail. He hits Flag Case, adds his reason and comments, and submits.
Flagging is Adam's way of saying "something is wrong here but I can't fully resolve it yet." The structured reason field makes sure that signal doesn't get lost.
Adam needs a second opinion. He opens the assist request, fills in the reason, selects who to send it to, decides how many coins to share as a reward, sets the urgency, and sends.
The coin share field is intentional: Adam has skin in the game when he asks for help. It keeps assist requests meaningful and not just a way to offload work.
Adam notices something the AI missed.
While working through his cases, Adam spots a pattern: too many false positives coming from the same model. He doesn't just resolve the case and move on. He flags the model.
Sometimes Adam isn't looking for a specific case. He's looking for a pattern.
The global search bar is persistent across every page. Adam types a name, a case ID, a customer, and the results come back organized across three categories instantly.
Adam's shift doesn't just end with closed cases.
The dashboard shortcuts aren't accidental: the Training Progress card links directly to Adam's Training Center, and the Rewards and Badges card links directly to the Rewards Hub. Progress is always one click away.
Adam can see his active modules, track his completion progress, and earn coins for finishing courses. Learning is part of the game.
Coins convert into real-world perks: gift cards, lunch with a manager, donation goals. The reward catalog makes the coin economy tangible and worth working toward.
Making It Better
Good design doesn't end at the first version. After design reviews with the stakeholder and subject matter experts, several opportunities for improvement emerged.
What changed:
- Status tags redesigned as pills, not buttons. Clearer visual language.
- Merchant Fraud chart corrected from line to bar, because this is comparison data, not trend data
- Search results refined for true federated results across Cases, Customers, and Investigators
- Assist flow fully prototyped end to end
- Dashboard card hierarchy made consistent across all cards
Before / After: Status tags
A small change with a clear visual language shift, from button-shaped to pill-shaped. Buttons imply action. Pills communicate state.
Before / After: Merchant Fraud chart
A line chart implies change over time. Merchant fraud count is comparison data: how many fraud cases per merchant. Switching to a bar chart makes the comparison instant and removes a false narrative of trend.
On tooling:
The designs were built following the SAP Fiori design system throughout: first prototyped in Axure, then migrated to Figma.
The migration wasn't just a tool switch. It was an opportunity to apply the design system more rigorously, refine visual consistency across every surface, and bring the designs to the production-ready quality they deserved.
Bridging Design and Engineering
I didn't just design screens. I documented them. Because I've been on the other side of a handoff. I know what it feels like to receive a design file with no context, no states, no edge cases, and be expected to build it.
So I made sure that didn't happen here.
The handoff documentation covers every surface, every component state, every dialog flow, and every data visualization decision, written so engineering could build without guessing.
Next Steps
ACME Phoenix was designed and prototyped as an academic project. But if it were a live product, the work wouldn't stop at handoff. Here's how I'd approach post-launch research and iteration.
What I'd want to know:
- Are investigators actually resolving cases faster?
- Where in the flow are they slowing down?
- What friction points are emerging that the design didn't anticipate?
- Is the system helping investigators make more confident decisions, or creating new sources of confusion?
How I'd find out:
Sit with investigators during a real shift. Real queue, real cases, real pressure. The goal: spot where the flow breaks down, what they work around, and what they reach for that isn't there.
Track what actually happens at scale. Key metrics:
- Average time to resolve a case by type and queue
- Which My Cases tabs get used most and least
- Drop-off points in the resolution flow
- Assist request volume and response rates
- Model flagging frequency over time
The numbers tell you what's happening. Contextual inquiry tells you why.
Outcomes & Reflections
ACME Phoenix is a production-ready fraud investigation console designed to help investigators like Adam work faster, make more confident decisions, and stay motivated through a demanding shift. The design achieves:
- A dashboard that answers Adam's three most important questions before he touches a single case
- A case details page where everything needed to make a call is on one screen, in the right order
- A full gamification layer that makes performance visible, rewarding, and worth competing for
- A global search experience that surfaces cases, customers, and investigators in one place
- A complete interaction system with consistent labels, actions, and patterns across every surface
What I'd do next:
Usability testing with real fraud investigators, because no amount of stakeholder review replaces watching an actual Adam use the system for the first time.
What this project taught me:
Empathy in UX isn't always easy. For most projects, I can put myself in the user's shoes because I've worn something close to them before. Adam was different. I've never sat in a call center with 40 cases waiting, a resolution timer ticking, and a team leaderboard watching.
That's the skill this project sharpened. Not just designing for users, but designing for lives you've never lived.