Case study
OneTrust
Issues Management shipped after a year of engineering with no UX involvement. Its largest enterprise clients were running the work in JIRA and Excel instead.
The situation on arrival
Misclassified issue records across the customer base, estimated by our VP of Product. Each is potential audit exposure.
Organizations on the platform this migration flow was designed to serve.
Pilot customers (Workday, John Deere, Woolworths) rejected the first version and stayed on their existing tools and spreadsheets (Excel, Archer, Power BI, SharePoint).
What was stated
Adoption was low and clients were resistant to change. Change management was taking too long, and the largest accounts had gone elsewhere. Workday, John Deere, and Woolworths were tracking issues in JIRA and Excel. The read inside the business was that the product needed to be easier to adopt.
Issues was meant to connect Assets, Vendors, Audits, Ethics, and Incidents product verticals. The connections were half-formed. No migration path existed for the 420M records already in the system.
What was actually true
I ran six internal interviews with power users, including the Chief Trust Architect, InfoSec, and GRC specialists, then six validation sessions with enterprise clients, among them Workday, John Deere, and Woolworths. In parallel I diagrammed the current state across about a dozen interconnected verticals, and my Staff UX Designer counterpart audited how those verticals actually connected.
No UX research had gone into the pilot. The people who knew this domain best had never been consulted, so their knowledge never reached the product.
Clients hadn’t rejected the features. They’d rejected a one-way door. Their workarounds guarded against irreversible mistakes: at John Deere, converting a risk to an issue is permanent and drops fields; at Woolworths, creating records in bulk doesn’t keep the links between them; and these records can carry legal weight. My read is that teams kept their spreadsheets and re-keyed by hand because a wrong move was hard to undo.
So the question changed from “is the product good enough?” to “can they get back out, and how much control do they actually have?” A migration no one can reverse is one no compliance team will approve.
Change management takes too long. We're already using JIRA and Excel.
What changed
The migration became three stages, each one designed so a compliance team could stop and verify before committing.
Attribute mapping. Map data fields from Risk to Issues, handle required against optional, and flag conflicts before anything moves.
Workflow configuration. Map workflow stages with parent and child relationships, with save and draft so work can pause. One client asked what would happen with 100 workflows, which moved the pattern from horizontal mapping to a vertical accordion that holds any volume.
Execution. Select risks, migrate with full reversibility through a recycling bin, no data duplication. Any authorized user can resume where another left off, which matters when time-poor analysts pause work and hand it on.
The pilot teams that had rejected the first version responded positively to the migration flow, and I handed it to engineering.
Enterprise validation sessions, run with the clients who had walked away.
Organizations the migration specifications were written to serve.
Each independently reversible before commit.
-
Stage 1 Attribute mapping: data fields mapped from Risk to Issues, with conflicts flagged before anything moves. -
Stage 2 Workflow configuration: parent/child workflow mapping, with save-and-draft so work can pause. -
Stage 3 Execution: risks selected and migrated with full reversibility through a recycling bin.
The pivots that defined the design
Three decisions turned a broken modal experience into a migration system built for enterprise scale.
Pivot 1
Full-page vs. modal
There was too much data for a scrollable modal to hold. I moved the flow to dedicated full-page steps with a persistent stepper, so people kept their orientation and control through the whole migration.
Pivot 2
Save state, draft mode
Analysts are time-poor, splitting attention across hundreds of records. Migrations needed to survive being paused and handed to someone else. Any authorized user can pick a migration back up exactly where someone else left it.
Pivot 3
Accordion compression
One client asked what would happen with 100 workflows. That question moved the pattern from horizontal mapping to a vertical accordion that holds any volume without losing legibility.
What if we have 100 workflows?
Delivered
The dashboard and relationship map had been a roadmap request during my time at OneTrust. After I left, I built both as interactive prototypes with dummy data, exploring what visibility could look like for a Senior Compliance Analyst. I shared them with two former teammates who knew the request from my time there, a staff UX designer and a principal data visualization designer, and both gave positive feedback.
Where it stopped
I left OneTrust in October 2024, after handing the work to engineering. What I handed off: the three-stage migration flow, a working prototype validated across six client sessions, and pattern documentation covering accordion compression, save state, and reversibility.
Three former teammates who stayed on the team have since told me a narrower slice shipped. I wasn’t there to see it land, so I can’t speak to adoption. What I can speak to is the design: the pilot teams that had rejected version one responded positively to this flow.
Alongside this, I mapped the holistic system with four peer designers: a staff UX designer, two principal UX designers, and a senior UX designer, and contributed concept work for SpeakUp’s investigation workspace (see the SpeakUp case study).