Charlotte-Mecklenburg PD - Case management, and the reviewer who wasn't in the room

Thesis: We built one of the most rigorous record-review pipelines I've seen in government software - four checkpoints across three roles. The most important reviewer was still missing from it.

For the reader: If you're hiring a staff IC who treats project scoping as a question of who's in the room - not just who's on the timeline - this one's for you.

Project Overview & Context

The hook

The City of Charlotte had been running its internal police case management system for over two decades. It's the connective tissue of the department's law enforcement work: every incident - 911 calls, non-emergency situations, patrol stops - tracked from first report through investigation to handoff to the court system, at a volume of more than 10,000 incidents a month. It also feeds federal crime statistics, so accuracy isn't a nice-to-have; it's a reporting obligation.

And it was showing its age. Officers were entering vital information into a system that made real-time entry cumbersome - in a job where the moment of entry is often the only moment you get. In 2021 the city committed to modernizing it, and I was retained to lead the UX.

This is a case study about that modernization - the research, the design system, and a form-generation approach that collapsed months of work into weeks. But the reflection that matters most came later: about what the review pipeline we shipped didn't include, and how that reshaped the way I scope projects now.

My role

Lead UX Designer / Researcher across a multi-year engagement. I owned:

User research: panel interviews, surveys, and ride-alongs with officers on shift
Feedback synthesis into the design strategy
Design: mockups, the component library, and two full themes (dark + light)
The automated form-generation approach (Figma + React component layer)
Moderated and unmoderated testing (UserTesting.com) and survey feedback loops

The system served far more than patrol officers: crime scene investigators, forensic experts, detectives, and the District Attorney's office all worked in it daily.

Timeline & tools

Timeframe: 2021-2023.
Tools: Figma for design and the generated form library; Airtable as the database behind the custom dynamic form generator; JIRA for tracking; UserTesting.com for unmoderated feedback.
Constraint that shaped everything: the new system had to run concurrently with the legacy one, which put the backend largely off-limits.

The Problem Statement

The challenge

A records system used by five different roles, governed by complex business rules (conditional required fields, triggers), spread across hundreds of forms, with officers switching between vehicles and desktops all day - and a mandate to modernize the experience without touching the data layer underneath.

Underneath the UX problems sat a harder, quieter one. This is a system of records about people - people who give a street name during one stop and a legal name during another, and can end up fragmented into two records that each tell part of the truth. Entry accuracy and record accuracy are different problems, and most projects like this only fund the first.

Objectives

Simplify and improve data entry - fewer steps, intuitive forms, auto-fill and smart defaults, so officers enter what they mean to enter under time pressure.
Improve report and case management - dashboard overview, real-time updates, navigable case folders for officers juggling multiple cases.
Create consistent UX patterns - one set of navigation, layout, and interaction conventions across the whole surface.
Treat record accuracy as a funded problem - reconcile fragmented identities with human judgment at every step, not just cleaner input fields.

Process & Methodology

Research & insights

I was brought in at the start to run a Design Thinking process, and built a visual guide to the methodology so a team new to it could work the same way I did - empathize, define, ideate, prototype, test.

The Design Thinking visual guide made for the project team: Empathize, Define, Ideate, Prototype, Test as connected stages, each annotated with its methods. — **The methodology, made visible.** The visual guide I built so a team new to Design Thinking could follow the same process - with each stage annotated with what we'd actually do there, from interviews and shadowing to "fail fast" prototyping.

The research itself was three-track:

Panel interviews with officers, CSIs, forensic experts, detectives, and the DA's office - the qualitative view of where the system helped and hurt.
Surveys across a broader user base for quantitative signal on specific functionality and pain points.
Ride-alongs - the one that mattered most. Watching officers use the system mid-shift surfaced what no interview could: data entry under time-sensitive conditions, information access on the move, and the real cost of every extra step.

Research had its own obstacle: much of the feedback was complacent ("I think this works fine") or disengaged ("I retire in 2 years; I don't really care"). I countered with scenario-based questioning and "How Might We" framing to pull latent needs out of users who had stopped imagining the system could be better.

Hand-drawn concept sketches of the report form template and dashboard, shown above the high-fidelity screens they became. — **Sketch first, pixel later.** Hand-drawn concepts for the form template page and the officer dashboard - and the high-fidelity screens they turned into. Sketching kept the early feedback loop with the team fast and cheap before anything was committed to pixels.

Design decisions (the why)

1. Treat accuracy as two separate problems. Fund both entry accuracy (was the right thing entered) and record accuracy (is the record true about the person, and does it stay true over time). Considered instead: funding only entry accuracy - the typical scope for this kind of system. Why: A records-of-people system that doesn't reconcile fragmented identities compounds errors over time. The harder problem - and the more interesting design questions - live in record accuracy.

2. A four-checkpoint identity reconciliation pipeline. The backend's match detection was the first checkpoint: when it flagged a potential identity match across stops, the officer made the initial call. Every case then went to a supervising officer for review. Cases with flagged discrepancies escalated to a full-time data analyst. Considered instead: lighter dedup logic with a single review pass - or no human review at all. Why: Identity errors compound. Three different roles spending real time on review is rare in enterprise software, rarer in government. A person who gave a street name on one arrest and a legal name on another shouldn't get duplicated into two records by accident - and the cost of catching that later is exponentially higher than catching it at entry.

3. Generate the forms; don't redesign them one at a time. The system's forms numbered in the hundreds - 500 forms, with an 8-10 month manual redesign estimate. I built generators instead - one for Figma, one for the React component layer - reading form data as JSON from the existing system (staged in an Airtable database) and producing both the design artifact and the shipping code from a single source of truth. The redesign shipped in 2 months. Considered instead: a modular-but-manual redesign, form by form, against the original estimate. Why: At that scale the forms stop being the work; the generator is the work. One source of truth also guaranteed the consistency objective structurally - no drift between what design showed and what engineering built.

4. A component library with themes for the actual conditions of the job. I proposed Prime Components as the base library, then built two custom themes - dark and light - because officers work day shifts and night shifts, in bright offices and dark vehicles. Following Atomic Design, I composed the base "atoms" into domain "molecules": address blocks, multiple-choice sets, checklists - the recurring shapes of police paperwork. Considered instead: fully bespoke components, or the library's stock theme. Why: The scale (500 forms, five user roles) demanded system-level consistency, and the environmental reality of police work made dark mode a usability requirement, not an aesthetic.

5. Work within the backend freeze instead of fighting it. The concurrent-run constraint meant no backend changes without additional municipal approvals. I scoped the innovation to the frontend - including cloud-based per-officer settings so personalization survived the constant switching between vehicles and desktop machines that made cookie-based approaches useless. Considered instead: pushing for backend changes up front. Why: Waiting on municipal approval cycles would have stalled the entire engagement. Shipping real improvements inside the constraint kept momentum and left a documented path for the deeper changes later.

The Final Solution

A modernized case management platform for the Charlotte-Mecklenburg Police Department:

Streamlined data entry - reduced steps, intuitive forms, auto-fill and smart defaults that lowered cognitive load and helped officers enter what they meant to enter.
Case and report management for officers - dashboard overview, real-time updates, and navigable case folders for working multiple cases at once.
500 generated forms - produced from a single source of truth by the Figma and React generators, visually and behaviorally consistent, honoring each form's business rules (triggers, conditional required fields) validated with subject-matter experts.
A design system built on Prime Components - custom dark and light themes, with Atomic Design molecules (address blocks, multiple-choice sets, checklists) shared across every surface.
The four-checkpoint accuracy pipeline - system match detection, officer reconciliation call, supervisor review of every case, and analyst escalation for flagged discrepancies.

The custom design system: base input components on the left, composed into report navigation, incident cards, case-history panels, and report-information blocks on the right. — **Atoms to molecules to case files.** The component library in practice - base inputs and choice blocks composed into the recurring shapes of police paperwork: report navigation, incident cards, case history, and report-information panels. The same pieces the form generators assembled 500 times over.

Outcome & Impact

What changed

We shipped a case management platform with a real four-checkpoint accuracy pipeline. Officers made the initial reconciliation call when the system found a potential identity match. Supervising officers reviewed every case. A full-time data analyst worked flagged discrepancies as a dedicated role. The work also shipped meaningful entry-accuracy improvements - auto-fill, smart defaults, consistent patterns - that reduced cognitive load and helped officers enter what they meant to enter.

The 500-form generation approach turned an 8-10 month estimate into a 2-month delivery, and made design-code consistency a property of the pipeline rather than a discipline to maintain.

Honest accounting

What didn't ship: any external correction path for the subjects of the records. The accuracy-over-time work was discussed, but we never got to it. The project ran long and was called complete rather than reaching a point that felt complete.

(No adoption or error-rate metric here by choice - the four-checkpoint pipeline is the substance, and a vanity number would weaken it.)

Learnings - what I'd do differently

The procurement defined "users" as the people who held a login. The person the record was about wasn't a user in the procurement document, so they weren't a user in the research plan, and they weren't a user in the review pipeline. I see this now as the load-bearing scoping decision of the whole project.

On any system that records information about people who aren't the customer, the first scoping question I now ask is: who is in the record but not in the room? If the answer is "nobody we're funded to talk to," that's not an answer - it's a risk to name out loud before the timeline gets set.

This isn't only true for police records. It's true for healthcare, education, insurance - any platform where one party enters data and another party is described by it. Accuracy for the user isn't the same as accuracy about the subject. Good design has to hold both.

Charlotte-Mecklenburg PD - Case Management