Snapshot
Organizations responding to a data breach have to tell a regulator what was compromised, and they have to prove how they know. That means ingesting a potentially compromised dataset, classifying every piece of personal, health, payment and privileged information inside it, and producing a defensible record of exactly what was analyzed and when. I designed the platform that does it — a desktop-only uploader, per-job isolated environments, AI classification with a human in the loop where it matters, and an immutable audit trail. Shipped to production in two months.
MY ROLE:
Sole Product Designer
TIMELINE:
2 months · Q4 2025 – Q1 2026
TEAM:
PM, BA, architects, ~10 engineers
SCOPE:
4 surfaces · 4 user classes · bilingual
The problem
An organization that has just been breached is on a regulatory clock, and three things stand between it and a defensible answer.
Getting the data in. Breach datasets are large and arrive from compromised infrastructure. Browser uploads aren't built for transfers that run across hours or days of interrupted connections, and every alternative — SFTP, email, a web portal — widens the attack surface at exactly the moment the organization can least afford it.
Classifying it at all. Someone has to find every piece of personally identifiable information, protected health information, payment card data and legally privileged material across documents, spreadsheets, scanned images, and whole Outlook archives. Done by hand, that is months of analyst time during which the organization cannot answer the regulator.
Proving it afterwards. Legal teams need to demonstrate that a specific dataset was analyzed at a specific moment and hasn't changed since. Under GDPR, HIPAA and regional privacy law, the inability to prove that isn't an inconvenience — it's the liability.
The Constraints
2 Months
Timeline
Day-one readiness, no soft launch.
4 Roles
User classes
Client Users, Legal Counsel, Reviewers, Administrators.
Multi-region
Residency
Data residency set per client organization and enforced downstream.
2 Languages
Languages
Bilingual across all four surfaces.
Research
Stakeholder interviews across breach investigators, legal counsel and compliance officers, alongside a review of the requirements and the emerging data model.
Legal's requirement turned out to be narrower and sharper than "audit logging." They needed an immutable, timestamped cutoff — a moment after which the dataset provably could not change. Reviewers wanted density rather than clarity: as many classification decisions per screen as they could stand. Client representatives wanted progress and nothing else; they are not investigators and the platform shouldn't make them act like one.
The insight that changed the architecture: the four roles weren't variations on one workflow. A shared system with role-based visibility would have made every screen a compromise between four incompatible priorities — a reviewer's queue density is exactly wrong for a client checking status, and a client's progress view is useless to legal. That moved the design from one system with role gating to four role-specific surfaces over a common pipeline.
How I worked
The architecture was being written while I designed. Ten engineers, two months, and architects whose data model was landing about a week ahead of my screens — which meant any design assuming a different shape of data was dead on arrival.
So I worked against the requirements and the schema rather than a blank canvas. Before each flow I'd read what the API would actually return, design to that, and bring the cases where the response shape made the responder's job harder back to the architect as a specific request rather than a critique. Framing it that way mattered: an architect under deadline can act on "the reviewer needs these three fields in one response or they're clicking twice per document," and can't act on "this feels clunky."
I sequenced the work by what couldn't be retrofitted. Ingestion first, because it can't be re-architected once clients are mid-engagement. Isolation second, because it's structural and touches everything. Review efficiency last, because it can be optimized after launch without breaking anything. Testing ran in parallel rather than after — investigators, reviewers, and the legal and security teams concurrently — because two months doesn't allow a sequential validation phase.
The honest cost: designing to the schema makes you conservative. At least one screen shipped organized around what the system knew rather than what the responder needed to act on — the exact thing this case study argues against — because reopening the data model in week six wasn't worth the week it would have taken.
How I used AI
Wireframes: I generated early layout options with Claude, Figma AI, Uizard, Relume, UX Pilot and kept the strongest 2–3 for review.
Design system: I used AI to scaffold tokens (colour, type, spacing) and base components. I then set the rules, variants and states myself.
What AI didn't do: product decisions, trade-offs and final UI. Those stayed human.
Decision 1 — Make the desktop uploader carry the whole ingestion experience
With web, SFTP and email ruled out, ingestion happens in one place: a desktop application with secure, resumable transfer and no password login — activation instead.
What I rejected: treating the uploader as a utility and putting the real experience in the portal. That was the natural split — thin desktop tool, rich web UI — and it would have been wrong. The client is mid-incident and the upload is the part that can fail. So the desktop app got the full progress model, pause and resume, per-file state and error recovery, and the portal mirrors that state rather than owning it.
What it cost: real installation friction — download, install, version enforcement — imposed on clients having the worst week of their professional lives, plus a second application to design and maintain.
Decision 2 — Put the isolation boundary in the architecture, and keep access control on top of it
Each engagement runs in its own isolated environment with its own storage and its own keys. Zero-Trust RBAC runs across the whole platform on top of that, scoping every action to an organization and a job.
What I rejected: treating access control as sufficient on its own. RBAC is software, and software has bugs — a permission check is one misconfigured row away from exposing one breach victim's data to another. Permission checks fail open; architectural separation fails closed. So the boundary had to exist structurally, with access control layered over it rather than standing in for it. Defence in depth, and for this product the depth is the value proposition.
What it cost: materially higher infrastructure cost and operational overhead per engagement, and two access models to reason about in every screen.
Decision 3 — Make the dataset freeze a decision someone takes, not a log someone finds
A "Commit Dataset" action behind two-step confirmation that freezes the dataset and writes an immutable, timestamped audit record.
What I rejected: background audit logging, which is how most systems handle this and which asks nothing of the user. I made it explicit and deliberately effortful because the legal value isn't the log — it's the provable human decision at a provable moment. An automatic log records what happened. A committed freeze records that someone chose, which is the thing counsel can stand behind.
What it cost: friction in a workflow that already had plenty, and a confirmation step users disliked at first.
Decision 4 — Let the model flag, and make a person decide where it matters
Every file passes through OCR and AI classification before anyone sees it. Each label gets a confidence score, and anything below a threshold goes to a reviewer. Admins can set the threshold per category. Legal privilege is always reviewed, whatever the score, and every threshold change is written to the audit trail.
What I rejected: fully automatic classification. It was faster, and it would have answered the months-of-analyst-time problem on its own. I passed because it can't be defended. When a regulator asks why a record was or wasn't flagged, "the model decided" is not an answer counsel can stand behind. The opposite extreme, a person checking everything, brings the months back. So a human decision exists only where the model is unsure, and where being wrong can't be undone.
What it cost: a slower pipeline than full automation, plus a review queue, a force-review path and threshold settings to design, all inside a two-month build.
Design system
I built a shared component system for both surfaces, the web dashboard and the desktop collector: tokens for colour, type (Plus Jakarta Sans) and spacing, plus core components with variants and states (stat cards, finding cards, release-decision buttons, upload rows). AI scaffolded the first pass, and I defined the rules and documentation the developers built from.
The classification pipeline
Anomalies such as corrupted files, suspicious metadata and disallowed types go into a hold queue instead of blocking the pipeline. Validated files keep moving while reviewers decide whether to release, review or exclude each held item.
The design question underneath all of it: where does a human decision have to exist for the output to be legally defensible? Not everywhere, because that brings back the months of analyst time. Only at the points of genuine uncertainty, and at the points where being wrong is unrecoverable.
Validation
Legal approved the isolation architecture pre-launch after a threat-model walkthrough rather than a design review. The design was then reviewed against the applicable privacy regulations by the client's legal and compliance teams before launch.
Workflows were tested with breach investigators, reviewers and legal counsel concurrently rather than in sequence — two months does not allow a separate validation phase, so validation had to run alongside design rather than after it.
Influence, and what outlived the project
Legal wanted to own data isolation and specify it as an access-control matrix. I argued the boundary couldn't live only in permissions — a permission check is one bad row from a breach inside a breach product — and that it had to be architectural, with access control layered on top rather than substituting for it.
I set up weekly reviews with legal and the architects and walked them through the threat model rather than the designs. Legal approved the approach early, and that early alignment meant there were no late-stage architecture debates, on a timeline where a single one would have been fatal.
What came out of it was a method the team kept: inventory every constraint, map each to a specific design decision, sequence by retrofit-ability, build in parallel. Its value isn't speed — it's that everyone can see why each decision exists, which is what stops the same argument happening twice.
As the platform grew after launch, a junior designer took on follow-up screens. I set the patterns they worked from and reviewed their inner pages and modals, so changes stayed consistent with the system.
Outcomes
Designed and shipped a four-role incident response platform in two months, consolidating ingestion, classification, review, exception handling, retention and reporting into one system. Analysis that used to be manual analyst work now runs through one guided, auditable pipeline, with people deciding only where the model is unsure.
The platform is live in production with enterprise clients, and I still lead design on new features as they roll out. Client performance metrics are confidential.
Learnings
Regulatory constraint is free design direction. The isolation and residency requirements produced a better architecture than I would have argued for unprompted. The compliance surface did work that taste wouldn't have.
Sequencing by retrofit-ability is risk management, not planning. What can't be changed later has to be right first, even when it isn't the most urgent thing on the board.
An audit trail can be a feature. Building the freeze as a deliberate user action rather than background logging meant users understood it and legal trusted it — the same data, made legible by making it a decision.
What I'd do differently
I'd put a real breach investigator inside design iteration at week six rather than validating with them near launch. Their mental model of the review workflow differed from the one I'd built from interviews, and I caught it four weeks after launch. It was fixable. It shouldn't have needed fixing.
And I'd keep a decision log from day one. By week eight nobody could remember why specific architecture patterns had been chosen, including me. I now start one on every project — a habit that came directly out of getting it wrong here.