Simi Kaur
Sample CSI

Designing Software That Helps Police Preserve Evidence in Court

View live prototype

Timeline

Jan – Apr 2026

Role

Product Designer

Team

5 students

Tools

Figma
Figma
ChatGPT
ChatGPT
Claude Code
Claude Code
Granola
Granola

TLDR;

Problem

Officers were documenting evidence across disconnected systems — notebooks, spreadsheets, and photos — with no reliable way to capture the details that matter. Small mistakes in chain-of-custody records could compromise cases in court.

Solution

Designed SampleCSI from 0→1: a platform with adaptive forms, AI guardrails that surface what officers might miss, and linked evidence relationships — so teams can document reliably under pressure.

01The Problem

The problem wasn't digitizing paperwork. It was preserving trust.

Early in our research, we learned that evidence collection is messy, high-pressure, and inconsistent between agencies. Officers were documenting information across notebooks, spreadsheets, photos, and disconnected systems. Small mistakes — like missing timestamps or unclear chain-of-custody records — could create serious issues later.

At first, we thought the challenge was mostly about efficiency. But interviews and artifact analysis shifted our perspective. The real problem was reliability under pressure — officers weren't just filling out forms. They were trying to build credible narratives from chaotic scenes.

From officer interviews

We need to document and secure evidence in a way that maintains chain of custody from the moment we collect it.

Chain of custody is critically important. If it's broken at any point, the evidence may not be admissible in court.

Your notes are only as good as the person writing them. If you miss something at the scene, there's no going back.

02The Design Challenge

How do we help officers document reliably under pressure without slowing them down?

Preserve chain-of-custody integrity at every step

Work fast enough to not slow officers down in the field

Build records reliable enough to hold up if challenged later

03Constraints

Designing for inconsistency became the hardest constraint.

The Tradeoff

A system flexible enough to handle inconsistency, without losing structure.

There wasn't a single workflow to design around. Different agencies documented evidence differently, used different terminology, and prioritized different information. Standardized flows kept getting more limiting the more artifacts we reviewed.

That led to four core features:

Dynamic forms that adapted based on evidence type

Dynamic forms that adapted based on evidence type

Custom fields for agency-specific workflows

Custom fields for agency-specific workflows

Progressive disclosure to reduce cognitive overload in the field

Progressive disclosure to reduce cognitive overload in the field

AI-assisted prompts that helped officers avoid missing critical details

AI-assisted prompts that helped officers avoid missing critical details

04Key Design Decision

AI as guardrails, not automation.

As we learned more about evidence collection workflows, we kept running into the same issue: officers needed to document information quickly, but missing even a small detail could create problems later. We explored more automated documentation flows early on, but the deeper we got into the problem space, the less comfortable full automation felt. In a workflow built around accountability and chain of custody, fully AI-generated reports felt more likely to create distrust than confidence.

Instead of generating reports, the system acted more like a set of guardrails. If an officer documented a knife, the interface could surface prompts they might otherwise forget — details about handling, location, or related evidence. The goal wasn't to replace human judgment, but to support it.

So we intentionally designed AI to stay in the background.

05Key Design Decision

The biggest pivot came from something we didn't hear in interviews.

One of our most important insights came late in the process. During synthesis, we realized evidence rarely exists in isolation — a blood sample connects to a weapon, a fingerprint to a broken object. None of our interviews explicitly revealed this; we uncovered it through artifact analysis and workflow mapping. Once we saw the pattern, we redesigned the case summary experience to support parent-child evidence relationships. We explored several directions:

A traditional table view

A traditional table view

A folder/tree structure

A folder/tree structure

A linked-card model

A linked-card model

We chose the linked-card approach because it preserved fast scanning while still making relationships visible at a glance.

Final linked-card case summary design
06Key Design Decision

Usability testing exposed where clarity mattered more than features.

There was one recurring issue that came up in usability testing: language. Terms that felt obvious to us weren't obvious to officers. We made a series of targeted refinements that improved comprehension and flow. One participant summed it up well: 'This would make our work faster.'

1

Redesigning the 'Activity Log' to a proper 'Chain of Custody' section with important information upfront

Activity Log — before

Before

Chain of Custody — after

After

2

Adjusting the status indicators to match terminology used in the industry today

Status indicators — before

Before

Status indicators — after

After

3

Changing 'Parent/Child' to 'Primary/Secondary'

Parent/Child terminology — before

Before

Primary/Secondary terminology — after

After

07Final Outcome

The final system balanced structure with flexibility.

While SampleCSI isn't live yet due to funding limitations, usability participants consistently described the system as faster and easier to navigate than current documentation processes.

08Using AI

AI also became part of how we built SampleCSI.

There was something a little meta about this project: we were designing an AI-assisted tool while actively using AI tools ourselves. That wasn't the original plan, but it became one of the more interesting parts of the process.

We used AI tools to:

  1. Synthesize interview transcripts
  2. Brainstorm information architecture
  3. Build high fidelity prototypes
  4. Draft usability testing scripts

Each of those tasks had a different character. Synthesis was actually the one that humbled us first. We fed in raw transcripts expecting organized, usable themes and got back output that sounded polished but felt generic — it missed the deeper patterns actually emerging from our interviews. We ended up stepping away from the AI-generated summaries and returning to manual affinity mapping to find more grounded insights ourselves.

Brainstorming was more useful for breaking logjams, even when the suggestions weren't right. Prototyping with AI was the most surprising: it could produce realistic UI in minutes, which let us test more directions than we would have otherwise. Drafting testing scripts required the most oversight — the outputs were plausible but often leading, framing questions in ways that pointed users toward the right answer.

ChatGPTClaudeGranola

We used ChatGPT for broad brainstorming and quick iteration. Claude was better for longer, more structured tasks where we needed it to hold a lot of context at once. Granola handled meeting notes and kept our synthesis sessions from disappearing into a folder no one opened again.

The biggest thing we learned was that AI worked best when we already had a strong point of view. When we came in with a clear question, we got useful output. When we came in vague, we got confident-sounding noise. And when we leaned on it too early — before we had done the hard interpretive work ourselves — it gave us the illusion of progress without the substance.

That changed how we structured our working sessions. We started front-loading more alignment work between team members before involving AI, and we got more deliberate about returning to our own research to evaluate whatever it generated.

Ironically, that mirrored one of the core ideas behind SampleCSI itself: AI worked best as augmentation, not replacement.

09Reflection

I learned that workflow design isn't really about screens.

It's about understanding how people make decisions under pressure. If I revisited this project, I'd spend more time validating edge cases earlier, especially around evidence relationships and multi-agency workflows. Our biggest pivot happened relatively late, and earlier questioning could have surfaced it sooner. This project also changed how I think about usability testing — watching users hesitate in real time taught me that clarity often matters more than feature depth, especially in high-stakes environments where confidence and speed are tightly connected.