Community Safety Web Portal
The community safety web portal provides automated background checks for peer to peer platforms quickly, accurately and at scale.

The community safety web portal is built to be a service to privacy team members within sharing economy organizations. It was designed to provide an intuitive solution for said users to easily understand the members in their community. 
As the sole product designer on the assignment, I was tasked with taking this from concept to reality. Within a span of three months, a tiger team consisting of one product manager, three full stack engineers, and four data engineers/analysts, successfully launched the beta version of this endeavor.
A PORTAL FOR THE SHARING ECONOMY  
While the journey of launching a product is rarely quick and simple, we needed to make sure the portal's user journey didn't feel that way. I spent a large amount of time ideating and wireframing various user flows with my product manager, Karishma. This process allowed us to propose user flows to the rest of the team and get early stage feedback from key stakeholders. After a few ideation rounds, we were able to finalize the user flow:

  1) Users first upload an input file of their member base into the portal.
  2) Next, our platform runs background checks on those members and returns those   deemed high risk, a parameter predetermined by the organization’s privacy team.
  3) Lastly, the user decides what members should be allowed in their community based   on the magnitude of their offenses.



SO, HOW DO I START USING THIS THING? 
In order to use the portal, users must upload an input file to be processed. It is a crucial step that must be done properly. 

Generally, our customers will be uploading input files containing large amounts of sensitive data about large sectors of their member pool. Input files of this nature are always in .csv format, which, after speaking to [deciphering] our data engineers, is basically a glorified excel sheet.

Two things were imperative to this step. We had to ensure files were handled securely given their sensitivity and they needed to be formatted according to our guidelines. 


WORKING WITHIN OUR LIMITS
Given our time constraints, we unanimously decided data security was paramount and should use the most amount of our dedicated engineering resources. Therefore, guaranteeing proper file formatting became the user's responsibility (for the time being). Irregardless, we still couldn’t have a situation where a processed file of 300,000 members returns invalid results due to improper formatting.
To temporarily circumvent this scenario, I decided to apply a two step confirmation to the uploading experience. In order to upload a file, the user must first check a checkbox confirming that they have adhered to our file formatting template. Only then, would they be able to upload a file.



WHO SHOULD I PAY ATTENTION TO?
The risk assessment section provides an overview of a company's high risk members and is the core of user engagement. 
Once the file has been uploaded, our algorithm does some engineering magic [that I won’t attempt to explain] and parses the data to segment members into our eight high risk categories (for category types, see mockup below). While the actual categories were determined by our team, the users are responsible for identifying which are high risk to their business.  
T.M.I.
The driving theme behind designing this portal was the concept of progressive information disclosure. Speaking with the team, I got a clear understanding of the amount of data available...let's just say there was a lot of information to digest. Reflecting on the potential use cases, I noticed they trended from users wanting general information to users needing specific details. I decided it would be best to sequence the copious amount of information according to their level of detail.
As a result, the data and resulting screens are stratified across three tiers of information: abstract, intermediate & explicit. It’s then up to the user to decide how much detail they would like to see displayed.

"Reflecting on the portal’s potential use cases, I noticed they trended from users wanting general information to users needing specific details."




STILL CAN'T FIND WHAT YOU'RE LOOKING FOR?
By incorporating a search filter functionality, we aimed to give users the ability to customize results to best fit their needs.
Thinking back to the main objective of the product, which is to service privacy team members to make informed decisions, we realized there was an extra level outside of the three tiers of information required; customization. There would inevitably be use cases we could not account for and with filtering we wanted to give the user the ability to modify the results to their liking.
MO' FILTER TYPES, MO' PROBLEMS - The Notorious B.I.G. 
Unfortunately, Notorious B.I.G never said this. However, Greg Nudelman shared a similar sentiment in his article, “Best Practices for Designing Faceted Search Filters.” While offering guidance on how to approach filter UX design, Nudelman outlined two types of search filters: drill down & parallel selection. He cautioned against trying to do both as they can lead to a confusing experience. I looked down at my sketches and immediately scrapped them...I was attempting both. 
Based on our product needs, a parallel selection filter type was the best fit since it allowed users to choose multiple selectors to filter their results by. For our purposes, it would be a better experience for a privacy team user to see members who fall under the traffic offenses category and live in the state of California, instead of one or the other.

PROJECT UPDATES
After launching the beta version, I handed off my responsibilities to fellow product designer, Hunter. He is continuing to make the necessary UI/UX improvements to take the portal from beta to v2.

Like what you see? Well there's more:

Back to Top