Designing Field Tools for Philly Truce's Peace Patrol

INTRO

Philly Truce is a Philadelphia nonprofit working to reduce gun violence through community-led patrols. Peace Patrol Officers โ€” many of them justice-impacted โ€” walk routes in the neighborhoods hit hardest.

They document incidents and walk those routes in the field โ€” older phones, bad signal, no extra taps.

Reports were labeled โ€œReport #1839.โ€ Shifts lived in group texts. Finding a report meant opening them one at a time.

I was one of six designers across two phases. I worked on IRMP assignment and editing, and I owned the All Routes filter through the Phase 5 file.

Role

UX Designer, one of six

IRMP + Routes

Status

Phase 5 handoff

Hi-fi prototype

Type

Nonprofit

Mobile

Civic field tool

Tools

Figma

FigJam

Notion

Problems

Reports labeled only by number.

Shifts ran on group texts.

Field use: old phones, bad signal, no spare attention.

Solutions

All / My Routes, with slots on the card.

A separate filter for distance, time, and neighborhood.

Reports titled by street and incident, not a number.

Results

3/3 testers found the right report and assigned it.

All Routes filter is shipping to the live app.

IRMP ready for dev.

Final screens

The Incident Report Management Platform

Officers could not record an incident reliably.

Peace patrol officers were writing incidents on a paper form. The form asked for a school, a student, and a race before it asked what happened. The app that replaced it still did not say the street.

Fig 1. Example of how incident reports were made on paper before going digital.

Overhauling Editing

To address user feedback on poor report identification, my team and I overhauled the report editing form. We replaced the generic version with a smarter interface featuring a dynamic header for context, new fields for police notifications and related incidents, and intelligent conditional fields to reduce clutter. This resulted in a cleaner, more intuitive form that also captured richer data.

To address user feedback on poor report identification, my team and I overhauled the report editing form. We replaced the generic version with a smarter interface featuring a dynamic header for context, new fields for police notifications and related incidents, and intelligent conditional fields to reduce clutter. This resulted in a cleaner, more intuitive form that also captured richer data.

To address user feedback on poor report identification, my team and I overhauled the report editing form. We replaced the generic version with a smarter interface featuring a dynamic header for context, new fields for police notifications and related incidents, and intelligent conditional fields to reduce clutter. This resulted in a cleaner, more intuitive form that also captured richer data.

Assigning and Resolving a Report

Assigning and Resolving a Report

Every unclaimed report locks until it's assigned. Skip the officer field, and the form throws a validation error before you can move forward. Pick someone, and two buttons unlock: Assign report or Resolve report, each with its own plain-language confirmation before anything changes.


This gate matters because of what testing later found: officers expected to assign a report to more than one PPO, since patrols rarely work alone. The one-PPO structure here was where Phase 5 finished, not the end of the story.

Every unclaimed report locks until it's assigned. Skip the officer field, and the form throws a validation error before you can move forward. Pick someone, and two buttons unlock: Assign report or Resolve report, each with its own plain-language confirmation before anything changes.


This gate matters because of what testing later found: officers expected to assign a report to more than one PPO, since patrols rarely work alone. The one-PPO structure here was where Phase 5 finished, not the end of the story.

Every unclaimed report locks until it's assigned. Skip the officer field, and the form throws a validation error before you can move forward. Pick someone, and two buttons unlock: Assign report or Resolve report, each with its own plain-language confirmation before anything changes.


This gate matters because of what testing later found: officers expected to assign a report to more than one PPO, since patrols rarely work alone. The one-PPO structure here was where Phase 5 finished, not the end of the story.

IRMP Testing Results

IRMP Testing Results

3

participants tested core IRMP tasks โ€” two Peace Patrollers, one Assistant Program Manager

participants tested core IRMP tasks โ€” two Peace Patrollers, one Assistant Program Manager

participants tested core IRMP tasks โ€” two Peace Patrollers, one Assistant Program Manager

What worked

What worked

Everyone found and understood the report they were looking for

Everyone found and understood the report they were looking for

Everyone completed the new report-assignment flow without help

Everyone completed the new report-assignment flow without help

What didn't

What didn't

Report overviews lacked context, especially threat severity

Report overviews lacked context, especially threat severity

"PPD" was misread as Peace Patrol Director, not Philadelphia Police Department

"PPD" was misread as Peace Patrol Director, not Philadelphia Police Department

Officers expected to assign a report to more than one PPO โ€” "it's never just one"

Officers expected to assign a report to more than one PPO โ€” "it's never just one"

"Fight" read as more severe than intended

"Fight" read as more severe than intended

The filter icon wasn't recognized without help

The filter icon wasn't recognized without help

These shaped the next-phase recommendations: spell out acronyms, add severity indicators, support multi-PPO assignment, replace the icon-only filter with a labeled one.

These shaped the next-phase recommendations: spell out acronyms, add severity indicators, support multi-PPO assignment, replace the icon-only filter with a labeled one.

These shaped the next-phase recommendations: spell out acronyms, add severity indicators, support multi-PPO assignment, replace the icon-only filter with a labeled one.

The routes management system

Browsing and Claiming a Route

Browsing and Claiming a Route

The All Routes screen shows location, date, and time without opening a route, and only one to two weeks out. Tapping in shows the map, time, instructions, and slots. Claim route stays off until the officer picks home base or on route.

Managing a Claimed Route

Managing a Claimed Route

Claimed shifts live in one list.

My Routes splits them into upcoming and past. Unclaiming asks once and names the exact shift. The one-hour limit sits on the card, not in a help page, so an open slot can be filled.

Designing the All Routes Filter

Designing the All Routes Filter

The list got too long to scan.

Filtering was not in scope. I added it so an officer could narrow by distance, time, or neighborhood. Show routes stays off until one filter is set, then shows a live count. It is a dedicated screen, not the IRMP modal, and it shipped in the Phase 5 file.

Starting and Running a Patrol

Starting and Running a Patrol

The route does not start until everyone is there.

Every assigned officer has to check in. If someone is missing, the route does not start. On patrol, the screen shows who is on duty, their role, and a live countdown.

Say it, don't hunt for it

Natural language replaces category browsing. People describe what they need instead of guessing where it lives in the app.

One question, not a form

When input is unclear, I ask a single focused question instead of guessing or showing a long list of options.

Something instead of nothing

If nothing matches well, the closest option still comes back. No one lands on an empty screen.

A safety branch, built in

If someone's words point to real distress, the flow sets meditation aside and hands them to actual support.

Outcomes & Reflection

Where This Stands

Phase 5 closed with the IRMP design ready for development and the Routes system finalized through high-fidelity screens. The IRMP updates and my Routes filter were built to be tested in the next phase; the Routes flow itself hadn't gone through usability testing when the phase ended, so its actual field performance is still an open question. Sign-up and account settings stayed out of scope on purpose, kept from an earlier phase, so the team could focus fully on the two tools officers use most.

What I'd Do Next

Test the All Routes filter with real Peace Patrol Officers, and expect some of the same labeling issues the IRMP filter ran into

  • Revisit onboarding. Research surfaced real digital-literacy gaps and high officer turnover, and the app still has no first-use guidance for someone opening it for the first time

  • Look at non-conflict incident types. Most patrol activity isn't conflict at all, and the current categories default too often to "Other"

Reflection

This was the first project where the users weren't hypothetical. Peace Patrol Officers do real work in real neighborhoods, and the margin for a confusing screen is smaller than it looks from a desk.

It gave me a real appreciation for nonprofit work, different stakes, different motivation, hours that felt worth it. I lean introverted, and working closely with a large, changing team across two phases is part of why I'm still in touch with people from both, and why I'd work with them again.