CommunicAid

iPhone mockup of Communicaid.

Timeline: Sept - Nov 2016

Project Type: Class Project

My Role: Project Lead, UI Designer

Tools: Sketch, InVision

Skills: Problem Space Research, Usability Studies, Wireframing, Mobile UI Design, Cardboard Prototyping

Context

Designing for disasters

Over the course of 10 weeks, I was tasked to come up with a problem space related to "disasters" where my partner and I designed and built a digital and physical prototype of our solution.

Problem Space

Communication during earthquakes

During earthquakes, cell towers always see a spike in usage from people trying to contact first responders and loved ones. Most of the times, cell towers become overwhelmed and rendered useless, at a time when they are needed the most. Because of this, people aren't able to get emergency medical attention and they're no able to contact loved ones as well. Everyone loses.

Research

The "Mesh Effect"

After researching and fully understanding this problem, we came up with a solution that would act as a secondary form of communication during disasters that would help relieve stress off of cell towers. This solution would consist of "beacons" that are pre-placed around a certain area that create a "mesh system" of beacons that anyone could connect to. By relaying data across multiple nearby beacons, anyone connected to a mesh system would be able to contact anyone else in the same system.

Figure 1: This diagram shows the connection between beacons and people.

Figure 1: This diagram shows the connection between beacons and people.

Figure 2: This diagram shows the connection between beacons and other beacons nearby. (Image courtesy of GoTenna.)

Figure 2: This diagram shows the connection between beacons and other beacons nearby. (Image courtesy of GoTenna.)

Physical Prototyping

The beacon

The beacons are the backbone of this entire project. Each beacon would be placed in local fire stations and manned by trained emergency personnel. With a beacon to beacon range of up to 2 miles and a person to beacon range of 1 mile, these are the specs for each beacon:

  • UHF Radio for beacon to beacon connection.
  • Directional WiFi Antenna to connect beacon to person.
  • Rechargeable Lithium Ion Battery to power the beacon for up to three days without any external power source.
We constructed a cardboard prototype of the beacons.

We constructed a cardboard prototype of the beacons.

After 3 versions and multiple rounds of usability testing, we found that the most work was needed changing the beacon screen to make error messages more clear. We made sure to optimize the design of it to be as easy to use as possible.

Version 1 of our beacon cardboard prototype.

Version 1 of our beacon cardboard prototype.

The final version of our beacon cardboard prototype.

The final version of our beacon cardboard prototype.

Digital Prototyping

The mobile app

The final piece of this system is the mobile app. With its intuitive and familiar user interface, my mobile app was created to be as straight forward as possible. No learning curve, just open it and use it. Through this app, you would be able to call or text your loved ones. The mobile app uses your contacts list to search for people with the same numbers as a your contacts so that you don't have to remember any phone numbers. Our app also shows you what beacon you're connected to as well as other nearby beacons.

Version 1

The focus of this iteration of the design was to take into account the situation of our users and design according to it. I knew I wanted to go for a minimalistic design that was easy for users to pick up on because they would be in a high stress situation and they shouldn't have to learn a completely new UI, especially for elderly users who may not be the most tech savvy. I also made sure to keep the buttons at the bottom of the screen (versus the top) so that they were in a comfortable pressing range for one handed use.

One of the first versions of our mobile app prototype.
One of the first versions of our mobile app prototype.

Version 2

After evaluating and getting feedback on the first version, I decided to switch to following Apple's native UI because I thought what's more familiar than the UI that's built into every person's phone already? (Of course, for the Android version, it would follow the native Android UI)

One of the second versions of our mobile app prototype.
One of the second versions of our mobile app prototype.
One of the second versions of our mobile app prototype.

Final Version

After multiple rounds of usability testing, we discovered the following problems:

  • Order of "Beacon Locations" was confusing
  • "In range" arrow was misleading
  • Assumed that app would already be connected to beacon
  • Needed a Contacts page

From this feedback, we made the appropriate changes and produced these final screens:

One of the screens from the final version of our mobile app prototype.
One of the screens from the final version of our mobile app prototype.
One of the screens from the final version of our mobile app prototype.
One of the screens from the final version of our mobile app prototype.
One of the screens from the final version of our mobile app prototype.
One of the screens from the final version of our mobile app prototype.
One of the screens from the final version of our mobile app prototype.
One of the screens from the final version of our mobile app prototype.
One of the screens from the final version of our mobile app prototype.
One of the screens from the final version of our mobile app prototype.
One of the screens from the final version of our mobile app prototype.
One of the screens from the final version of our mobile app prototype.
One of the screens from the final version of our mobile app prototype.
One of the screens from the final version of our mobile app prototype.
One of the screens from the final version of our mobile app prototype.

Final Prototype

What I Learned From This Project

  • I learned that simple design isn't necessarily more usable. What actually helps increase usability is familiarity by utilizing existing design conventions. It's all about lowering the learning curve.

What I'd Do Differently

Because this project was trying to tackle such a complex and rarely occuring problem as earthquakes, it made designing for them much more difficult.

  • Getting access to representative users for our usability testing and user research was very difficult in the limited time we had. If I were to revisit this problem, I would have try to search for online forums of earthquake survivors. Perhaps then, we could at least send out some surveys and possibly talk to a few of them.
  • I would have loved to talk to some fire station officers to see if fire stations would truly be the right place to put the beacons.
  • I would try to rethink the design of the UI. There are simple designs out there that are still extremely usable.
  • The scale of this solution is obviously too large for a class context but I would try to revisit this problem space to come up with a more feasible and targeted solution given the knowledge I have of this problem now.

Thanks for scrolling!