Challenge:

Police officers have to do a lot to keep the public safe, while making sure their administrative tasks are taken care of.  This project explores a web responsive checklist form that focuses specifically on helping the officer perform and document their duties during traffic stops.

Duration:

One and a half week class project at Indiana University

My Contribution:

Wireframing
InVision Prototyping
Ideation
Sketching
Affinity Diagramming
Storyboarding

Tools Used:

Illustrator
Photoshop
InVision

Teammates:

Yangguang Li
Derek Parker

A Solution:

Our solution is a web-focused checklist that allows patrol officers to follow the established procedure during a traffic stop.  It prompts the officer to follow procedure and enter the necessary information for the traffic stop, filling out the paperwork to submit later.

During a traffic stop, the officer, using this checklist form, could have a guide to help them through the process of a traffic stop.  It could help them offload their attention of administrative tasks and focus on the situation/environment that they are present in.  Not only would this checklist form remind the officer of critical steps, but it would also prompt and retain the vital information necessary to fill out their reports (e.g.  license plate number, driver's license number, location, etc.).

Link to the InVision prototype:  https://invis.io/P67LK4OR3
 

The Checklist:

Partnering with Agency360's founder, Matt Molter, and COO, Tonya Hanshew , they came to us wanting to create a checklist for police officers to use, while they are on duty, to treat all calls they get the same, trying to avoid human error.

"Good checklists, on the other hand are precise. They are efficient, to the point, and easy to use even in the most difficult situations...they provide reminders of only the most critical and important steps--the ones that even the highly skilled professional using them could miss. Good checklists are, above all, practical."

                        -Atul Gawande, The Checklist Manifesto

A Meeting With The Clients:

Upon interviewing Matt, Tonya and Indiana University's Police Department Lieutenant Brice Teter, we found that as a police officer, your life and the lives of others are on the line, on top of other administrative tasks.  We also found that funding and access to technology severely differed department to department.  Not only may there not be access to technology, there exists a technology gap between young and tenured officers.  Younger officers are more familiar with current technology while the older officers are used to traditional technologies and may be resistant to newer technologies.

The duties and responsibilities of police officers are vast, putting  a lot of stress on them to gather all necessary information and detail while also protecting the public.  

"There is no such thing as a routine call."
                                      - Lt. Brice Teter, IUPD (not pictured above)

With this in mind, how could we start designing for situations where a checklist would help and officer do their job, while not endangering their lives?

Re-Imagining The Checklist:

Imagining what our checklist would look like, we broke down what a checklist was:  a series of tasks to complete.  We asked ourselves:  what other forms does a checklist take?  We looked at a lot of different types of checklists, comparing and contrasting them.

A checklist, when stripped down to it, is basically a true/false form of things to do.  We didn't want our design to be overly simple, where an officer would simply look and check things off the list, but we didn't want to make it overly complicated where only technically-literate officers would use it.  The checklist should also not hinder the officer while in the line of duty.  We had another constraint added:  design only for the web and not for the mobile web.

Some early sketches that I drew, exploring how our design could look and function:

Moving Forward:

With the information from the interview and the added constraint, we went to the whiteboard with Post-Its to map out different scenarios a police officer would find themselves in.

Note:  This is not a comprehensive list.

We then started assigning danger levels to all of these situations as a way to narrow down a scenario where a checklist wouldn't hinder the officer's duties while remaining helpful.  We didn't want technology to be incorporated into their current process, we wanted it to already a part of their process. 

Looking at our groupings, we immediately took Categories 3 and 4 off the table, due to a lot of unknown variables we couldn’t plan for.  Category 1 seemed to be an after-the-fact situation, where using a computer during the process may put an immediate, extra burden during the procedure.  Category 2 was our sweet spot, where there the checklist would be helpful in those certain situations.

We decided to go with traffic stops because we thought a checklist would be most beneficial to an officer’s routine.  They would be back in their car at least 2 times, where they could review procedure and enter information.

What would this checklist look like?  How would this help an officer?  Would this hinder or help proper procedure.  With these questions in mind, we started whiteboarding what our checklist would look like. 

Traffic Stop Procedure (grossly simplified):

• Reasonable suspicion, leading to a stop
• Officer assesses the environment, alerting dispatch of the situation and giving relevant information (violation information, license plate, location, etc.)
• Officer interviews the offender
• Officer returns to squad car and runs information
• Officer returns to offender's car to give punishment

To help my team and I visualize the traffic stop procedure, I storyboarded the scenario.  In doing this we found certain areas where we thought the checklist would help the officer the most, while remaining practical.  

Wireframing:

After settling on an initial design, I started wireframing our design.  The first set of wires were used to do usability testing to see if the design made sense to people and see if there were any choke points in the current design.

First Iteration

We learned, from our usability tests that the progress bubbles at the top afforded clicking.  This wasn't our intention as we envisioned the progress bar to remain unclickable.  The wording was confusing when prompting the user to complete tasks as well.

Second Iteration

Taking these things into mind, I started working on the next iteration.  Addressing the progress bar, I asked myself how it could be laid out differently.  It seemed that people were paying attention to the bar if it resided in the middle.  Putting it on the side of the page, giving it less attention and less weight, seemed to be the best option, from quick group sketching and brief testing sessions.

On the start screen, there was no place to input a call number from dispatch, from which we found after a couple follow-up questions were answered.

Final Iteration

Our final iteration also included information about what to do in a certain situation (e.g. how to pull over a suspect).  This was included to act as a reminder for the officers of the types of information to retrieve as well as the procedure to follow.

A notes section was added to these items in the event that the officer is unable to obtain a piece of information from the suspect and/or situation.

My Reflection:

This project and it’s deadline really tested what could be done in a week.  Designing for patrol officers was, and is (I found out), very difficult.  There are so many factors that come into play both on and off the job and there is no routine that had consistency.  Interviewing a police officer helped me realize just how many unknowns there are for officers on the job.  

Designing a one size fits all solution is very hard and involves a lot of trade-offs.  Focusing on a single target user/scenario helped me focus on one person and one job, shaping the design to that person’s needs.  This started me thinking about what a target user really helps you do:  focus in and be specific.  One example that kept coming up throughout the process was curb cuts in sidewalks.  They were intended and designed for physically-challenged/disabled people, but still are used for a variety of other things as well (e.g. parents with strollers, bike usage, skateboard usage, general pedestrian usage, etc.).

Sketching in sessions helped my team frame our problem space and helped each of us stay on the same page.  When it came to wireframing our design, I found that wireframes helped me iterate by making it apparent that some ideas may not work within our certain context.  Making the wireframes helped me get feedback and critique about the design and the interactions associated with it.  Wireframing became the main mode, after sketching our sketching phase, for getting critique because it allowed me to build upon what I had already created, allowing for more critique and leading to better designs.