Neighborly

User research insights

Findings from research was synthesized into 5 identified 5 and 5 proposed solutions.

Problem

Insight

Anxiety

People often hesitate when asking for help due to fear of embarrassment and uncertainty

Templates

Use prebuilt templates so users can ask for help without having to draft a request from scratch

Lack of trust

People feel uneasy trusting a stranger online to successfully complete a task for them

Reviews

Implement a review/rating system so volunteers can be verified as “trusted”

Safety

Existing tools such as Nextdoor and Buy Nothing require user data, increasing safety concerns

Anonymous pseuduonyms

Allow users to use anonymous pseudonyms. Don’t require any data beyond email or phone.

Volunteer burnout

Volunteer burnout is the #1 struggle for mutual aid organizations

Fluid roles

Allow users to switch between volunteer and user easily, so they aren’t trapped into a specific role.

User personas

I developed four distinct personas to represent the 'Supply and Demand' of mutual aid, ensuring the interface felt as safe for the hesitant seeker as it did rewarding for the busy volunteer.

Maria (The Overwhelmed Parent)

Pre-built Templates:

To support Maria’s busy schedule and "low energy" pain point, I implemented quick-tap categories (Groceries, Manual Labor) that auto-fill requests, reducing the time and cognitive effort required to ask for help.

Ari (The Hesitant Student)

Anonymous Pseudonyms:

To resolve Ari’s "fear of embarrassment" and desire for "dignity," I designed an onboarding flow that generates randomized usernames, allowing her to seek financial or grocery aid without social stigma on campus.

Jordan (The Dedicated Volunteer)

Fluid Roles Toggle:

To prevent Jordan's "burnout," I created a prominent header toggle that allows him to switch instantly between "Volunteer" and "Seek Help" modes, signaling that it is okay to be on either side of the community.

Rosa (The Cautious Neighbor)

Review & Badge System:

To ease Rosa’s "uneasiness trusting strangers," I implemented a peer-to-peer "Badge" system (e.g., "Great Neighbor!") that serves as a visual trust signal from other community members.

User journey maps

I mapped the parallel journeys of the Seeker and the Volunteer to ensure that at every point of high vulnerability, like asking for help or entering a stranger's home,the app provided a specific safety net. For the Seeker, this meant emphasizing privacy during onboarding; for the Volunteer, it meant providing clear expectations through categorization.

Volunteer journey

Help seeker journey

The first designs

During this rapid iteration phase, I explored five different entry points for the user.

I ultimately decided to move forward with a hybrid of Option 2 and 5, with Option 2 as the landing screen and Option 5 as the dashboard displayed once the mode is selected (Help seeker or Volunteer).

This provided the clearest path for the two distinct user journeys (Help seeker and Volunteer) while keeping the community feed front-and-center.

Information architecture

After exploring various landing page concepts, I mapped out a two-path information architecture. My goal was to ensure that while the Help Seeker and Volunteer have different primary tasks, the transition between these roles remains frictionless. This 'Branch Logic' allowed me to maintain a consistent navigation system (Home, Requests, Messages) while tailoring the feed to the user's active mode.

Wireframes

I continued iterating on designs for other screens.

I continued this process until I developed wireframes for my planned user flows.

Prototyping

I protyped my wireframes in Figma to create user flows designed for 5 separate tasks that participants would be tested on

Tasks:

1. You’ve just heard about this app and want to see what's happening in your neighborhood. Set up an account without using your real name.

2. You need help moving a heavy sofa this weekend. Create a request for help in your local group.

3. Switch to 'Volunteer' mode and find a neighbor who needs help with groceries. Reach out to let them know you can do it.

4. You are currently looking at requests in 'Lake Jackson,' but you want to see if anyone needs help near your workplace in 'South side.' Change your group.

5. A neighbor just helped you with a task. Mark it as finished and let the community know they were helpful.

Conducting the usability study

To validate my high-fidelity designs, I conducted a formal usability study with six participants. By tracking their Click Paths and recording specific Quotes, I was able to identify remaining points of friction. This data directly informed my final iterations on the 'Mark Complete' flow and the group-switching navigation.

Microsoft teams meetings were conducted and recorded for the test .

Participants were given each task consecutively.

Sessions were reviewed and observations were notated in a prepared Excel sheet.

Participants then participated in a System Usability Scale questionaire.

Usability study findings