Legal evidence · SaaS modernization

TrialDirector Cloud. A legal evidence platform, modernized without breaking trust.

Led design on cloud-transition workflows for a legal evidence platform where trust is the product. I designed the collaboration models, audit states, and developer-ready documentation that moved a legacy desktop system to the cloud without breaking chain of custody: the unbroken, provable record of who touched each piece of evidence. The defining craft moment: for critical actions, the screen never shows a change as done until the server confirms it, so a litigator can never act on something that only looks saved.

Led design on a legal evidence platform's move to the cloud, without breaking chain of custody: the provable record of who touched each piece of evidence. For critical actions, the screen never shows a change as saved until the server confirms it.

Legal tech SaaS modernization Audit and governance Design system Accessibility

Role

Designed core cloud-transition workflows, collaboration models, audit states, and developer-ready documentation.

Timeline

2022 to 2023.

Organization

IPRO.

Scope

Legal evidence platform. Design system across product lines.

01 The problem

Move to the cloud without breaking chain of custody.

Move a legacy desktop system to the cloud without breaking any of the things a trial depends on: the record of who handled each piece of evidence, the permissions that control who can change what, the way evidence is found and shown in court, and the trust of the people who use it. The product had to feel familiar to litigators while behaving correctly as a shared cloud system.

Why it mattered

This is a legal evidence platform used by litigation teams to manage evidence in high-stakes trials. In that setting, chain of custody is non-negotiable. A wrong state shown in the interface is a courtroom liability, not a cosmetic bug.

Who was affected

Litigators who carry twenty years of muscle memory in the legacy product, and the review teams who depend on audit trails and permissions holding correctly once the work moves to a multi-user cloud system.

The stakes

Evidence cannot be co-authored. A document is either admitted, redacted, withheld, or under review. The interface has to make those four states unambiguous, in the courtroom and on the way to it.

02 Discovery

Turn the rules of evidence into software logic.

Working the double diamond process, I widened first to understand the legal reality, then narrowed to the design. I partnered with legal subject matter experts and engineering to turn the rules of evidence into software logic, and mapped the evidence lifecycle from intake to courtroom so the cloud product behaves correctly under the rules litigators already work by.

Context

Employer project at IPRO. Enterprise legal technology platform used by litigation teams to manage evidence in high-stakes trials.

Insight that shaped the work

The product had to feel familiar to litigators while behaving correctly as a shared cloud system. Discovery mapped the full life of a piece of evidence: from the moment it enters the system, through search, review, annotation, and redaction (blacking out protected information), to how it is presented in court. That path became the structure the design had to respect.

03 Strategy

Make server-confirmed truth the product.

Every significant decision is documented as a mechanic, the operational reason behind it, and the tradeoff it accepts. In a legal evidence system, the interface must never show a state the server has not confirmed, and it must preserve the workflow litigators already trust.

Role and authority

First designer on TrialDirector. Designed the core cloud-transition workflows, collaboration models, audit states, and developer-ready documentation.

Key design decisions

Mechanic	Operational why	Tradeoff
Accept and Reject queues, not concurrent editing	Evidence cannot be co-authored. A document is either admitted, redacted, withheld, or under review. The interface has to make those four states unambiguous.	Slower than Google Docs-style flow. Right for chain of custody and for what happens when a reviewer is wrong.
Two surfaces: Workbench and Presentation Mode	The dense day-to-day surface and the courtroom surface have different consequences. Mixing them produces either an unusable dashboard or an unsafe courtroom view.	More design system maintenance. Buys clean separation of operator complexity from courtroom clarity.
No optimistic UI on critical actions	If the server has not confirmed the state, the user must not see the state. Optimistic confirmation is a courtroom liability.	Microseconds of perceived speed. Repaid by trust and by not displaying false truths to a litigator.
Preserved legacy terminology and folder metaphors	Twenty years of litigator muscle memory is an asset, not a UX problem.	Less stylistic freedom in the IA. Buys near-zero retraining cost in the new product.

04 Solution

Two surfaces, one trustworthy cloud product.

A high-density Workbench and a simplified Presentation Mode as two separate surfaces with different responsibilities. Strict Accept and Reject queues, hard-coded evidence states, and a design system that refuses to display a state the server has not confirmed.

What I did

Partnered with legal subject matter experts and engineering to translate evidentiary rules into software logic.
Defined collaboration models, audit-ready review states, role-based governance, and an evidence lifecycle from ingestion to courtroom presentation.
Designed around ingestion, metadata normalization, OCR search, redaction, multimedia handling, annotation, review, approval, and presentation.
Implemented strict Accept and Reject queues instead of Google Docs-style concurrent editing.
Hard-coded evidence states to remove operational ambiguity.
Designed a high-density Workbench and a simplified Presentation Mode as two separate surfaces with different responsibilities.
Retained legacy legal terminology and folder metaphors to preserve expert muscle memory.
Rejected optimistic UI for critical actions so the interface reflected server-confirmed evidence states only.

Walkthrough · Figma tour

Figma walkthrough of the TrialDirector design work. Evidence review, Accept and Reject queues, immutable state logic, and the change log surface. 2022 to 2023. Video not loading? Open in Loom ↗

TrialDirector case selection screen with Coke v. Pepsi as the active case.

TrialDirector · Case selectionCase selection is the first state a litigator enters. The list view exposes court case number, internal case number, trial date, and status as discrete fields. No free-form text. Each row is operable, every action is explicit.

Evidence review showing a synchronized media exhibit alongside a transcript with revision markers.

TrialDirector · Synchronized media and transcriptThe reviewer surface ties media playback to transcript line-state. Highlights are server-confirmed revision states, not user-local edits. A reviewer cannot mistake an unsaved comment for an accepted change.

Evidence review showing two synchronized text exhibits side by side with highlighted transcript lines.

TrialDirector · Text exhibit synchronizationSame review surface, text exhibit instead of media. The pattern stays constant so a litigator's eye does not relearn the layout between exhibit types.

Side-by-side annotation surface showing two versions of an exhibit with the annotation tool active.

TrialDirector · Side-by-side annotationAnnotation is locked to two surfaces side by side. One canonical pattern, accessible keyboard model, no concurrent editing on a single document. The interaction matches the legal workflow, not a Google Docs metaphor.

Change log surface listing fact additions and creations with creator name, timestamp, issue name, and cast member.

TrialDirector · Change log and auditThe change log is the audit posture made visible. Every fact addition has a creator, a timestamp, an issue, and a cast member. The screen makes operational accountability the default.

Evidence review tool palette and revision history with Accept and Reject controls.

TrialDirector · Reviewer toolsetStrict Accept and Reject queues, not concurrent editing. Edit and View are surfaced as terminal operations, with redaction as a state. The interface refuses to display a state the server has not confirmed.

A document exhibit shown inside the evidence review surface.

TrialDirector · Document exhibitDocument exhibits render with original layout retained. Legacy folder metaphors and terminology preserved deliberately so twenty years of litigator muscle memory transfers to the cloud product.

Responsive evidence review at smaller breakpoint.

TrialDirector · Responsive review surfaceThe dense Workbench breakpoint adapts without leaking Presentation Mode patterns into operator workflows. Two surfaces, two responsibilities, one design system.

The design system underneath

Underneath TrialDirector sits the IPRO design system. Same employer, same legal-tech domain, 2022 to 2023. A WCAG AA system that standardized data grids, dialogs, interaction patterns, navigation patterns, accessibility tokens, and engineering handoff so every product line builds against the same primitives. Product lines were fragmented by acquisition and parallel development, and rebuilt the same dense legal patterns independently. Data grids, dialogs, annotation, and timeline surfaces diverged. Accessibility was inconsistent. Engineering handoff slowed every cross-product initiative.

Role and authority

First Product Designer on new projects at IPRO. Partnered with engineering leads across product lines, accessibility, and QA stakeholders.

What I did

Contributed to a WCAG AA design system for a complex legal tech suite.
Standardized complex data grids, dialogs, interaction patterns, and navigation patterns.
Created reusable patterns for dense enterprise legal workflows.
Scaled accessibility design system patterns across the product suite.

Key design decisions

Mechanic	Operational why	Tradeoff
Canonical Fact and Annotation patterns	Evidentiary detail must read the same across product lines or reviewers lose trust in the suite.	Less per-product visual novelty. Buys one review model everywhere.
Accessibility tokens on dense grids	Legal data grids are the daily surface. Contrast, focus order, and keyboard model cannot be per-screen decisions.	Higher component specification cost up front. Repaid in audit and QA cycles.
Shared timeline primitive	Chronology and audit history used to be three implementations. One primitive removes redundant engineering.	Timeline may not fit edge cases without extension. Still cheaper than three forks.

IPRO · Timeline patternA timeline pattern shared across products. Standardizing this surface removed three competing implementations and let engineering reuse the same component for evidentiary chronology and audit history.

IPRO Fact pattern for evidentiary detail.

IPRO · Fact patternThe Fact pattern is the unit of evidentiary detail. Locking it down at the system level meant every product line presents facts the same way to a reviewer.

IPRO · AnnotationAnnotation interaction was the most-repeated surface across the suite. One canonical pattern, accessible, with the same keyboard model everywhere.

IPRO basic table component showing header, row, and cell primitives with the design system token treatment.

IPRO · Table primitivesHeader, row, and cell primitives for every data-dense surface in the suite. Defined once with tokens for color, contrast, focus order, and keyboard model so legal grids do not re-specify the same decisions on each product line.

IPRO highlight and redaction color tokens used for marking and obscuring evidentiary text.

IPRO · Highlight and redaction colorsSystem-level tokens for highlight and redaction on evidentiary text. One palette across product lines so reviewers read the same emphasis and obscurance states everywhere, not a per-screen color decision.

IPRO design system overview showing components, patterns, and tokens organized as a unified library.

IPRO · Design system overviewA single source of truth across the product lines. Components, patterns, tokens, and surface inventory organized so engineering and design build against the same primitives.

IPRO lists and menus showing selection lists, dropdowns, and menu interaction patterns.

IPRO · Lists and menusSelection lists, dropdowns, and menu interaction patterns standardized across the suite. One canonical interaction model means a reviewer's muscle memory works the same way regardless of which product surface they're in.

05 Outcomes

Designed the cloud transition; team and product retained by Reveal Data.

Each outcome below is sourced from internal case material and sized to evidence. These are design outcomes, not a claim that the product shipped to market or that the work caused the acquisition.

Designed A cloud-based TrialDirector workflow that preserves audit posture, chain of custody, and operational safety.

Designed Concurrent multi-user collaboration with role-based access control and review-state governance.

At acquisition IPRO and Logikcull were acquired by Reveal Data in a combined $1B+ transaction. My TrialDirector cloud-transition work at IPRO was still in design, not shipped, at that point. Logikcull, where I was the first designer, had already shipped.

Post-acquisition Reveal Data retained the TrialDirector team after acquiring IPRO, so the product continues under Reveal Data.

Delivered IPRO design system unified complex data grids and interaction patterns across product lines.

Live in the Reveal product The advanced search builder and keyword builder I designed are part of the Reveal product today.

What this shows

Enterprise legal workflow design where chain of custody is non-negotiable.
Cloud migration without breaking twenty years of operator muscle memory.
Design decisions that refuse optimistic UI on evidence state.
TrialDirector team and product retained by Reveal Data after the acquisition.

Confidentiality Screenshots are sanitized. Sample names, dates, and content shown in the product UI are placeholders.

Pedestrians crossing the Brooklyn Bridge in motion blur beneath its stone arches. — Field note 05 · Brooklyn Bridge, New York

Next case study

Apply to Education. Hiring flows, management, and a new Performance Improvement Plan product.

Get in touch Resume (PDF)