A digital evidence platform (consulting, name withheld) · 2026

Evidence platformTwo weeks on a video-redaction tool

A two-week consulting engagement to fix the video and audio redaction workspace inside a chain-of-custody digital evidence platform trusted by 400+ US law-enforcement agencies. Twelve issues found. Fourteen changes designed. One designer.

Role: Product design consultant, solo
Client: A digital evidence platform (consulting, name withheld)
Timeline: 2 weeks, 2026
Platform: Web: evidence management platform

Cover mockup comingA digital evidence platform (consulting, name withheld)

The context

The client is a digital evidence management system for US law enforcement and prosecutor offices: the platform where an agency puts its body-cam footage, phone dumps, CCTV, and case files, and where the chain of custody around every piece of that evidence gets tracked, automatically, so it holds up when it reaches a courtroom.

The product is used by more than 400 law-enforcement agencies and prosecutor offices, and its whole reason for existing is a promise the platform can defend: an automated, immutable audit log for every action taken on every piece of evidence. It meets CJIS, SOC 2, HIPAA, and FIPS compliance, and it’s hosted on AWS as a certified Public Sector Partner.

The engagement was narrow on purpose. The company brought me in as a product design consultant to focus on one thing: the video and audio redaction workspace, where an officer or paralegal blacks out a face, silences a name, and produces an export the court can rely on. Two weeks, one designer, deep in that one surface. The mandate:

Find every usability failure in the beta redaction editor by working through it as a real user would, not as a QA tester.
Design fixes that respect the platform’s compliance posture: a redesign that broke chain of custody or made an action untraceable was worse than one that shipped an ugly button.
Hand over prototypes engineering could ship from directly: screens, states, prototype links, reference sets.

How I audited it in two weeks

Two weeks is about the length of a new design lead’s first audit, and I ran it that way: map every issue, rank them by what could go wrong once the evidence reaches court, and name up front the principles every fix would be argued against.

Twelve issues in the beta editor: three critical, six moderate, three minor. The critical three were the ones that would let a court’s attorney embarrass an officer on the stand.

Critical finding 01, 'You can't actually read the transcript'. What I saw: every word sits in its own bordered box with its own checkbox; one sentence gets broken across five rows, and the speaker's name is repeated on every fragment. Why it matters: sensitivity lives in context, and when the sentence is fragmented, reviewers might fail to identify a name like 'Alexi', so it survives into a released file. What it breaks: recognition over recall, aesthetic and minimalist design. Beside it, the beta transcript redrawn, one word per box. — Critical 01: you can’t actually read the transcript.

Critical finding 02, '“Add Reason” is not discoverable'. The reason is hidden by default, with no signifier that the user must add one, even though the justification is the most important thing in evidence work. What it breaks: error prevention, visibility of system status, user control and freedom. Beside it, the beta controls redrawn. — Critical 02: “Add Reason” is not discoverable.

Critical finding 03, 'The count is all you get'. Tick Names, Phone #s or Addresses, or type a word into auto-detect; the detector matches exact spellings and hands back a count such as '15 found', with no way to inspect the matches. A nickname or a mis-transcribed address comes back with no matches, and the user approves the export believing the file is safe. What it breaks: visibility of system status, helping users recognise and recover from errors. — Critical 03: the count is all you get.

1 / 3

Every fix was argued against six heuristics I named up front: visibility of system status, error prevention, recognition over recall, consistency and standards, progressive disclosure, and Jakob’s law. Naming them first kept every change defensible in review, and gave the engineering team a lens to inherit. Fourteen changes came out of it; these five mattered most.

Key decisions

Decision 01

A transcript that reads like a transcript

On the table: One word per box, each with its own checkbox
Continuous sentences, the speaker named once
What I chose: Dialogue runs as continuous sentences, the speaker is named once and can be renamed to a real role, and detected terms are underlined and colour-coded where they sit.

Why

In the beta, every word sat in its own bordered box with its own checkbox, so one sentence spread across five rows and the speaker’s name repeated on each piece. Now a reviewer can judge sensitivity in full context: red for redacted with a reason, dark yellow for redacted without one yet.

The redesigned Audio & Transcript mode: the transcript as continuous dialogue by Speaker 2 (Officer), Speaker 4 (Resident), Speaker 1 (Supervisor) and Speaker 3, with flagged terms such as Alexi, daughter, a phone number and an address underlined in colour, and a Find panel reading '5 terms flagged'. — The transcript as a person reads it, with flagged terms marked in place.

Decision 02

Every redaction has to say why

On the table: A reason dropdown that appears only on selection
A global “Add reason” with a fixed list of justifications
What I chose: “Add reason” is a global control with a fixed list of accepted justifications. It says exactly what it’s about to apply to, and offers to cover the whole group.

Why

In the beta, the “Add Reason” dropdown appeared only when you selected something, and pushed the video and audio controls out of the way when it did. Now it always sits in the same place on the secondary bar, and nothing can be exported undocumented.

The video workspace with the Add reason control in the top bar showing a count badge, a person box on the video marked 'Person #01 · reason needed', and the Faces panel listing people with their status. — “Add reason” in one fixed place, naming what it will apply to.

Decision 03

Detection you can inspect, not just a count

On the table: A count of what was found
Every finding listed, with confidence and what still needs attention
What I chose: Each person or term gets its own card, with a confidence score, how often it appears, a warning where coverage is uncertain, and the same actions on every card.

Why

The beta said “101 tracked” and then gave a hundred time ranges in one block, or “15 found” with no way to see the matches. Now a reviewer can spend their time on Person #01, at 78% confidence with seventeen gaps, and move quickly past a clean 84%. Duplicates are suggested for merging, with an undo, and a review list filters what still needs a reason. Detection stops being a black box you either trust blindly or check all over again.

People and terms as cards, with confidence and what still needs you.

Decision 04

One workspace, two modes

On the table: Separate toolbars that change as you move
One header with a single mode switch
What I chose: A single header with one switch between “Video” and “Audio & Transcript” in the centre, and each mode’s controls in the same place on the right.

Why

In the beta, the video and audio toggle sat in the right corner of the secondary bar, with different toolbars on the left. Controls appeared and disappeared as you moved between them, and the audio options were duplicated onto the video tab. Now you stop re-reading the screen every time you switch, and where the reason, modes and controls live becomes second nature.

The same shell for both modes; only the tools change.

Decision 05

A redaction log that outlives the session

On the table: Leave the reasons in the editor
Export a redaction log with every file
What I chose: Every export produces a redaction log: each redaction, its time range, its treatment and its reason, as a downloadable PDF attached to the case.

Why

This was the change I fought for hardest. In the beta, the reasons for each redaction were never seen after export. Six months later, a defence attorney asks why a second was silenced, and the answer has to come from someone’s memory.

A log outside the export is a new artefact in the compliance chain: it has to be as tamper-evident as the export, travel with the case, and be legible to someone who didn’t create it. The easy design was to leave the reasons in the editor. The right one was to make them part of the record, so a challenge made months later is answered from the record, not from memory.

Export complete: 34_Axon_REDACTED.mp4 added to the case, a summary of what was redacted (8 objects blacked out, 2 audio segments silenced, 4 objects reviewed and left visible), a downloadable Redaction log (PDF) with every redaction, its range and its reason, and a note that the original file is unchanged. — The export receipt, with the redaction log attached to the case.

Results

The redesign was handed over in August 2026: 26 screens covering the full flow, 41 prototype links so a PM or engineer could walk it without opening Figma, and 3 reference sets explaining the intent, the mapped issues and the WCAG measurements. I’m still working with the client, and what happens to a design after handover on a compliance product is the client’s journey. I don’t have production usage numbers for this feature, and I’m not going to invent them.

What I stand behind from the two weeks:

All twelve beta issues were closed with a specific change and a heuristic behind it, including the smaller ones: search, select and redact in bulk; one “Detect” for both modes; progress that says “about 40s remaining”; a timeline that shows what’s left to do; warnings only when they matter; one export confirmation instead of two pop-ups; and selective redaction of a person’s time ranges.
The redaction log is a new compliance artefact the platform didn’t have before: the chain of custody isn’t just for the file, it’s for the reasons someone touched it.
The handover is measured, not just described. Every screen was sampled against WCAG contrast guidelines, with the numbers next to the beta build’s, so implementation doesn’t regress by accident.
26 screens and 41 prototypes in two weeks, solo, was possible because I worked with Claude Code as a design and prototyping partner. Iterations that would normally cost half a day, like rebuilding a variant or reflowing a component across states, took minutes.

The file viewer inside a case: the video with its transcript beside it, and Redact video and Redact audio buttons, both opening the same redaction workspace. — The way in: redact video or audio from the file viewer.

The video workspace while detection runs: 'Detecting all objects… 64%, 1m 28s elapsed · about 40s remaining', with a note that detection runs in the background. — Detection that says how long is left, and lets you keep working.

Audio & Transcript mode with a search for 'warrant': a checkable list of matches with speaker and timestamp, and Redact selected. — Search, select, then redact every match in one pass.

Back in the case after export: 'Redaction export complete, 34_Axon_REDACTED.mp4 was added to Case #2023-0510', and the file marked 'Redacted copy available'. — Back in the case, with the redacted copy ready.

1 / 4

What I learned

When the product is a compliance product, “the record” is a first-class user. A redaction reason that lives only in a session isn’t a redaction reason: it’s a memory that will be lost.
Naming the heuristics before the fixes is the single highest-leverage move for a two-week engagement. It kept every change defensible in review, and it gave the engineering team a lens that outlasts the consultant.
Two weeks is enough for depth on one workspace, and not enough for anything more. The scope was the design, not the ambition; discipline about the boundary was the whole reason the work landed.
A “small” change like progress you can actually read is only small on the specification: it is the difference between a user who trusts the system and one who doesn’t.

Credits

Design: myself, Product Design Consultant
Client: a digital evidence platform (name withheld), ongoing engagement

Evidence platform: Two weeks on a video-redaction tool