February — April, 2016
This was a semester-long group project done in 5 separate sprints/milestones. After starting with ideation and concept building, we then compiled a list of user requirements and technical limitations. Shortly after we began sketching and prototyping. This is where a large portion of the iterative design process came into play. We then refined our screens, annotated them, and dove headfirst into an intense testing phase.
Currently, civilian’s access to police data is limited to their state or city’s website, and a few different information dumps. The data is not easy to find, read, or decipher. Current options show large spreadsheets of data with no, limited, or confusing visualizations. We want to open police data for users to easily understand, draw conclusions, and become more involved in their communities. We want to foster engagement and connectivity while heightening awareness and police accountability.
I was personally in charge of the data visualization portion of the app. This include sketching, designing, testing, and iteration. I also was in charge of the formal write-ups, and a large portion of digital and in-person user testing.
In the UX milestones, my primary role was focusing on the data visualization task flow and user journey. In preparation for this, a few simple personas were drafted based on our demographic for different use cases. The primary persona that I designed for was Jason Moore, the 28-year-old veteran. He is a new homeowner, and politically a libertarian. He’s very interested in increasing transparency to keep police officers accountable.
We began by dividing the project up by tasks. My task flow, specifically, was the visualization side of the app. In a user story format, “As a user, I can visualize data.” The task flow can be seen below.
One of the exercises we took part in asked us to sketch each primary screen from our task flow in an extremely short amount of time. This allowed us to quickly realize problem areas, and hammer out the design until it was boiled down to its essential parts.
A portion of this milestone was establishing a set of technical requirements for our design. While these did change as we continued, we started off stating the following:
"Our product is a website designed with mobile first principles. There will be no OS specific constraints. We will be designing with Spanish speakers in mind. We will also be considering people who suffer from color-blindness since we will have a lot of data visualizations. Our website will require Internet connectivity. We will be considering translation to Spanish. The requirement of using the mobile web will be difficult because we are building such a robust website. The constraints of the web and browser standards will present a challenge."
In the end, this was helpful to begin pushing us in the right direction. The website became an app when we realized how much we had limited ourselves and the extent of the potential use cases for the application.
Initially, we began the design process with research. We considered existing apps and websites that relate to this topic, as well as ethnographic research to find an accurate and relevant demographic.
When researching our demographic, we found that this topic transcends any form of race or socioeconomic status. We want to continue to nurture that and ensure that our application is not exclusive in any way. Since the emphasis is on unification, respect, and a generally positive message and attitude, it’s very important that the app itself emanates that sentiment through its means of reaching the demographics. The app cannot target a specific race, socioeconomic status, or gender, and instead must attempt to be as open as possible, while still being effective at accomplishing the user tasks.
I was largely in charge of the digital testing. A digital prototype was sent to a select group of people inside our demographic alongside a short questionnaire on Google Forms. The intention of this was to gain more quantitative and diverse data from our user base. Being digital, it allowed us to reach out to people who we normally would not have been able to reach. In this process, we learned a lot of valuable information about our app, and specific pain points that the users were experiencing.
We learned that not including an onboarding process in the prototype really confused people. There’s a fairly large discrepancy on many of the usability questions that is telling of the problems some users were facing. Some people had an easy time, others struggled. The goal, obviously, would be for all users to rate the experience a 10 / 10 on ease of use and conveyance. Thankfully, all the responses on the need for technical assistance were on the low end, between 1 and 5. Using this data, we can add an actual value to the struggles of our users, allowing us to have a more solid justification for design changes.
Interestingly, the tests done in person had much lower ratings for a lot of these questions. One participant rated the app as being generally difficult to use and expressed the need for assistance in navigating it with the ratings 1, 8, 5, 8, 5, and 3 respectively. Conversely, one of the other users tested in person gave fairly high ratings and did not express the need for assistance. This participant gave the ratings 7, 10, 8, 2, 6, and 8 respectively. This user did have a hard time navigating but rated everything else higher. This dichotomy between the tests is actually problematic and needs to be solved. Some of our users are struggling while others are scraping by.
One participant commented the following:
This feedback, and much more, greatly informed the final prototype. We found a lot of small moments of friction in the user’s flow and ironed them out in the next milestone.
Interaction patterns, and visual design; Material design inspired neutral design. In designing the style guide for our application, as well as initiating the UI design process, my role was to take charge of the interactive patterns. In taking charge of the interactive patterns I found that it would be best to display my line of thinking with a quick motion piece, as well as an in-depth write-up. As a group, we decided to follow Google Material Design standards, so our style guide was built off of that.
A lot changed through the process, and the final result is a product of that. Starting with a very blue interface, we eventually worked our way to the final product based on user feedback and test results.
I oversaw establishing the interactive patterns style guide. Below is a video establishing the way the app would move, as well as an in-depth write up to explain it.
Everything has a different layer in Z space that it occupies. So, the top bar of the app would theoretically be at a depth of 2, the keyboard and suggested searches that pop in would be at 1, the search results would be at 0 and the hamburger menu always lies underneath the content of the app at -1. Alerts would pop over the app at a depth of 3.
To keep the user from getting “analysis paralysis” we will only show a chunk of the data at a time. Pressing the down arrow (or a single tap anywhere in the pane) will expand the pane to make the content more visible.
This pane can now scroll independently of the rest of the app. Scrolling vertically should function as expected, but due to the nature of a large amount of information, scrolling horizontally is also crucial. The pane should resist the user a tiny amount as they gesture to scroll over to the left or right, but also still indicate that it is possible to scroll in that direction. The spreadsheet should snap to columns as you scroll through, make it easier to get your bearing on where you are in the data.
Menus should move in from the right, and go back that direction when closed.
Pressing anywhere outside of the Menu / Pane / Card / Popup should close it.
We will follow the Google Material Design patterns for the following: Data Formats, Empty States (Especially best match), Search, and Errors.
In the prototyping stages, my role was to push the group as a whole through several stages of iteration and to refine my design based on feedback from presentations and quick design reviews with 3rd parties. In the original presentation, all of the UI was black and white. This decision came largely in part due to our desire to be neutral in tone and color palette, as to not influence the user’s thought processes or emotional state. While the concept sounded good, in the end, it made the final product not look complete or whole. So, the first big round of prototyping was us trying to find the best color palette. I pushed us along that path as I tested out a very blue design, and iterated upon that.
Our prototyping stages began with visual design and style, but that quickly got locked down. We tried a blue version, and it felt a little social networky, so we moved on. Once we had the obvious visual design problems out of the way, we were able to get into the actual user experience design portion of the app. In our testing, we found lots of little errors or oddities that hadn’t stood out to us before. From those findings, we refined our prototype and worked it down to a functional product.