Raheem
Timeline: 2 months
Team: 2 UX designers, 3 front-end developers, 2 back-end developers
My Role: UX designer and researcher
Case Type: End-To-End App Design, User Research, UX Design
Raheem is a nonprofit dedicated to ending police brutality by allowing users to share their stories and empowering them to report on “bad apples” within a police department.
One of the founders came up with the idea after his partner was murdered during a routine traffic stop.
Before my team was brought on to the project, the company had already crafted a website with a form for users to report on interactions with officers during traffic stops that were both good and bad.
The stakeholders wanted our team to make a separate report form that could quickly and easily be submitted from the side of the road after a traffic stop. To support the immediacy and real-time data of the reports, the stakeholders had the idea to have a QR code on traffic tickets — an idea that they would be presenting to the Oakland police department, which is a police department that the company works with directly to help influence the department’s policing. Therefore, the product we were tasked with creating was more a proof of concept than an actual product.
Because the company had already conducted extensive user research to find out who their target audience was, we already had an idea of who would be our primary user. Based on their research, the primary user was someone who had experienced police violence to some degree.
I led a brainstorming session to create an initial user flow, which helped get us started in brainstorming wireframing iterations — for example, having multiple pages vs. one long page.
We made low-fidelity prototypes that we then prototyped, and then I did in-person usability testing, where I watched and recorded users interacting with the product.
From that test, we realized that users actually prefer one long form vs. multiple pages. Raheem’s analytics confirmed that, showing that there was a significant drop-off rate for their original multi-page form.
Instead of copying the exact form on the Raheem website, we:
However, usability testing indicated that not everyone would want to write a whole breakdown of what happened, especially while on the side of the road recovering from a traumatic traffic stop.
“I don’t want to write anything. I’m angry, the cop pulled me over. Click, click, send. I’m not the type [to write a whole review].”
— Richard A., User Tester
And so we:
In the beginning, the stakeholders seemed to have wanted a data-driven product, one that would collect tagged info and then you could gather that data to present to governments and policy-makers to show that this worked.
This is why we originally pushed to have the most important data to be easily answered via multiple choice by the user, and making the story mode optional.
However, the stakeholders later said they wanted the product to be more focused on the “review” portion — making stories more important and top-of-mind for the user.
And so we had to add buttons and shift a lot of the language to encourage the user to continuously go to the page where they can share their story.
We also made the “stories” tab on the officer dashboard first and most prominent, and created a detailed filter and sort system to make all the stories easily searchable and accessible.
The stakeholders also thought that our method of collecting emails for the website to create reminders for the user to finish completing the form later (specifically the story section) was clunky, and may contribute to user drop-off. They wanted the emails to be collected on the first page form instead of having the user to navigate to another page to add their email as it was more efficient. After that suggestion, we realized that it helped the user flow be more streamlined.
Originally, we made the text box page seem as optional as possible, even writing “optional” and indicating that the previous form page was submitted by having a “thank you for your feedback” declaration at the top of the page. But we changed it by taking the “optional” and “thank you for your feedback” out.
We also changed the button on the form page. Originally the button said, “add this report”, but then we changed it to “continue” to indicate that the user wasn’t done with their submission.
It was important to emulate the look and feel of the website as much as possible, so we based our designs off of that. Color palette and typeface was already in place. We got the colors and typeface from the Raheem team and made it a “style” in the Raheem figma so we could easily iterate and have the front-end team have easy access to what it all looked like. We showed the team how to access the visual design in the figma doc, so they could align their coding with our work.
The only thing we changed and iterated visual design-wise was deciding on how to group together the two different fonts (one was a serif, the other a sans serif).
We knew that drop-downs wouldn’t work with our mobile-first product because that could be difficult to navigate with a user’s fingers depending on how large their fingers were. So we needed to figure out the best way to indicate that a user can click on multiple options, or just one singular option, landing on the idea to have tags for multiple options and radio buttons for single options.
There was also a lot of black, white, and grey as we were iterating, so we wanted to incorporate the primary color, yellow, in the most effective way possible, deciding to use it as a highlight to direct the user to important actions, such as the headers in different sections of the form and in the slider.
Because this is more of a proof of concept product, there is no clear way to know if we’re solving user problems. It’s more about solving our stakeholder’s problems. The success of our product is beholden to whether or not our stakeholders are happy with the product.
After viewing our version 1, the stakeholders were mostly happy, but whereas originally the stakeholders wanted a data-driven product to give policy-makers real-time data on a community’s officers, they shifted to a “story-first” point-of-view and wanted us to instead focus on producing the stories. Because of that, we changed the verbiage in our version 1 to reflect the emphasis on story, and we used that information to brainstorm how to layout and design version 2, which is the officer dashboard with the stories and data about the officer.
This led to the creation of my favorite feature, the dashboard, which was also the biggest hurdle I had to overcome technically. I had never designed a dashboard before, let alone a statistics-based page (which, in general, is overwhelming to me since I don’t do well with numbers), and I was tasked to design a visual component to the information we were presenting.
However, I ultimately landed on one that had a general gray-scale of different gradient intensities with a muted yellow and a yellow-green to complement Raheem’s bright yellow color style.
This jived well with Raheem’s color palette, and also gave enough variety to accommodate color-blind users. But some of the colors didn’t necessarily work well together, so I indicated which data would have which color to avoid putting together colors that don’t work well.
The result is aesthetically pleasing and works with the style guide we had to work off of:
It is important to stand up for your design decisions using user data to prove that it’s more user-friendly, but to also be mindful of the stakeholder’s unique needs and demands. Learning how to balance both was a struggle at first, but once I was able to be more flexible, the end product was both user-friendly and met stakeholder needs and standards.