Pennsylvania Prison Society

The Voice/Form Solution

The Web Solution

Based on the recurring ideas within our research and usability testing, our final design was an information managing system which is flexible and assists the main office with filing and assigning requests. We reduced the flow of a request to some core questions which were applicable to multiple platforms like google forms, a phone conversational user interface, and a web application. This breadth of application was intended to cater to the diversity of volunteers and their individual workflows.

Research | Overview

We have held several semi–structured interviews with our client and the organization’s Director of Volunteers, and have performed analytical methods such as stakeholder mapping, flow diagramming and user journey mapping. These research methods were done early on to help us really understand the system and identify the pain points. From these methods, we have derived 3 key insights/painpoints:

• varied chapter behavior,
• the disorganized intake of requests, and
• the lack of incentive to report.

Different policies between prisons lead to different report flow for OVs. There are no shared systems across all chapters, but each chapter has existing workflows they operate on. Every chapter also has their own unique behavior. This became apparent when we did contextual inquiries with OVs and semi-structured interviews with the Director of Volunteers (who knows almost every OV within PPS). Smaller chapters have individual OVs who visit prisons based on their own schedule and email visit notes to PPS. Other chapters visit facilities as a group and discuss issues raised together and create a monthly report that summarizes the issues they saw in their visit. There was a wide variety of visiting behavior and preferences when reporting which made it difficult to standardize chapter behavior for PPS.

From our semi structured interviews with people within the office, we discovered that requests came in many different forms: email, phone call, or letter. Often times, these requests weren’t from the original requester. They may have been sent from a concerned family member or a letter could have been from an incarcerated individual which was sent to their local chapter, which was then sent to the main office for documentation purposes and so on. These requests also have varied structures due to the variety of forms they take. Internally, PPS document requests with names, inmate ID, category of concerns, date and etc… Overall there was an issue with the aggregation of requests due to the disorganized intake of requests for PPS. The inconsistent report format and sourcing makes filing requests difficult.

"We are volunteers; we can only do so much with our free time."

From our contextual inquiries, we discovered that official volunteers didn’t have any incentive to create a report. When pressed into why, OVs stated they were volunteers; they were not paid to do this and they didn't want to report, because they felt like it was extra work. In addition, it was too much of a hassle to create individual reports for every incarcerated individual they met. This lack of incentive was likely derived from feeling unseen and unheard in the organization and OVs likely didn’t feel like their reports made a difference. I uncovered this retrospectively when we did usability tests on our mid-fi wireframes.

Ideation | Low to Mid Fidelity

Based on the interviews and site visits we did, we relocated our focus from the ask ("How can we encourage reporting?") to news insights we had:

• Unified report aggregation
  • When interviewing the different chapters, we found that official visitors were ambivalent towards reporting back to the office. This meant that the main office was getting reports, if any, sporadically.
• Optimize existing operating system
• Balance chapter resource when assigning requests
• Uniform report format
  • Because of the different types of reporting styles that chapters have, from spreadsheets to emails for individual requests, there is a large discrepancy in how reports look and work. The unification of a report format will allow for a smoother workflow when analyzing the data received from the sketches.

After generating new insights from our recent observations and informal interviews, we gathered together to do a crazy 8 activity to quickly develop ideas that could potentially address our pain points. We based our first low fidelity prototype on the results of the crazy 8 activity.

Iteration | COVID-19 & User Testing

When we started working on our mid-fi prototype, COVID-19 had forced PPS to temporarily halt in-person visits. PPS had adapted to video call visits for volunteers who could use video calls, as well as making an online form to ensure that prison facilities are actively participating in proper COVID-19 prevention methods.

In parallel, we designed a common script– a set of questions that OVs typically ask or procure information about. This common script included questions like "What happened during your visit?" or "What type of request is it?" This common script would be adaptable to multiple platforms: like web forms, interactive voice response(IVR, which is similar to a conversation user interface like Alexa or Siri), and like we had done originally, a web application. We decided that this adaptability would be critical to address the diversity of OVs and their reporting styles.

Unexpectedly due to COVID, we learned that OVs readily adapted to the new visit methods. PPS reported that volunteers were adapting well to the new technology. This quelled a huge concern for us when we were between low-fidelity and iteration.

For the low-fidelity web app prototype, we defined the tasks that a typical Official Visitor(OV) or Chapter Convener would have to do. When we tested these tasks through a think aloud, all of our users found the task names to be confusing. They also missed the human interaction when they interacted with our prototypes. During our rounds of iteration, we found that separating the tasks by ongoing requests and past requests was far more effective and clearer. We also added a simple "seen" column to assure the volunteers that their hard work has been viewed and acknowledged.
We had also tested our common script on several users. We found that users were always zealously talking about the visit details and stories before they ever thought about documentation information like inmate IDs or even the location of their chapter. They had also expressed that answering identification information individually was a hassle. As such, we revised the common script to first ask about the visit details before asking about documentation information and we greatly reduced the amount of identification questions and merged questions where we could.

Solution

Clickable web app prototype here. Web form/common script prototype here.

Based on our early research insights and usability testing, our final design is an information managing system which accommodates for various report behaviors from different chapters and assists the main office with filing and assigning requests. We developed the two major solutions that the organization is having most trouble with: the formalization of reports and the tool to manage and review them. The final design is a web–based system to collect report in different formats:

• The common report script for volunteers: there will be a common report script, which enables volunteers to submit reports through a web based form or through a phone call via IVR. Varied report behavior and methods demanded flexibility from our solution. The common script was created for flexibilty and was iterated through extensive observation on OVs and how they communicate their requests to others.
  
  
• The web–based system for volunteers: enabling them to see their request assignments, their report records and take further actions. When OVs log in, their user role will have limited administrative access. This esnures privacy for incarcerated indviduals, a concern I discovered in the interviews with the Director of Prison Monitoring, in addition to serving OVs a simple visual platform to review and create reports for requests.
  
  
• The web–based system for PPS Office: This system was created to centralize reporting and documentation of requests, which were painpoints we found in our intial research. The web–based system will be able to see all reports from volunteers across Pennsylvania, and assign requests to different chapter conveners or individual volunteers, while volunteers could only see their own assignment. The system would automatically document those reports, show trends of report types, and enable a flat organizational structure to assign reports to chapter conveners or to individual volunteers in an area without a chapter.

As the director of PPS office continues to implement and comprehend the system, the different user flows will come together into an ecosystem, which delivers our four core ideas: a central hub, frictionless documentation, maintaining different levels of access and turning qualitative data into quantitative data.

Solution | Takeaway

Designing for a system with so many constraints was difficult. We spent a lot of time understanding the space, as all of us were unfamiliar with the prison system. It was an incredibly humbling experience to talk to incarcerated individuals, as well as hearing stories and struggles from Official Visitors. I felt that the time we spent on contextual and user research gave us a proper understanding of the challenges the users face that ultimately guided us to a viable and doable solution for PPS.