Problem Solution Process & Contributions Research Developing the Solution Preparing for Launch Design Decisions Reflections

FightPandemics: Facilitate "match-making" process for mutual aid groups

Cross-platform design of an app that facilitates connection among individuals and organizations during pandemics

Duration

Mar.2020 - present

Role

UX Design Co-lead (with Enialo Leon)

Team

Collaborated with 2 designers, 3 product managers, and 3 engineer leads, the business owner among others

Results

Webapp MVP shipped, ios MVP partially shipped, Webapp V1.2 in development

View our webapp product at: https://fightpandemics.com/

Problem

The original way of "resource match-making" (Google Form) for mutual aid groups is manual and inefficient

Mutual aid-matching groups are using Google Forms to manually collect information of people who urgently need help and those with the bandwitch to offer help. And the process of finding these people are not linear. Mutual aid groups need to distribute its Google Form in a variety of channels to find individuals.

Solution

Facilitate information and resource sharing targeting context-specific needs

FightPandemic was created to facilitate connection, information exchange and resource sharing among individuals and organizations.

By building this platform, we are able to increase the matching efficiency, particularly for the mutual aid groups. By introducing a help board with tags and location filters, both organizational and individual users can quickly locate the posts to offer or request help.

Product Walkthrough

Bryana is a senior year medical student who wants to quickly learn about medical volunteering needs in her city.

Task 1: Locate requests in her city

She opens up the app and sees many request for help. She uses the filter to help her locate help in her city.

Task 2: Search for medical requests

She searches with the keyword "mask" to see requests and offers help to most urgent requests.

James is a restaurant owner who was recently laid off during pandemic. He needs some legal advice.

Task 3: Create a post with context-specific information

He creates a post, specifying he is requiring help. Since he lives in the States, he wants people with legal experience in the States to offer him legal help.

The Big Picture

Process and contributions

An asymmetrical double-diamond process in practice

The process is modified based on "Observing the Double Diamond process in practice" by Teisanu Tudor.

Unlike a traditional double-diamond, the design goal in this project was driven by many things such as the initial vision, user research, member mentality, and cost. I also collaborated in a cross-functional team in almost every step in the process.

Research

Understanding our users

I want to understand people's help-seeking and offering behaviors during the pandemic, especially when it is related to needs and challenges in terms of resource sharing and receiving on social media, so I conducted a short survey.

Survey results validated our hypothesis. But I still want to dive deeper into the challenges people face during the pandemic. Collaborated with another researcher, we conducted 8 interviews and 30+ pieces of social media audit to support the primary research.

Design Goals

We didn't jump from A from B. Together with PM, I laid out key design goals that helped us lay the groundwork of design:

Design a platform for mutual aid groups and individual users to offer or request help, so that we can reduce the entry barrier of help-seeking and -offering bebaviors, and improve match-making efficiency.

Developing the Solution

Focusing on core functionalities

Help Board

One major decision is to call out posts regarding "offering help" vs. "requesting help". We tested users' mental model in thinking about the tabs. We observed if users would click on "offer" or "request" if they are offering help.

Create a post

Me and another designer iterated on the "create a post" flow to answer one question: how might we make a multi-step posting experience easier? Finally, we were able to reduced the mandatory steps from 6 to 1 at the minimum.

Filter

The idea behind filtering is to make the match-finding process faster. The design of filters is contextualized to the current needs during the pandemics. The selection of filters is the collaboration results of the design x data collection team.

Search

Although search is a relatively standard flow, there are many decisions around different states in searching and how to present the search results.

Thinking about edge cases

As I talk with Product Managers and engineers more, I started to form a more complete mental structure when handling edge cases. I also collaborated with 2 designers to create designs for edge cases - empty state, complicated state and errors.

Design Validation

To validate our design, I created a testing prototype and collaborated with other designers to test our design.

Establishing a design system

One challenge of having multiple designers collaborating on the same flow lies in the design inconsistency. Sometimes it's just a 4px of difference in margin that causes confusion for engineers!

To tackle this problem, I worked with (and learned from) 2 another designer to established the IOS design system. This way, all designers can reuse the components in the system.

Preparing for launch

Design Handoff

At first, with the spirit of "keeping all things in one place", we used Figma to hand off the designs. But the problem is, not everyone is familiar with Figma. With the best effort in organizing the files, the design assets still seem "all over the place". This is where I pushed for a partnership from Zeplin (and got a free cooperation account) to handoff our design.

Soft launch

We also talked with four mutual aid groups during the soft launch to understand their experiences of trying our products, and gather initial feedback.

Based on the feedback, we redesigned the onboarding process to make it "short and sweet". Some text fields with regard to user profiles are also changed to reflect the working process of these mutual aid groups.

Design Decisions

Filter

Feature: Users can filter the results based on location, type of help/request, and who is offering it.

Rationale: Based on user research, there are many different levels of needs people might have during the pandemic, from food and groceries to mental health. From a business perspective, users also need to filter out posts based on who is offering if they are looking for jobs within specific organizations.

Search

Feature: Users can search information and see results in all posts, offers or requests.

Rationale:One main pain point we identified was people who need help and who can offer help cannot find each other. The search feature allows users to quickly find relevant posts that they can offer or request help.

Create a Post

Feature: Users should be able to create a post in the community and choose the visibility and duration of the post.

Rationale:Some needs have an expiration date. At an early stage, letting users decide to what extent do they want their needs to be explosed and when will their request/offers expire seems to be the most cost-effective solution.

Profile

Feature: Users are able to see their individual profile and create a new organization profile in this tab.

Rationale: Organization users are essential to our future business model. It is impotant that users can create organization to post job information and request other types of help.

Inbox

Feature: Users are able to receive notifications about their posts.

Rationale: Users need to be interacting with people who are offering or requesting help to satify their needs.

Reflections

What could have I done better?

Use user research to answer foundational questions

Because of time constraints and the fact that we were (too) excited to start something new, some foundational questions were left unanswered -

I think these foundational questions are essential to the sustainability of the business. If I were to do the project again, I would use various research methods and earlier testings to answer these questions.

MVP is an experiment, not a set of product decisions

In the early phase of the projects, I had a lot of conversations with the business owner and other designers around whether XYZ features should be included in the MVP. The decisions were based on rationality, yes, but we treated the decisions as they were.

It wasn't until some decisions were proven not solid enough that I realized we should treat the MVP decisions as hypotheses for future experiments. We should actively seek out experiments to prove (or disprove) these hypotheses to even iterate on the MVP itself.

Learning and growing

Make designs as explicit and specific as possible

Design artifacts need to be visual so people can see for themselves and understand the flows. When it comes to specs, they need to be concise and specific so engineers won't be confused.

Wearing more than the designer hat

In start-up culture, I learned how it is of vital importance to wear more than one hat. For instance, I also conducted UI testing to ensure the engineers are delivering quality products according to the design.

Embrace changes

In this project, a lot of things from prioritization to organizational structure have changed. I need to be more flexible to embrace the changes in process and prioritization.