Hearth — Helping Those In Need Find Safe Help
UX/UI case study solving a need in local communities.
The project brief was to provide UX and UI design for an application to support homeless people. Initial discussions revealed that the app was really for case workers — individuals who work with people (persons without housing, victims of abuse, etc.…) to connect them with community resources like shelters, food banks, and so on. The vision was for someone to put in specific items that they needed, and then get a list of resources with information they could quickly act on.
The Problem
Those in need don’t always know where to go for help.
Social workers must build their own knowledge of community resources. The current process to find the needed resources is time intensive and hard to keep track of.
Data and Research
The client shared past research that really helped to inform and guide the project. They had done a couple previous iterations. There were others who tried to produce similar solutions. And there were even a few large competitors providing tools for this. The clients had already performed interviews and shared those notes and materials with me. That gave me a big head start.
This information revealed some key requirements. People in need often don’t have reliable access to internet or mobile data. Another issue is trust. They don’t often trust those trying to help them, making follow up support extremely difficult. This also meant the experience needed to be anonymous and not collect any personal or sensitive information. Case workers often work on the streets (or on the go), so the design needed to be mobile friendly.
Deeper into the project I realized another issue. Where was the data for these community resources coming from? Who was providing and maintaining it? The answers to these questions were important to provide real value in the application.
Target Users and Goals
While the end goal was to help those in need, it became evident that they were not the primary user. There needed to be a self-service aspect, where anyone could use this to find resources for themselves. Case workers or anyone in a local civic/social service would be the most frequent users. They were the true target persona. They wanted a quick way to:
- Put in someone’s needs.
- Get a resource list matching those needs.
- Share that list, or print it off and give it to the person in need.
Ideally, information that used to take hour or more could be found and shared in a matter of minutes.
My Process
I worked through a few iterations of flow maps and wireframes to make sure that we were solving the key goals. Sometimes gaps were revealed in our understanding or things only became clear after a couple iterations. Doing this helped us to arrive at clarity on the problem, and how best to serve those who really needed it.
Solution
The final experience was totally anonymous, requiring no account or personal information to find resources. A case worker or an individual could check a series of criteria for their needs. The list of data points was broad, so I broke the list into three areas. When someone is trying to determine how to match resources they could go through these sections in turn:
People
This starts the user on a path asking the first key question, who needs help? This considered aspects like gender, age, and safety concerns.
Needs
After identifying who is getting helped, the next question is, what do they need?
Services
This section gave a space to handle the nature of services. How do they need help? I.e., are these places open now? Are they free? What type of service is provided?
Entering any optional criteria returns a list of results with easily scannable and actionable information. Print styles were provided and kept simple, providing an easy and accessible way to share those resources with anyone. This was especially important for those who couldn't be emailed or texted this information.
In addition, a community moderated experience was proposed to support obtaining and maintaining the needed data for the resources. Anyone could submit data that would be primarily be moderated by the owner of the app. In addition, the community could make edits or additions with verified accounts. To ensure accountability, all edits would be public and information abuse could be reported — in a similar model to Wikipedia or similar tools.
Bonus: Branding
The project had no direction or plans for branding. That can be an important aspect of the UI. To avoid the design falling flat, I provided this logo option as a generous addition to the project.
Outcome
The client was super pleased with the final result. Further development of project was unfortunately stalled due to funding issues. However, with my blessing, he openly shared the prototype. He continued interviewing target users and received many positive responses. Some commented how much they wish they could actually be using it.
While it wasn’t something that has become a real working product (yet), it is still a project that I’m very proud of. I was able to follow a methodical design process and follow a lot of valuable research to deliver an efficient and effective solution. More than anything, this was something that could really make a difference in someone’s life. If this were to help even one individual, it was worth the endeavor.
Client’s Comments
You did a perfect job. It’s beyond exceptional.
I would say that I really liked your design process, the iterative feedback, and your overall final design. You had a great blend of really understanding the needs of the client while also offering your thoughts on how best to execute where it made sense.
What I would have done differently
I might have made the wireframes lower fidelity to start with. While it helped me to think through the user journey more clearly, it was confusing for the client at first. Good communication solved that.
