re+connect

Our Design Process

Research

Literature Review

I’ll admit when I learned I would be working with an interdisciplinary team from Harvard and MIT, on disaster resilience and management, I felt quite daunted. My first two weeks on the project were spent immersing myself on the topic, my primary resource being re+connect founder Jasmine Qin’s 87-page thesis on community disaster resilience in Puerto Rico.

Here were some of my main takeaways:

1. The disaster resilience challenge is incredibly nuanced and complicated, having to address the varying needs and capacities of different groups. For example, when it came to using a mobile app, some of the most at-risk populations did not have technology access/literacy to be able to input their needs into an app, so volunteers they trusted would have to go visit their homes instead.

2. Perhaps even more than food and other distributed material resources, social capital —individual and community networks— have proven to be the most vital capacity for coping and adapting to shocks from disasters. One of re+connect’s mantras was: connecting people and data to boost disaster resilience.

3. re+connect’s vision for its product had 4 stages: mobilizing volunteers and community groups, assessing the situation, coordinating services and tasks, and finally reporting progress and impact.

Competitive Analysis

We were tasked with creating SWOT analysis of re+connect’s competitors in the disaster management space, addressing what features they had and why, along with what data they collected and how it was used. We also took samples of their UI/UX elements.

• Needslist: Real-time virtual marketplace for foundations and relief organizations to match needs/offers of supplies, services and funding in times of crisis and disasters

• Usahidi: open-source tool which utilizes user-generated reports to collect, manage, and map and visualize data. 

• HOT/MissingMaps: Crowdsourced geospatial data collection based on satellite images to support humanitarian response

• Crowdsource Rescue: Houston-based disaster responses non-profit that connects first responders and vetted volunteers with disaster response cases

We also looked at indirect competitors for inspiration such as:

• Trello: dashboard of boards that are in progress, can organize tasks to personal preference of workflow

• Doordash: progress bar and map of delivery

• Taskrabbit: search and selection of task categories with visual and informational cues

• Citizen: report incidents with video, photos, text. Register account with phone number, users have to at least add 1 emergency contact to proceed with account registration

Synthesis

Jobs to be Done (JTBD)

We began research synthesis by identifying the Jobs to be Done (JTBD) of the 3 key actors of re+connect: community ambassadors/residents, community groups, and agencies.

A Job to be Done describes a core task that would cause a consumer to adopt an innovation. So we asked ourselves: what would make them adopt our app?

So for example:

• A JTBD for a resident would be to access resources for themselves and loved ones.

• A JTBD for a Community Group would be to understand the needs and capacities of people they work with.

• A JTBD for an Agency would be to acquire and allocate relief goods/services quickly.

User Journeys & Use Cases

After we identified the jobs to be done, we then mapped out the major user journeys for each key actor. A user journey map is essentially a flow of how users would complete their jobs to be done in their current circumstances, without the re+connect platform. After Iterating a few times, we came up with educated assumptions of how the key actors would handle disaster management scenarios on their own.

Utilizing the user journeys, we identified the current pain points for users, which informed us of potential use cases, where our platform would be useful. We created a use case documentation to brainstorm how each user would solve their jobs to be done using re+connect’s service. This documentation included 48 total use cases across the 3 main user groups. Use cases that connected to others across the user groups were ones where the app could really make a difference.

Personas

We created personas to keep our users in mind while we designed the product.

Design

Information Architecture

Our biggest contribution to this project was our iterations to their information architecture. We iterated on

 In this project, we learned firsthand about the importance of information architecture.

We originally tried to design without fully completing and understanding the IA. But it wasn’t until we created the IA that our designs became user-centered and grounded in research.

Creating information architecture was definitely not easy - we went through more than 5 completely different iterations of IA. Here are our 3 main rounds of iterations.

After learning the key findings from the service map, we began thinking of key elements that could be used.

The feedback we got was that this one was too structural and didn’t take into account the user journeys that we identified earlier

V2 was too behavioral, more similar to a service map, didn’t communicate the structure

Design Studio & Sketching

My partner and I paired up for a design studio, in which we gave ourselves just a few minutes to come up with rudimentary designs that would end up becoming our low-fidelity wireframes. The goal in the beginning was just to get as many ideas out as possible.

Low-fidelity wireframes

We made low-fidelity wireframes of the sign-up process, the dashboard, task tab, user profiles. Here are some examples of those wireframes, along with the use cases they would address.

Component Library

To aid us in the designThis process, we adhered to a pattern library that we put together for ease of use and consistency.  library included iconography, sizing, font, spacing, and other visual elements. We factored in that most Puerto Ricans used Androids, and that iconography may be different based on regional conventions.

Testing

User Testing

We tested the final iteration of our information architecture, as well as our low-fidelity wireframes, with David J. Carrasquillo-Medrano, Manager of Planning and Community Development at the Hispanic Federation. For the information architecture he helped to both confirm and correct our assumptions. For the wireframes, he told us what he expected to see on certain web pages, and how he would interact with certain elements on the page. We would give him various scenarios/use cases expected of consumers, and he would go through them.

Main Takeaways from Testing

1. “90% of conversation between agency and community groups happen over the phone”. Managers and coordinators need to be able to “keep tabs” on agreements made during off-app conversations

2. “It’s very important to have some way to print or export data such as contacts.” Agencies find it useful to collect their data efficiently for coordination efforts, internal reports, and other initiatives

3. “There’s a difference between an informal exchange of goods and services and a grant application for $5 million dollars.” There are vastly different scales of resources and allocation. The term “request” implies there’s a guarantee to receive support.

4. Consider adding a space to allow agencies to include a prompt for community groups to answer when applying for RFPs

5. Visibility of other agencies’ RFPs and resources could help promote solidarity amongst the different groups