COLAB11 - Web App

Charody

Charody is a web app that helps provide temporary housing to families affected by disasters.

Problem Space 

Every year CA wildfires force thousands of individuals and families to evacuate their homes. From our research we’ve found that between 2015 and 2021, CA wildfires destroy an average of 8,444 structures every year, many of them being homes.

The 2018 Northern California Campfire alone destroyed 13,900 homes and forced 52,000 citizens to evacuate their neighborhoods in Butte County. In turn, CA wildfires displace families from their homes leaving them with few options to find a place to temporarily live while they rebuild their lives.

Disaster relief case managers help dozens of families, who have fled their homes, find temporary housing. In cases where families cannot immediately return to their homes after a wildfire, disaster case managers help them find temporary housing in the form of hotels and motels.

Often, the case managers run into expense issues as the organizations they work for cannot afford to pay for hotels for extended periods of time. The families themselves cannot afford the hotels either. As a result, case managers run out of housing options for the families and do not have the ability to provide them with any temporary housing solutions. 

There are homeowners who are willing to provide temporary housing to families who have evacuated their homes due to natural disasters such as wildfires. However, the concern of many of these homeowners is their inability to validate that specific families are truly victims of disasters. They don’t want to host people who are taking advantage of their kindness. Additionally, they want to know that the family they are hosting genuinely needs help and are good actors.

Research Insights

We started researching our problem space by interviewing organizations that helped people affected by wildfire disasters. This first round of interviews started with eight workers from FEMA, Red Cross, counties across CA, and even fire departments to understand each organization's role in helping people affected by wildfires.

We found that none of these initial groups were responsible for assisting victims in finding temporary housing in the event the fires destroyed their homes. Each of these groups directed us to another group to see who was responsible for helping victims attain temporary housing. 

Eventually, the interviewees directed us to a few nonprofit organizations (NPO) that worked with victims. The NPOs explained that they have community case managers who work directly with people whose homes were affected by wildfires.

We learned that case managers verify and validate every individual or family they work with to ensure they are legitimate victims. They help families find temporary housing and assistance. And they monitor each family to ensure they get back on their feet. 

We interviewed five case managers from various NPOs to understand their roles in helping victims, their problems, and what they wished they had to help them do their jobs better. 

User Pain Points

Based on the user interviews we conducted with case managers and other wildfire relief workers, we noticed some trending problems in this area.

  • Mass shelters constructed during a wildfire close after 30 days. It becomes difficult for case managers to find temporary housing for families whose homes are in too bad of a condition to return
  • Case managers explained that even when hotels/motels are an option, it gets too expensive to house multiple families at a time
  • Family pets were not always allowed in mass shelters, and the families did not want to be separated from them.
  • FEMA assistance can be prolonged, and victims wait a long time to receive any help

Feedback

Uncovering the case manager pain points about dealing with temporary housing led us to investigate the idea of volunteer home sharing as a possible solution. Subsequently, we wanted to understand homeowner’s thoughts on this subject. We conducted interviews with homeowners to get feedback on this space and understand their concerns.

Five interviewees participated in a virtual generative research interview session to understand what they’d expected to see on a disaster relief site and what they wanted to know about the process of hosting.

The key themes were knowing how the process works, volunteer homeowners are motivated by making a difference, and if they'd receive support.

  • Homeowner interviewees wanted to help disaster evacuees but need the feeling of safety and knowledge of how the program works.  
  • They want to know they're making a positive difference and are motivated by making an impact.  Pictures of hope and stories capture their hearts. 

  • 3/5 homeowner usability testers wanted to see testimonials to encourage them to sign up
  • 4/5 testers wanted an emotional connection and to sympathize through images


Landing on the Solution

Based on the case manager pain points and the feedback we received from homeowners, it was apparent that each user could help the other solve the problem of temporary housing for disaster victims.

Homeowners wanted the people they allowed in their homes for an interim period vetted. Case managers vetted each family they worked with. Case managers needed a safe and secure location to place families, and homeowners in the community were willing to offer that. 

We figured that by creating a way for disaster case managers to connect with homeowners who've expressed their willingness to temporary house evacuees, more families displaced by wildfires would find safe and secure temporary housing. We decided that a web app would be the best platform to encourage this connection. 

Here is a list of some of the high-level features we wanted to implement

  • A Homeowner profile allows users to input their contact information, location, and specifics of what they can accommodate as hosts.
  • ID and photo uploads in the homeowner profile to verify that the face and information match
  • A page that organizes homeowner profile information into a list that can be filtered based on accommodation specifics and location
  • Email verification for our case manager partners to maintain exclusive access to the homeowner listings page information


Lofi Mockups 

Iterative Design Learnings

  • 3/5 usability testers were unsure of how to login with the first design
  • They wondered if the two options were modals 
  • There was an A/B test for the second and third designs with a unanimous vote for the third design 

  • During the second usability test, 3/5 homeowner testers were confused by the "home" icon because "home" was associated with the "homepage". 
  •  "Home" was changed to "home details".​​ 
  • 4/4 disaster case managers wanted to know the evacuees were hosted by trustworthy people.
  • We implemented an "verify ID" step after combining "contact" and "info" screens in the previous design.

Our “How it works” section in the homepage had to reflect Charody vetting the homeowners’ trustworthiness and for homeowners to trust Charody with their information. 

  • Step 1: Changes included homeowners needing to have ID and photo verification. 
  • Step 2:  Added that the partner organizations are verified and were the only ones who can access homeowners’ info.

Hifi Mockups

Implementation Details

Technical implementation

Charody is hosted via Heroku and Netlify. Charody features MERN stack with additional implementations in Google Cloud Storage and others. Data is created through the signup form and gets stored in redux on the front-end. When users are ready to submit their information, data is sent to the back-end where it is registered on the database and eventually makes it's way back to the front-end as a parsable.


Technical challenges

What was the hardest part of development?

  • Dylan: Finding the time to work on the project after starting a job.
  • Chao: The most time-consuming problem is deciding how to implement a feature. Because there are multiple ways of implementing a feature, some being more efficient than others. There is always a catch and a series of conditions which later means that you might have to rewrite everything you were just working on.


Does your app have any scaling issues?

  • The ‘download listings as CSV’ feature could become problematic as we scale. We had not initially decided how to handle a large scale of data so midway through we had to decide on how to implement a feature that can handle a large amount of data.


What are some key takeaways? 

  • Chao: A lot of time spent was wasted due to indecisiveness and reconfiguring. Something that wouldve worked out better wouldve been to take a break and let the idea sit and plan before tackling implementation.


Future Steps

Based on user testing it was suggested about including more hosting accommodations like RV and trailer parking spots. We will consider these suggestions in future iterations of the web app. 

The team has discussed plans to continue introducing the Charody web app to Nonprofit partners. In the event of a large wildfire, Charody can now allow volunteer homeowners to sign up quickly and for case managers to contact them if a family is in need.

Team Learnings

Product Manager Learnings:

Robert Mullins III

  • Prioritizing our backlog based on user requirements was essential in ensuring we were developing features that brought the most value to the product.
  • It is important for team chemistry to consistently hold each team member to the standards set by the team in the beginning of us coming together.
  • I learned how to implement an agile system where we strategized, designed, developed, and iterated to build our MVP web app.   
  • Lastly, communication through documentation was key in keeping the team aligned on what we were building each sprint cycle and why we were building it

Designer Learnings:

Haira Esther Kang

Due to being considerate with team members’ skills and expectations, I noticed I was passive with design decisions. There were times we lost focus in making the product easy for the users instead of for ourselves. Halfway through the program, we were able to regroup and think about the users’ needs rather than our wants. 

Since there was no UXUI mentor in the program, I realized the times I wanted guidance were when I was working on my designs. With this, I still need to practice my UI and Figma skills. Additionally, there are still many UX research methods I’d like to explore and the challenges we had with content sparked my interest in UX writing.

Developer Learnings:

Chaoneng Tan

Collaboration and Responsibilities: Throughout the program, there has been plenty of hitches and progression. One core idea I was able to internalize more was the scope of our responsibilities. There were plenty of times where back-and-fourths happened between wants and needs and ultimately, the decision was up to the person in which the feature fell within the scope of.

Technology and Specialization: In the age of technology and with the diversity of upbringings, there are always preferences and alternatives. The differences that we must identify and understand is the core concept of the technology. There were times in which I’ve identified unfamiliar designs but realized that the outcome is not as far-fetched as what I had imagined.

Developer's Learnings:

Dylan Floyd

The most valuable thing I learned through Co.Lab was definitely how to stream file transfers. I built out image uploads and downloads to Google Cloud Storage for Charody, and I happened to be building out the same thing at my day job.

Getting to do the same thing twice allowed me to revisit my approach, which made me realize we really needed streaming at my job. The less optimal approach we were about to launch would have used multiple gigabytes of memory, but our servers were limited to just 256 MB. So thanks to Co.Lab, I was able to tell my boss we were about to crash our website, and I knew how to fix it.

More generally, I learned that addressing team issues early is important, and that I shouldn’t underestimate anyone's ability to improve their behavior. It’s easy to brush issues off and assume talking about them won’t help, but it’s much better for everyone to bring up issues as soon as they’re a pattern.

Full Team Learning

  • Learned that having a baseline understanding of the software used to build the product helps the discussion amongst teammembers when developing product solutions.
  • Having a clear and objective product idea leads to better understanding and clean production.
  • Communicating team issues early is important.
  • Despite different working styles, personalities, locations, and schedules, we pulled through together with patience and understanding for one another which helped us create an impactful product.