CPDP Champaign

Four Data Types. One Coherent System.

Year 2026
Client Invisible Institute, Chicago
My Role UX/UI Designer
Tools Figma · FigmaJam · ClickUp
Status Currently in development
Services
Information Architecture Color System Interaction Design Relational Navigation Design Component Library
CPDP Champaign, project screenshot

Mission

The Champaign Police Data Project makes official records from the Champaign and Urbana police departments publicly available for open review. This platform goes deep: articles, officer profiles, complaints, and use-of-force incidents, all browsable, all interconnected, all published for anyone to examine.

My Contribution

I designed the entire platform from scratch through a co-creative process with the Invisible Institute team, defining the information architecture for four distinct data types, leading ideation sessions to find a visual language that unified them without flattening their differences, and building the interaction design for the relational navigation between officers, complaints, and incidents.

Delivered

4
Data types, each with its own dedicated page and unified visual language
3
Levels of relational navigation: officer → incident → connected officers
WCAG AA
Accessible design, contrast, typography, and touch targets compliant from day one

Context

Police accountability data is only useful if people can actually navigate it. The Champaign Police Data Project publishes four types of official records, articles, officer profiles, complaints, and use-of-force incidents, each rich with detail, each connected to the others. The challenge wasn’t collecting the data. It was designing a system where a resident, journalist, or legal professional could move through all of it without getting lost.

The Challenge

Each of the four data types needed its own dedicated page, officers live differently from complaints, and complaints live differently from use-of-force incidents. But they couldn’t feel like four separate tools. A user looking up an officer should naturally find their disciplinary history. From there, they should be able to open a specific incident and see every other officer involved. The information needed to flow.

The risk was building something that felt fragmented, or worse, overwhelming. Four categories, multiple pages, relational connections, too many moving parts can collapse into confusion fast.

Challenge mapping sketch
Before designing a single screen, we mapped which information needed to connect with which, and why.
Journalist needs to find
an officer’s employment history
Screen 1 , Homepage
Lands on site
Sees U.S. map with color-coded states
+ grid of state buttons
Full Data · Some Data · Coming Soon · No Data
Must know in advance which state the officer worked in. No cross-state search available.
Does the journalist know
which state to look in?
NO
Dead End
No way to search
across states
YES
Screen 2 , State Data Table
Clicks state button
Raw table loads: UID · First Name · Last Name
Agency · Start Date · End Date
Thousands of rows, no context
No name search. Only column sorting (A→Z, newest first). Must scroll manually through all rows.
Finds the officer , but
Same officer appears in multiple rows
No indication these are the same person across different employment periods
No unified officer profile. No history view. Data requires manual interpretation.
Dead End
No profile page. No further navigation possible.
Downloads entire CSV
Continues research manually in Excel or spreadsheet tool

Understanding the Users

The platform serves residents, journalists, and legal professionals, but their needs here go deeper than a simple search. They’re building cases, investigating patterns, cross-referencing incidents. The design needed to support that kind of sustained, detailed exploration without creating friction at every step.

Resident
Direct encounter · Personal context
When
I have a direct encounter with an officer
I want to
Look them up by name and see their history
So I can
Understand who I’m dealing with before deciding what to do next
Journalist
Investigative · Pattern-driven
When
I’m investigating a story about police conduct
I want to
Cross-reference complaints and incidents across officers
So I can
Build a documented narrative backed by verified public records
Legal professional
Case-driven · Evidence-focused
When
I’m preparing a case involving a specific officer
I want to
Verify their disciplinary record and incident history
So I can
Use official records as evidence in an active legal case

The Color System

The solution to keeping four data types unified without merging them into noise was color. Each category got its own consistent color, green for articles, blue for officers, orange for complaints, red for use of force, applied throughout every page, every card, every tag.

CPDP Champaign, color system

Color became the information architecture. A user scanning a page knows immediately what type of data they’re looking at. When they follow a link from an officer profile into a complaint, the color shift signals the transition. It’s a system that works visually before the user has read a single word.

Connecting the Data

Before designing any screen, we mapped what information needed to connect to what, and why. That exercise revealed one thing: every data type leads back to an officer.

Data type
Articles
Fields
Title Date Category Officers mentioned
Search by
Title Tag
Connects to
Officers
Data type
Officers
Fields
Name Badge No. Agency Employment period UID
Search by
Name Badge No. Agency
Connects to
Articles Complaints Use of Force
Data type
Complaint
Fields
Complaint ID Date Allegation type Officer(s) Outcome
Search by
ID Officer name Allegation type
Connects to
Officers
Data type
Use of Force
Fields
Incident ID Date Force type Officer(s) Outcome
Search by
ID Officer name Force type
Connects to
Officers

From there, the navigation designed itself. Each officer profile shows a full disciplinary timeline. From the timeline, a user can open any incident and see every other officer connected to that same case. What could have been a dead end becomes a thread to pull.

From Paper to Figma

Every design decision started on paper. Sketching by hand let us map the hierarchy and flow quickly, without committing to any visual direction too early. Once the structure felt right, we moved into Figma for prototyping, structured feedback rounds, wireframe revisions, and finally the UI. Some feedback pushed us back to the architecture level, particularly around how the relational connections between data types should work. Getting that right before moving to UI saved significant rework.

Site map sketch 1 Site map sketch 2 Site map sketch 3 Site map sketch 4 Site map sketch 5
First site map sketches and initial wireframes
Wireframes in Figma
Wireframes in Figma

Iterations

The design didn’t arrive fully formed. Each round of feedback from the Invisible Institute sharpened what the platform needed to be, and what it didn’t.

First Iteration

The first version established the structure: one dedicated page per data type, a consistent layout, and a color per category. The colors were strong and saturated, each section with its own bold identity. It worked as a proof of concept, but it felt too heavy for a public accountability tool. The visual weight competed with the content instead of serving it.

First iteration design

Second Iteration

The second version brought the design closer to Invisible Institute’s visual language. Softer colors, rounded corners, a lighter feel overall. The four data types kept their individual identity but no longer felt like four separate products.

Testing this version with the client revealed two friction points: the homepage wasn’t making the platform’s purpose clear at a glance, and the timeline format made it harder, not easier, to read the data in sequence. Both needed to change before the design could move forward.

Second iteration design

The Result

After multiple iterations, prototyping rounds, and direct feedback from the Invisible Institute team, the design landed where it needed to be: a system where four data types feel like one coherent platform.

The designs for CPDP Champaign are complete and approved. The platform is currently in development. When it launches, it will be the most detailed public view of police records available for Champaign and Urbana, a system where the data actually speaks for itself.

Final CPDP Champaign design

Let's connect! Got a project, a question, or just want to talk design? I'd love to hear from you.