Philly Truce, a non-profit organization with a focus on community safety and violence intervention, operates multi-faceted violence reduction programs like Peace Patrol through which Safe Path Monitors and Safe Path Patrollers actively patrol community streets and neighborhoods to observe and mitigate incidents of violence. As Philly Truce expands its initiatives, managing the incidents encountered by Safe Path Monitors and Patrollers has become increasingly difficult. Currently, Safe Path personnel document incidents they encounter using paper-based reports, which makes effectively utilizing the incident-related data difficult and time-consuming.
As such, Philly Truce aims to develop a digital platform that allows Safe Path Monitors and Peace Patrollers to better document and manage incidents they encounter. The creation of this platform would allow Philly Truce to more effectively manage incidents, improve the deployment of Safe Path personnel, and better engage community members in helping curb violence in and around Philadelphia neighborhoods, improving the overall effectiveness of its violence reduction programs.
In this phase of Philly Truce app production, the goal was to create a user-friendly digital platform for Safe Path Monitors (SPMs) and Peace Patrollers to document incidents efficiently, including features for creating, claiming, owning, editing, and closing reports. Aligning with business goals, this enhances operational efficiency by replacing the absence of record keeping, allowing for real-time data capture and analysis. This directly supports Philly Truce's mission of improving community safety and reducing violence.
Our product strategy team determined that the PRD for this phase would be to deliver a coded MVP that includes the Incident Report Management features and Chatbot/Tip Line. During an eight-week period, we split our goal into two-week sprints - totaling four sprints.
Philly Truce has undergone two previous phases to ensure that SPMs and Peace Patrollers had a way to keep the Philadelphia community safe in the palm of their hands.
Phase one was about discovery. Who is the user, exactly? How do we draft a design that solves the issues at hand? Some findings were not accomplished within those phases, however, we were able to pick up where they left off.
Who is the User?
Our research team found that beyond the title of Peace Patroller or SPM and their roles, we were also designing for students who'd seen something traumatic or are in a compromising position to report something they have seen, heard, or experienced.
What are their needs?
In this phase, our research team discovered that the students need a safe way to report incidents and connect with SPMs and Peace Patrollers. SPMs and Peace Patrollers need a way to connect with the students and efficiently document and archive the information received.
The Audit
My design team decided to do an audit of Phase 2's designs of the report management flow to gain a better understanding of what we could omit and what could be built upon. with help from our research team, we were able to gain a clear understanding of where to begin.
Performance Testing
Our research team planned a pilot test to test the prototype's performance on mobile. The features tested in the first round were:
Create a New Report (SPM Generated)
Edit a Claimed Report
View an In-Progress or Closed Report
Claim an Unclaimed Report
Receiving our first round of insights were very helpful in guiding us to the right starting point. Based on the priority score, impact score, and the frequency score, we were able to determine which flows were a priority to iterate first before others. The results pointed to Create a Report, Edit Report, and the overall transition experience of the app to make the prototype as close to real as possible. So, we got to work.
Create a Report Changes
In order to make our designs more responsive, we added constraints so that the important elements are constrained to their respective areas when resizing for different screen sizes.
Based on UT analysis, New Report button was affected by screen size.
Bottom Nav also received a similar treatment.
Edit Report Changes
Some of the option boxes were not active during usability testing which caused testers to give up on completing tasks.
In this iteration, we:
Made sure that when “Other” is selected in the dropdown, users have the capability of explaining with an open-text field.
Ensured that the additional “Edit” icons were removed as we felt they were redundant, due to already being in “Edit mode.”
Eliminated low flexibility in terms of describing incidents to SPMs.
Experience Improvements
Claim and Close Report
We removed excess pop-up modals prior to editing. Previously, the edit icon and messaging icon generated pop-up modals that were a bit redundant and could easily confuse the user.
Thanks to our collaboration with the Content team, we established a solution to have just one pop-up modal to account for all entry points mentioned (Claim Report CTA & Messaging icon)
New Changes
Incident Type(s) Categorization
Incident multi-selection is no longer hidden behind dropdown menu. Now includes additional fields for more details.
Create New Report CTA
We changed the (+) Icon to a more universally recognized icon that represents “Create/Compose” as a one-tap solution to creating a new report.
Clear CTAs
We worked with the Content team to establish clear CTAs such as Create Report , Save, and Resolve Report.
Bottom Navigation
Removed bottom navigation shadow + added a line as a divider.
Edit Report
Flow Changes
[Proposed by Content] If "Fight" is selected, users can provide more details by selecting between two options (2 people or 3+ people)
Save Changes pop-up modal
We shifted towards adding scrollable feature in this overlay to be more future proof due to large amount of edits that could be made
Scrollable
We implemented drag interactions for longer screens shown to mimic usage by mobile devices
Related Reports
Previously was “Connected Reports”
Changed “Select any connected reports”
to “Select reports to connect.”
Consistent Motion
IF users tap Back arrow icon, this current screen will move forward.
IF users perform any of these below actions…
Save (Edit Report changes)
Resolve Report
Reopen Report
Save to Drafts (Future implementation)
Pop-up modals will first appear as a centered overlay.
THEN next screen will move backwards…
And the snack bar will come up from the bottom.
Demo of Motion
Screen 1: Backward motion and forward motion
Screen 2: Modal overlay and snackbar
Identifying Possible Confusions
Confusions:
We simplified interactions in areas where we thought that the User may become confused during the research study. Areas like:
Checkboxes - the User was required to click a certain amount of check boxes in order to move forward through the prototype
Drop downs - finding a way to connect the interaction could prohibit the User from moving forward effectively
Solutions:
After working with results from Research and suggestions from Strategy we were able to come up with a plan. Instead of:
Multiple checkboxes to click, we require only (1) to be clicked for the prototype
Navigating to a new screen, we created and embedded a component of the interaction
Ready for Dev
We began annotating for the dev team.
Phase 4 will be focused on designing a desktop version of the Philly Truce app as well as fine tuning the chatbot and other features that were out of scope for Phase 3.
Thank You!
Thank you for your time viewing my contributions to the Philly Truce app!
Home