Group 1001’s ONYX Project
Fraud Activity Prevention
AI Webflows and Prototyping | Data Driven User Centered Design
Designing an embedded fraud risk management system that replaced a siloed, reactive process with in-workflow visibility for contract servicing teams.
1.4M
Annual fraud losses driving urgency
0→1
Fraud lifecycle moved in-workflow
↓ Ops
Reduced cross-system lookups per case
My Role
Senior Product Designer
Team
PM, 1 designer, 3 engineers, 2 QA, Scrum Master
Timeline
Q1 2026 · Single sprint cycle
Scope
End-to-end workflow design, high-fidelity specs, prototype
CONTEXT
A complex risk problem buried in a fragmented process
Group 1001 operates in a B2B insurance model, servicing contracts through a combination of internal operations teams, customer service reps, and fraud investigation units (FOCE/SIU). When fraud or suspected scam activity targets a contract, multiple teams need to respond — but they were doing so across disconnected systems.
The ONYX platform is the company’s central contract servicing hub. Fraud tracking, however, lived with a completely separate system. This meant the teams closest to the contracts had no fraud context when making servicing decisions, and fraud investigators had no connection to the live contract data they needed.
Problem framing
The real problem wasn’t fraud — it was that no one could see it in context
“Every team had a piece of the picture. Nobody had the whole thing. Fraud investigators worked in one system, contract teams worked in another, and the gap between them is where things fell through.”
- Fraud flags records lived in a different system — invisible to contract servicing teams during live case work
- No consistent process for initiating, escalating, or resolving fraud flags across teams
- Prior fraud history on a contract was invisible at the point of servicing decisions
- Customer service reps handling inbound calls had no real-time fraud status to act on
- Investigations were inconsistent — each analyst had their own informal process
Strategic approach
Embed fraud risk into the contract experience — don’t build a better silo
Before defining the solution, I worked with Product and Operations to align on the core strategic question: do we improve the existing fraud portal, or do we integrate fraud management directly into the contract workflow?
A better fraud portal would have been faster to ship. But it would have preserved the same fragmentation that created the problem. I advocated for integration — making fraud risk a first-class part of the ONYX contract experience, so context traveled with the analyst instead of living in a tab they had to remember to check.
This shifted the frame from “build a fraud tool” to “make every contract risk-aware.” Four principles shaped everything that followed.
Principle 1
Make risk visible at the point of decision
Fraud context needed to surface where contract decisions were being made — not in a secondary system analysts had to navigate to separately.
Principle 2
Design for two audiences in one system
FOCE/SIU investigators and contract servicing teams needed different views and actions on the same data. Both had to be served without compromising either experience.
Principle 3
Optimize for clarity, not speed
In a compliance-sensitive environment, error prevention and audit traceability matter more than reducing clicks. Every interaction model had to reflect that.
Principle 4
Build the foundation, not the full vision
Phase 1 needed to establish reliable core workflows. Automation and predictive scoring were scoped to Phase 2 — adding them now would slow delivery without enough data to calibrate them.
What we chose not to build — and why
Early scoping considered building predictive risk scoring — surfacing high-exposure contracts before a fraud event occurs. It was the most exciting part of the vision. But without baseline data on how fraud flags were being initiated and resolved in-workflow, any scoring model would have been built on guesswork. I advocated for deferring it: establish the embedded workflow first, collect clean signal, then build prediction on top of real behavior. Phase 2 owns this.
We also considered a dedicated fraud dashboard as an alternative to embedding in the contract view. After prototyping both, it was clear the dashboard replicated the exact fragmentation we were trying to fix — analysts would still be switching contexts to check it. It was cut in favor of in-line contract integration.
Design process
From parallel systems to an embedded fraud lifecycle
Step 1 — Map the fraud lifecycle
Understand how fraud actually moves through the organization
Before any wireframes, I worked with FOCE, SIU, and Operations to map every stage a fraud flag passed through — from initial suspicion to investigation, escalation, resolution, and removal. This revealed two critical things: the lifecycle wasn’t linear (flags could be escalated before full investigation completed), and ownership was ambiguous at every handoff point. Any design that implied a clean sequential flow would misrepresent how the work moved and create false confidence.
This mapping exercise also surfaced which teams needed read vs. write access at each stage — a constraint that shaped the permission model and directly informed the architecture conversation with Engineering.
Step 2 — Where does flag creation live?
Cross-portal flag initiation and the architecture constraint
Case creation functionality that impacted contracts existed in a separate portal in ONYX. This created friction: context switching, incomplete initiations. Embedding flag creation directly in the contract page conflicted with the ERP’s existing case management architecture — a structural constraint that required Engineering alignment before any design decision could be finalized.
I used Figma Make to prototype both directions — maintaining the portal vs. embedding in ONYX — so stakeholders could see the operational implications of each, not just read about them.
Selected snapshots from ideation sessions — mapping friction points, exploring flow options, and aligning on architectural constraints with Engineering.
Step 3 — Remove Flag Placement
Balancing simplicity with audit clarity
The fraud flag needed to support three states: display current status, allow updates, and enable removal. The decision was between a single dropdown (simpler, fewer steps) and two separated flows (more steps, but clear audit trail). In a compliance-sensitive context, removing a fraud flag is an auditable action with legal significance — combining it with routine updates blurred a distinction the business needed to be explicit.
AI Exploration – Click on the link to see the prototype
AI-assisted exploration of the two interaction models in Figma Make — used to evaluate risk of user error, state clarity, and compliance implications before stakeholder review.
Step 4 — Final Handoff
Production-ready specs and Engineering partnership
Delivered high-fidelity designs with complete interaction documentation, lifecycle logic, and state handling guidelines. I partnered with Engineering during handoff to clarify edge cases and ensure implementation aligned with the intended fraud governance framework.
Final Prototype: https://visual-reduce-27624437.figma.site
Post-launch plan
This project was released on May 16, 2026 at the time of writing the case study. Post-launch metrics will be added once data is available.
Success will be measured through analyst adoption rate of in-workflow flag management, reduction in cross-system lookups per fraud case, fraud detection and resolution time, and operational efficiency across FOCE, SIU, and CSR teams.
The leading indicator I’m watching most closely: whether fraud flags are being initiated inside ONYX or still in the legacy portal. That number will tell us whether the integration actually changed behavior — or just added a new surface nobody uses.
Before vs after
| Metric | Before | After |
|---|---|---|
| Fraud visibility | Separate portal, invisible to contract teams | Embedded in ONYX contract view |
| Flag initiation | Manual, inconsistent, cross-system | Standardized in-workflow flow |
| Prior fraud history | Not visible at point of servicing | Surfaced inline on contract |
| Audit trail | Fragmented across two systems | Unified, traceable within ONYX |
| Investigation consistency | Analyst-dependent, informal | Standardized lifecycle with clear states |
Reflections
1
AI-assisted prototyping (Figma Make) accelerated stakeholder alignment significantly — but high-fidelity outputs early created expectation mismatches. I now explicitly frame exploratory prototypes as directional before every walkthrough, and build that framing into the project kickoff.
2
Bringing Engineering into the architecture conversation earlier would have shortened the iteration cycle. I spent time on an approach that Engineering could have flagged quickly as insufficient. Earlier cross-functional alignment prevents designing toward the wrong solution.
3
Deferring predictive scoring to Phase 2 was the right call for launch. But I’d want a clearer roadmap commitment before descoping a feature stakeholders care about — the Phase 2 plan should be documented and visible, not something that quietly stays out of scope.