We interviewed 5 individuals who were involved in a 911 emergency situation and attempted to call 911. We noted important points in each of their stories and aggregated similar points to identify overarching trends. Our main findings were that all participants used a cell phone to call, half of the interviewees were in panic and were not able to articulate the situation, and a desire among interviewees to have responded to the situation either more quickly or precisely.

The research findings became embodied in our first persona, Kingsley. Kingsley has to report a medical emergency in an hard-to-locate area, but is too panicked to articulate information about the emergency to the dispatcher. From this point on, Kingsley’s goals, desires, and pain points became a model for our design process, which will be discussed in detail later. In addition, with Kingsley’s creation, we were able to simplify our key vision and goals to a mobile application that would allow users to send their location and medical information to a dispatcher with minimal effort needed on their part.

In this part of the design process, each group member individually identified possible expectations of our personas (Kingsley and Holly). These expectations were based on our research on 911 emergencies, the interviews we conducted, and our own assumptions. We clearly differentiated whether expectations were research-based or educated guesses.
Next, we individually wrote two scenarios, one for each of our personas (Kingsley and Holly). In the scenarios, we described the persona’s emergency situation and how they used our app to quickly share their location, view updates about the response process, and decrease the emergency responders’ arrival time.

With our key purpose, persona, and context in mind, we ideated some design concepts we felt would work well with our envisioned app. The final sketches included the following:
Map: identify and send the user’s exact location
Updates: visual feedback about emergency responders’ progress, advice related to the emergency, and other relevant information
Profile: input medical information to later send to the dispatcher, add emergency contacts and other relevant information

During this part of the process, each team member individually made two storyboards. One of the storyboards was hand-drawn, while the other was a photo storyboard. In these storyboards, we focused on illustrating a context scenario and a key path scenario for our app.

For my hand-drawn scenario, I focused on one of the app’s key path scenarios, the transition from calling 911 to entering our app, sending the emergency location, and filling out an emergency form (which was an early concept). My photo storyboard presented an emergency in an unidentifiable location, a problem we had been addressing at the time, and how the app works as a solution.  -Tiffany

For my hand-drawn storyboard, I focused on the key path scenario of filling out the profile with medical information, in order to be prepared in case of an emergency. In my photo storyboard, I focused on representing a context scenario in which the user was in an unknown location, and how they would use our app to quickly and easily send their location to the dispatcher. -Anastasia

For my hand-drawn scenario, I depicted a situation that highlights the usefulness of location sending when the user is in a compromising situation and unfamiliar situation. My photo storyboard shows a scenario in which the user may not be able to speak and explain his situation, which shows that automatic location sending and an emergency form or another non-audio feature would be useful -Eric

For my hand drawn storyboard I focused on highlighting the simplicity of how a user expects 911 to work with modern technology. In the photo storyboard I used higher fidelity imagery to help illustrate the narrative. -Torin

StoryBoard 1

StoryBoard 2

STORYBOARD 3

STORYBOARD 4

We took the design sketches and the key path scenarios from the storyboard to the next step by creating a sitemap of the main screens and features of our app. If we were collaborating with other designers and developers, the sitemap would be impertinent to communicating our key path flows, existing features, and our vision of the app holistically.

After the usability testing, each group member shared the feedback they received. We aggregated all the feedback, which allowed us to identify and group similar findings. Based on the feedback we received during the evaluation, we identified major and minor usability issues and together, worked out possible solutions to these problems.
For example, 3 out of 4 participants felt that the “Updates” screen was unnecessary because it was redundant and densely packed with information. They noted that this screen would be too visually overwhelming or irrelevant in an emergency situation. The “Updates” screen, did in fact contain a lot of information: updates about the emergency response process, an emergency form that the user could fill out if they wanted to, a list of contacts involved in the emergency, and options to record and backup media, such as photo, video, or audio. Based on the feedback we received, we decided to take out the “Updates” screen and instead integrate its key features into the existing “Map” screen. This allowed us to make our app more clear and concise, which we believe are important characteristics of an emergency response app, without stripping it away of useful content.

With all the basic components of our app completed, we moved on to one of the final stages of the design process-- wireframing. Based on the feedback we received during our usability testing, we modified the layout and design of our app through our wireframes. Then, we annotated and explained features of the wireframes. Annotationed wireframes were important so that, if passed to another team of designers and developers, the wireframes could stand alone and clearly demonstrate key features of the app. By the time we finished our wireframes, our key path scenario was cemented. (Kingsley and Holly would be proud.)

After completing our wireframes, we received peer feedback, which helped us create the first draft of our hi-fidelity mockups. Because we had been incorporating feedback throughout the process, the transition from wireframes to hi-fidelity mockups was pretty simple and straightforward.