All Hearts

Case study of a hurricane relief app designed during Immersion Studio in the University of Washington’s MHCI+D program

Our cohort began the MHCI+D program with Immersion Studio, a fast-paced introduction to user research, prototyping, and design. Through this five day long design sprint, we worked in teams of three to address an issue using computer-supported cooperative work (CSCW). Over the course of the sprint, our team explored ways to facilitate community hurricane relief and recovery.

Team: Divya Polson, Carol Chen, Rui Song
Tasks: User research, prototyping, usability testing, design
Duration:
5 days

The prompt: Explore the ways of using technology to help people cooperate in acts of community collaboration.

We started by researching examples of computer-supported cooperative work in the wild, from Google Docs to Wikipedia. From there, we began to propose the problem spaces we found interesting and that we believed could be enhanced through community collaboration.

As a team, we discussed the recent California wildfires and the hurricanes in the southern United States. Broadly, we were interested in how communities tend to come together during disasters and we wanted to learn more about the natural disaster relief space.

Discovery

Formative research

We conducted secondary research by browsing research reports, news articles, and interviews online. In particular, we looked at case studies of Hurricane Sandy and Hurricane Katrina, and the aftermath of those disasters. Social media was also a useful source in that we could see which topics people were discussing and what concerns people had during the after effects of a hurricane. We also did some competitive analysis to see what other tools and resources existed for hurricane relief.

Research insights

  1. External organizations and government relief efforts tend to focus on immediate survival needs, so people often have difficulty finding general daily resources and services.
  2. People naturally share information on social media during natural disasters and are eager to help, but their help is often limited to their network of friends and may not be effective or accessible to those who need it.
  3. Outdated and inaccurate information leads to dangerous, unnecessary, and overall ineffective relief responses.

Based on our research and the insights we gathered, we created the following design challenge statement:

Ideation

Braiding

With our design challenge defined, we jumped right into ideation. Over the course of an hour, we sketched over 30 concepts. Some ideas were not feasible, but it was helpful to discuss why they were good or how they could potentially be adjusted.

We narrowed our design concepts down to the following three ideas:

1. Supply Share

2. Trip Planner

3. Rebuilding Community

Down-selection

Following a helpful group critique session, we regrouped as a team and rated each concept (scored 1–5) on three criteria:

  • Exciting: Is the idea novel, challenging, and compelling?
  • Relevant: Are we appropriately addressing the challenge statement we defined for ourselves? Would our target audience find this useful?
  • Achievable: How viable is this approach given our time constraints?

Through this process, we ultimately identified Concept 1 to be the most exciting, relevant, and achievable solution of the three.

Prototyping

Moving forward with the supply sharing concept, we mapped out the features we wanted to include and how we envisioned the various touch points would interact. We sketched our ideas on paper and demonstrated them to one another, discussing ways we could merge our concepts and improve them.

After a few productive sketching sessions, we created the following low-fidelity wireframes to test with:

Paper prototype testing

We tested our paper prototype with four participants by presenting them with a scenario: “Imagine your town has been hit by a hurricane, and you are in need of a flashlight.” We observed how they worked through the flow of our app and noted their reactions.

Some key takeaways from usability testing:

  • Visual cues need more clarity. Some of the iconography we used was confusing and not successfully representative of our ideas.
  • Varying interpretations of “low stock” vs. “high stock”. Not everyone has the same understanding of different levels of stock and this created some uncertainty when reporting live stock conditions at stores.
  • Need for trust between borrowers and lenders. Although disasters are the time to put one’s faith into the hands of others, some participants were skeptical of who they were borrowing from.

Our revised concept: All Hearts

A mobile app that allows members of the community to borrow and lend personal supplies and report on the real-time stock of supplies at local stores during hurricane recovery.

Benefits:

- Covering daily needs overlooked by organizations

- Direct, real-time links between needs and supplies

- Feeling connected to your neighbors

- Crowdsourcing the rebuilding of a community

Takeaways

  • Know when to move on. Especially given such time constraints, we learned that we needed to make decisions quickly and discard ideas if they simply weren’t working.
  • Don’t jump to solutions too quickly. This was especially tempting for me, as I tend to fixate on solutions far before we even get to the ideation stage. However, this tends to result in poorly thought-out solutions, and I learned the importance of staying open-minded throughout the ideation process.

Next steps

  • Conduct further user testing. Specifically, we want to test with individuals who were recently affected by a moderate to severe hurricane.
  • Continue building trust between borrowers and lenders. Although we built in some features to build trust, we want to measure how comfortable people feel borrowing and lending items from their neighbors.
  • Consider connectivity issues. Given the timeframe and scope we defined, we moved forward with the assumption that users would have access to the app. In the next iteration of our design, we want to think about how to account for poor connection.