Develop a map-based, resource platform that enables Life After Hate to more effectively provide service to people trying to leave hate groups.
Product Designer, Front-end Developer
September 2019 - May 2020 (9 months)
Design: Sketch, Adobe Photoshop
Coding: React.js, Node.js, MongoDB, Mapbox
This is a 2 semester project done with Hack4Impact aimed at extending the reach and efficiency for nonprofit Life After Hate (LAH). Hack4Impact is an UIUC campus organization of students passionate about using tech for good. We develop products for nonprofits to help them further their mission and better engage their clients.
They accomplish this goal this by connecting former hate group members or members trying to leave hate groups (called formers) to resources and partners within the LAH network.
These partner businesses/individuals have volunteered their services and time to help those who are exiting hate groups. The LAH staff will then put the former in contact with these partner services to help them leave violence and racism behind. Some examples of resources are tattoo removal, career preparation, and education. ExitUSA is the specific branch of LAH that executes this process.
"Each year, more than 250,000 people in the United States are victims of hate crimes. The vast majority are violent and more than half go unreported. Between 2008 and 2017, 71 percent of extremist-related fatalities in the U.S. were committed by members of the far right or white-supremacist movements. LAH helps people leave the violent far-right to connect with humanity and lead compassionate lives." - Life After Hate
When helping people leave hate groups, LAH staff members need to sift through their resources located on many different platforms: Excel, email, paper, and more. These resources can be either businesses or organizations that will support ex-hate group members willing to change.
This time sunk looking for resources is time not spent helping people exit hate groups, limiting LAH's reach as an organization. This bottleneck in the support process can also take up to days to complete. By automating and organizing the search process, we can speed up the process of matching resources to formers. We wanted to create a highly-secure, easily searchable, centralized web application to host and manage these resources. This way, we can enable LAH to spend more time serving people and accomplish their mission on a larger scale.
When we heard about LAH's problems, we saw an immediate opportunity to help. Our organization aims to help nonprofits broaden their impact, and we do that by creating the necessary tools so that they can better focus on their core mission. When building a product, we put an emphasis on scalability, user-friendliness, and intentionality. We put special thought into building a product that can scale with the organization and support more staff along with the organization's future goals. Through rigorous user research and testing, we optimize the UX of our applications by building around the user. To make the product as impactful as possible, we personalized it to the use cases of the nonprofit. We consider the nonprofit the priority and end user, meaning that our products are made with their goals, staff, and audience in mind.
After a few calls with LAH, we found that a map view would be necessary for the platform since location and proximity of resources are important when LAH helps individuals. The map view would serve a similar purpose as websites such as Redfin, giving a visual representation of data to help illustrate distance and positioning. We are not as focused on the landscape as Redfin is when choosing real estate, but this map view is still necessary since proximity is important for our product. There is also the chance that the user may want to do a high-intent search, meaning they are looking for something very specific such as a particular resources contact name. In this case we need to display search results in a way that allows you to quickly skim through resource details. We did this by adding a separate directory view. This directory view focuses on displaying the details of the resources in a spreadsheet format to make it easy to quickly find the intended resource.
I served as the Product Designer on a team with a Product Manager, Tech Lead and 5 developers. We had two different teams for the Fall and Spring semesters, only difference in composition being that the Spring team had one less developer.
As a designer and Front-end Developer, I was in charge of the UI and UX of the application. I worked closely with the Product Manager to help create user-centric prototypes and mockups, while also working with Front-end Developers to implement these designs in React.js.
The first things we had to address before we got building were the scope of the project and the constraints. We needed to ensure we were picking the most impactful features to include in our product while also considering the complexity that these features may bring to the project. By thoughtfully scoping this project out, we ensure we build a product that most effectively addresses LAH's problems in 2 semesters of development.
I gave a brief overview of the rationale behind the choice of having the map view along with the directory view. This gives a broad solution to LAH's problems, but there are many details that still need to be explored.
One feature we actually passed on was the optimization of the map view for mobile. Given our users, we found that the application would be used almost exclusively on desktop. The time we would spend making the map view on mobile would be better spent working on another feature, so we decided to pass on scoping a complex feature that would see little to no use.
Since Hack4Impact works in increments of 1-2 semesters, it is important that we weight the complexity and impact of features against each other when deciding to include them or not. We have to prioritize completion of more important features to ensure we create the optimal product in our defined time frame.
One constraint that was immediately obvious to us as an organization was the handoff from one team to another between the Fall and Spring semesters. We needed to ensure the second team could easily understand and work off of the existing codebase. We would need to pay special attention to naming conventions, code formatting, and standardizing the site structure.
The way the project would pan out is that the Fall team would focus on the map and directory view while the Spring team would focus on account management and tying up loose ends. We focused on addressing the main map and directory views first so that we had time to process user testing and feedback to improve our principal features.
Another constraint we came across concerned the security of our application. The data that we are displaying on our application has personally identifying information for the individuals and businesses volunteering their services. If a hate group were to get their hands on this information, it could be catastrophic for those businesses and individuals. To ensure the security of this information, we opted to use Google OAuth to handle sign-ins. Google is a widely used and highly secure service, so it was an optimal choice to ensure security and inclusivity for those who will access the platform.
Before we start creating the designs for the application, we need to fully understand the audience of our application and some existing alternatives.
Starting with some alternatives to our application, the most obvious one is Excel/Google sheets. Both products allow for easy filtering, storage, and displaying of resource information. These products are similar to our directory view, but our map view remains unique. When creating this product, we will keep in mind the similarities to Excel and Google sheets. We can use this to our advantage by asking for pain points that LAH currently has with using Excel to store their resources.
For the map view, there are not really any intuitive consumer projects that could store resource information and display dynamically on a map. This is where we see a lot of value and use coming from our product. As a result, we will invest more time developing the map view.
The first thing we need to do is define the user. In terms of our immediate users, we have the 2 staff members of LAH. We also need to keep the potential volunteers in mind. Our product has a well defined use case, where all our users will be using this platform to search for resources and occasionally add/edit them.
We couldn't rely on 1-2 users for all user feedback to build this application. We had to extrapolate some of the feedback to see if our platform would work for a generalized audience with little to no friction. To do this, we had Hack4Impact members test the function of our application prototypes and extensively researched the audiences and design decisions of similar products like Yelp, Google Maps, WebMD, and Redfin.
By doing some research on our users, we are able to come up with a list of user needs and other characteristics that will influence our design. By asking questions to LAH staff and volunteers, we were able to define the following user needs:
After identifying the user needs, we can go straight into building out the user flow diagram. This will help us lay out the architecture of our application in terms of actions + screens by building around the use cases of the app.
Some of the use cases we can identify are:
We can base our user flow diagram off of these 6 actions. This diagram combines all 6 actions into one graphic:
In the user flow diagram, the dark orange shapes represent our starting points and the completion of a user task.
By building out a user flow, we can build out the skeleton of our application and easily see what tasks take too long to complete or are not the most intuitive. This is a good foundation for building the UX of the application, and is extremely simple to draw out and visualize. We often cannot optimize every action to be quick and intuitive. In our case, we prioritized the speed and ease of searching over the edit resource function.
After perfecting the user flow diagram, I got to work on the wireframes for the app. When creating these wireframes, I worked off of our user research and based the layout off of similar products (Yelp, Google Maps, WebMD, and Redfin).
There were quite a few problems where we really dug deep to solve. I've outlined some of our more impactful design decisions that we made to provide a better experience for the user.
When searching, we had 3 different types of data that factored into the search ranking: location, tag, and the keywords. Having 3 different inputs would make searching much slower. How do we keep the form user friendly while still collecting all the data we need to make a search?
We had to go back to the differences between high-intent search and general search. We had already decided that high-intent search would be on the directory view page, while the general search would be on the map view page. So we broke down exactly what we needed to make both of the searches.
General search: We decided that keywords and tags were interchangeable and that location was a staple. This search is more broad, and from our user research, staff would likely be using one or the other. Through following principles of Postel's Law, we decided to make the second input highly versatile by accepting both tag and keyword queries. Postel's Law states that you should be Be liberal in what you accept, and conservative in what you send. We keep the search open ended and keep the results relevant to what search query was given to us.
To make this work, we created a weighted search algorithm that weighs the keywords that are found within resources. Based on research and user needs, we created a search ranking system with the following components contributing to the rankings:
Each components has a specific weight based on how well the search query matches a resource and how important that aspect of the resource is.
High-intent search: Because of the nature of high-intent search, we decided to include all 3 data components in the search. Location, tags, and keywords. This is a highly specific search, so we want to allow users to have a high level of control over their search. The user still has the choice of leaving any field blank, but all options are provided.
We used a slightly modified version of the keyword scoring above, with the only difference being that the tag can be explicitly defined. This allows the user to really narrow down search results.
We spent a lot of time considering the layout and function of the search bar. We also revised the location input field to be extremely forgiving in which location formats could be accepted. For example, queries as simple as just "Chicago" or as complex as "600 E Grand Ave, Chicago, IL 60611" would both be accepted. With some extra engineering work and some research into basic search algorithms, we were able to optimize the user experience in both search cases.
Resources are very complex and contain a lot of data. When displaying many resource cards on the map view, we need to find a way to display the data in a digestible manner so that users can easily skim or provide more detail if requested.
When designing this card system for the resources, we needed to work around this idea of cognitive load. We wanted the user to understand the information while also keeping the cognitive load low. This means limiting the information presented to only the most important items and also structuring the data in a user-friendly manner. While this is great for skimming, we still need to make the details of a resource accessible. To accomplish this, we designed around the principle of progressive disclosure.
We progressively display information with 3 states:
condensed card → expanded card → modal window
Each progressive level will present more data, eventually displaying it all when you reach the modal window. This progression is representative of user behavior on the map view. When browsing for an item the distance, name, and tags are generally the most important, with a description to add some context. Then if you want more, expanding the card reveals relevant information to give to the former, including the address, contact, and phone number. More specific results are listed on the modal window if necessary. But we kept all the most relevant information within one click.
Currently our map view is focused more on slowly guiding you to the information you need from a given resource through progressive disclosure. This method works great for users who may not be familiar with the UI or the specific resource. But for some of our users (LAH staff), this application will be see extended daily use. The staff will be extremely familiar with the resources and the use of progressive disclosure will unnecessary in many cases. So how do we make our card design more user friendly for power users?
We need to implement a feature that the power users can utilize without the interrupting the user experience for other users. We had to consider the behavior behind why the current model doesn't work. The LAH staff (power users) are highly familiar with the resources because they add them to the application and frequently contact them. Often times they know all the details of a resource, they are only looking it up on the platform because they need a specific detail they may have forgotten. Because of this, the intermediate step of the expanded card is unnecessary. They want to get directly to the modal window.
To cut the expanded view out of the process, we add a non-intrusive 'shortcut' button in the top right of the card. This button takes you directly to the modal window. This button disappears and is replaced with a 'close' button when the card is expanded. By doing this, we give the option to reduce the number of clicks it takes to go from condensed card to modal window from 2 to 1 click.
Since our project spanned 2 semesters, we were able to invest time in user testing. We had most of the main components built out in the fall semester (map view, directory view) which allowed us to spend spring semester pinpointing usability issues with ample time to revise.
We primarily did user testing with the LAH staff and people who did not have a deep understanding of the application. We asked the users to try and complete certain tasks and documented the processes that each user followed to get to the end goal.
Through testing, we found that a lot of users were clicking on the 'tags' of a resource. After further research, we found that the tags resembled buttons. They had an outline and used the same bright orange accent color as the buttons and map pins, both clickable objects.
Our initial solution was to revise the design to have no border and use a more neutral color, but we decided that this was a necessary feature to add. The pilot users were trying to filter by tag. They needed it to complete their task and were left frustrated when it did nothing and had to go to plan B. We left a lot of time to work on usability issues, and decided it could be added to the scope without any adverse effect to our current timeline.
I already went through the reasons for leaving a dedicated tag filtering input on the map view search in the 'Key Issues' section above, but we decided that it somehow needed to be incorporated.
We took a look at the user behavior and noticed that users were only clicking on the category tags after they couldn't find what they were looking for in the top results. For most users, filtering becomes important after they have started scrolling through the resources and want to look at related resources. Going back up to the search bar and typing the tag in would be more work, when the user could simply click on the tag.
I want to reiterate that this map view is being used for general searches, meaning that they often will not have a tag in mind unless they see it. If they are looking for a specific tag, they would search in the directory view.
Having a clickable tag acts as a "recommended" section to find related resources. So the implementation we designed was to have users click on the tag they want to filter by, and this would be added under the search bar and re-trigger the search.
You can easily remove the tag simply by hitting the 'x'. By adding this feature we will make it easier to browse for resources. This may be a little bit less useful for power users who know exactly what they are looking for, but when this product is expanded to volunteers we expect to see the feature utilized more.
After all of the user research, prototyping, and user testing we came to our final designs. The Front-end Developers did a great job implementing the designs in React.js throughout the 2 semester project.