Philly Truce — Peace Patrol digital platform

Case Study

Philly Truce
Peace Patrol.

Role Product Design Lead
Team Mobile + Desktop Pods
Duration Phase 4 · 8 Weeks
Type Nonprofit / Civic Tech

Overview

Designing for the work of keeping peace.

Philly Truce is a Philadelphia-based nonprofit founded to reduce gun violence through community-led intervention. Its core initiative, Peace Patrol, empowers trained Peace Patrol Officers to conduct daily neighborhood patrols, de-escalate conflict, and report incidents in collaboration with local stakeholders.

As the program scaled, the team faced increasing operational complexity, managing patrol routes, officer availability, scheduling, and incident tracking across multiple neighborhoods without a dedicated system.

My Role

Phase 4 · Product Design Lead

Responsibilities

Led design direction across mobile and desktop, aligned research insights with delivery constraints, facilitated stakeholder decision-making, and ensured end-to-end system cohesion.

Team Structure

2 cross-functional design pods (Mobile and Desktop) working alongside research partners, engineers, and nonprofit stakeholders.

Delivery Window

8 weeks, Phase 4. Scoped for feasibility, prioritizing features with the highest operational impact under tight constraints.

Problem Statement

"Dispatchers were coordinating routes, schedules, and PPO availability through fragmented, manual workflows."

Phase 4 Design Brief · Philly Truce

Routes were shared via group chats. Last-minute changes were handled reactively. Visibility into coverage gaps was limited. The goal for Phase 4 was clear: design a dispatcher-facing desktop dashboard while evolving the mobile experience so PPOs could view schedules, claim routes, and reflect real-time operational changes.

System Thinking

Mobile meets Desktop.

Early in Phase 4, we facilitated alignment sessions to map how mobile and desktop responsibilities intersected. While the users differed (PPOs on mobile and dispatchers on desktop), their actions were deeply interconnected. This artifact helped us identify shared features (routes, schedules, availability), avoid duplicating logic across platforms, and define clear ownership between experiences.

System thinking diagram showing mobile and desktop relationship

Mobile ↔ Desktop relationship mapping: shared features, platform ownership, and dependency flows.

Sprint Timeline

Planning Under Constraints.

With an 8-week delivery window, we worked across design, research, and engineering to scope what was feasible. Not every requested feature could be delivered, so we prioritized based on operational impact. This timeline became a shared source of truth across teams, clarifying dependencies, setting expectations, and protecting design quality under tight deadlines.

8-week delivery window

Sprint timeline showing 8-week delivery plan

The Experience

The Mobile Experience.

Phase 4 mobile work focused on enabling PPOs to participate in dispatcher-led planning, not just react to it. The goal: help PPOs clearly understand route assignments, availability, and completion flows without increasing cognitive load during active patrols.

User Flow

Updated Information Architecture.

Based on usability studies from the previous phase, we revised the mobile information architecture to reduce friction during critical moments: route completion and feedback. These changes directly informed which screens we redesigned and which interactions we simplified or deferred.

Updated mobile user flow and information architecture

Wireframing

Collaborative Exploration.

We encouraged each designer to explore the route experience independently, then reviewed patterns collectively. Critique sessions and dot-voting aligned the team on the strongest ideas, surfacing edge cases early and ensuring decisions were made collaboratively, not by hierarchy.

Wireframe exploration — route experience, option A Wireframe exploration — route experience, option B

Mobile Components

Building the Design System.

Key components were designed to handle the real-world complexity of field operations, including route states, availability toggles, alert patterns, and feedback flows, each optimized for glanceable use during active patrols.

Mobile component — route card
Mobile component — availability state
Mobile component — alert pattern
Mobile component — feedback flow

Report Statuses

Unclaimed, In Progress, Resolved.

The three main report statuses (Unclaimed, In Progress, and Resolved) required distinct visual treatments to communicate urgency and state at a glance. Each status carries different affordances for the PPO in the field.

Report status — Unclaimed Report status — In Progress

Final Mobile UI

Clarity During High-Attention Moments.

The final mobile designs focused on clarity at critical moments: route completion, feedback submission, and next-step navigation. Design annotations document rationale and edge cases considered during engineering handoff.

Final selected mobile UI screens with annotations

Selected final screens, annotated for engineering handoff. Focus on route completion, feedback submission, and navigation clarity.

The Experience

The Desktop Experience.

Designed for dispatchers and administrators responsible for planning routes, assigning PPOs, and managing daily patrol operations. Unlike the mobile app which supports execution in the field, the desktop product supports decision-making, coordination, and oversight.

System Workflow

The steps between the dashboard and the app.

Dispatchers intuitively plan routes on the desktop, considering hotspot areas and operational leads. PPOs receive assignments, meet supervisors, grab gear, and head out. If they encounter anything on their route, they intervene and report via the mobile app.

Desktop to mobile workflow diagram

End-to-end workflow: dispatcher planning on desktop flows into PPO execution on mobile.

Design System

The Style Guide for Desktop.

We established a shared system for buttons, navigation, and layout to keep complex admin workflows consistent and scalable. A unified design language reduced friction and allowed the team to move faster across sprints without rethinking foundational patterns.

Desktop style guide — buttons, navigation, layout system

Shared design system: components, states, and layout tokens established for the desktop dispatcher dashboard.

Iteration

Iterating the Scheduling Flow.

Early scheduling flows were too linear and error-prone. Through iteration, we separated route assignment, daily scheduling, and publishing to better match dispatcher workflows and reduce mistakes. Each round of testing surfaced new edge cases: late cancellations, overlapping routes, last-minute PPO unavailability.

Scheduling iteration — flow evolution across design rounds

Scheduling flow evolution: from linear and error-prone to separated, context-aware stages.

Final Desktop UI

A flexible system built for real-world complexity.

We designed a flexible scheduling system that allows dispatchers to edit routes, parameters, and shift times without losing context. Breaking edits into focused actions reduced errors while keeping daily planning fast and predictable. The result: a dashboard dispatchers could trust under pressure.

Final desktop UI — dispatcher scheduling dashboard

Final dispatcher dashboard: flexible scheduling, route management, and real-time operational visibility.

Reflection

The Philly Truce project taught me that designing for operational systems requires as much clarity about what you won't build as what you will. By aligning closely with research and iterating through multiple user flows, the final solution balances flexibility with structure, allowing teams to plan confidently while adapting to real-world change.

Next Project

MentorMap