Motorola Alert is an application to help you connect more quickly to family and friends when feeling unsafe or when in an emergency. When you put your phone in alert mode, it sends periodic notifications with your location to the people you designate so they can act fast to get you the help you need. The app was designed to support value-tiered markets like Brazil and India where threats to personal safety and security are an every-day concern.
The features and design of the app is fairly simple and directed towards value-tiered markets like Brazil and India. There are 4 basic functions of the app. The primary function is to serve as an emergency beacon. When in an emergency, a text message with the user's current location will be periodically sent to his or her emergency contacts. In addition, while in emergency mode users can sound an alarm or make a quick call to either emergency services like 911 or to a specific person. Secondary functions include the ability to share a user's location whenever they leave or arrive from a set location like home, work, or school; the option to send a request to friends to meet at a specified location and the ability to ask family or friends to watch over them while on the go.
The genesis for the app started out from an immersion study in Brazil and India to better understand the needs and desires of consumers in emerging markets. Importantly, one of the central findings across both countries was the pervasive threat of bodily harm that people felt in their every day life. People want to feel safe and our looking for solutions to improving their well being.
My involvement in Motorola Alert came several weeks after the project had started. The engineers and product manager had already created a version of the app Once on the project, I conducted a heuristic review and identified a number of issues. The design and features needed to change to better accommodate real user needs.
I wanted to better understand the current market for safety apps and performed a competitive review to better understand what competitors were doing. The safety app we were building was for the value-focused customer like Brazil and India where data costs were very high and relatively unaffordable to the regular consumer. The idea of using a data intensive, map-based interface was immediately discarded for a simpler text-messaging based notification system.
As part of the design process, I defined a set of design goals for the app. There was several objectives but the two primary goals was to optimize the design for emerging markets and to make the app more useful than the current model for asking for help.
The design team took another look at the original proposed app and decided to update both the functionality and design of the app. We looked at physical safety as a continuum from real immediate threats to more existential threats (i.e., walking home by yourself late at night) and designed features to support those different scenarios that a user could potentially experience. We created different scenarios and imagined what features would be helpful to them in those situations. We used these scenarios as guides for defining the features of the app.
For the next step, I articulated all the possible features and functionality that would be needed to support the experiences we were targeting.
As the product design phase moved forward, I worked on identifying all the possible touch points for the app on the phone. I started defining key use cases for the app.
Eventually I created a comprehensive list of all use cases that the app needed to support.
Once we had established what set of experiences and features we wanted to target for the app, I created an initial set of low-fidelity wireframes depicting the key screens of the app.
Once we had an initial design we engaged the software engineering team to further understand the difficulty of implementing the design. We also worked closely with key stakeholders like the product management team to better understand their business needs. As new requirements and constraints were introduced, the design evolved. For example, we initially wanted to support the ability for users to communicate directly between apps regarding their location status (e.g. at home, leaving work) but realized the work effort was too difficult for the initial release. As a result, we removed the feature and updated the design to accommodate the missing feature.
Final "Out of Box" flow
As the design progressed, we continue to test and re-test the design with users using a rapid prototyping tool. The testing really helped to refine and make the app more usable to users. For example originally, we focused on minimizing the number items a user needed to setup by providing defaults but realized through testing that they ultimately wanted control over all aspects of it since this app was focused on their physical safety.