Dakota Criminal Justice Network
The Dakota Criminal Justice Network (CJN) creates digital applications to streamline data entry and communications between law enforcement officers, attorneys, judges, and probation officers.
CJN had a problem to solve for the Saint Paul Police Department (SPPD), who was reluctant to migrate to CJN's scheduling application because of their desire to integrate overtime scheduling into their online system. My three-person team was brought in to research the current overtime scheduling system used by SPPD, investigate how to streamline and digitize the process, test our ideas with officers, and deliver a high-fidelity, brand-compliant prototype.
Discovery User Research
Our first step was to research the existing system SPPD uses to schedule and track their overtime shifts. After our initial meeting with CJN, we knew that this was an entirely paper based system that needed to be manually created and updated on a monthly basis. We set up a meeting to conduct a contextual inquiry with the officers involved in the scheduling process to let them walk us through every step they take.
Discovery Client Meeting
In our initial client meeting, we received a brief overview of the project and the goals of CJN from the department's manager. We learned that they wanted us to design web application that would integrate with their existing application suite while meeting the unique functional needs of SPPD. We received an overview of what CJN perceived these needs to be at this initial meeting.
Contextual Inquiry with CJN
The following day after our initial client meeting, we had a more in-depth discussion with the entire project team at CJN. In this meeting, we received more context into the work that the organization had previously done and where they were looking to make some adjustments going forward in relation to both design and technology requirements. This meeting provided us with the framework in which we had to design our system and the technical considerations we would need to consider, including the types of devices that would be used to access the application.
Contextual Inquiry with SPPD
During our first meeting with potential users at the SPPD, we were finally able to witness the overtime scheduling process in action. Two of the primary schedulers from the organization walked us through their process, which included touch points at which three different administrative staff members were involved.
We also clarified our definition of what exactly an overtime event was. We discovered that officers' overtime opportunities consist of large events held at specific venues, like Minnesota Wild games at the Xcel Energy Center or Saint Paul Saints games at CHS Field. There are many technical requirements that go into setting up and scheduling these events, which this contextual inquiry uncovered.
Finally, we discovered the goals of SPPD in regard to this project. They wanted a digital application that would streamline their process and centralize data. They needed the new system to be fair and transparent when it came to their scheduling process and provide access to past schedules for review purposes.
Data Analyisis & Synthesis
Through our data synthesis, we discovered a few primary pain points in the existing system:
- the many rounds of communication during which papers could get lost,
- the lengthy amount of time spent creating and filling out paper forms,
- and officers' lack of visibility into the system and access to their past records.
Affinity & Journey Maps
We began by writing down individual observations we had made during our meetings with CJN and SPPD. These included steps into the process, considerations that needed to be made, etc. We went through several rounds of affinity mapping to see the different ways we could break down the data. At one point, we organized the data points into categories that corresponded to steps in the process. At another, we organized them into a timeline of sorts to create a journey map.
Mental Model Diagram
We also broke down our affinity maps to create a mental model diagram, which represented how the users interacted with and understood the system. We knew that this would be an important step because our newly designed system would need to consider and fit into the users' mental model.
Task Flow Diagram
Finally, we used all of this information to create a diagram of the task flow of our new application. This diagram identified what information would need to be visible during key decision-making stages, highlighted points of automation within the system, called out where feedback would be necessary, and provided a draft of our information architecture. During this process, we were able to trim down our user groups from three to two user types.
Rapid Iterative Prototyping
Our research process and wireframing process began to synchronize mid-way through the project, once we had enough research to begin concept work. We continued to analyze and interpret our research as we went through the rapid iterative prototyping process because it allowed us to make informed adjustments as we went.
Because this project was heavily task-based, our wireframing process helped us to determine what specific pieces of information we needed to include on each screen before committing too much design time to any one concept.
During each round of wireframing, we held critique sessions during which we helped one another identify possible design holes and consider fringe cases.
Moving into digital prototyping, we used Sketch and InVision to create clickable interactions for our user testing session with SPPD. Sketch made it easy for our team to create and share assets that followed CJN's existing style guide. By the time we started adding interactions using InVision, we had a solid understanding of both the user’s needs and our new system.
We used our interactive prototype to complete a user testing session with a scheduler from SPPD. For this evaluation, we designed scenarios and tasks that allowed us to focus in on the information architecture, language, and signals of our new system. We created a detailed script for the session, which was recorded so it could be referenced later. The scheduler was able to successfully complete each of our scenarios and tasks, with just a couple of wrong turns that made task completion take longer. These were related to some of our signaling in the application, so we adjusted those for our final prototype.
Next Steps & Recommendations
Moving forward with this project, we would like to continue testing the application with additional officers and agencies to ensure that our solution is one that could be adopted by other teams outside of SPPD. Once further testing is complete and refinements made, the development team at CJN can begin building the application. We provided CJN with annotated wireframes highlighting the major functionalities of each screen, in the event they do wish to move forward with the project as stated.