RESPONSIVE 911

Improving EMS response time
sign upLearn more

OUR GOAL

 

Intuitively get help where you need it

Update user’s locations continuously after calling 911, and allows users to verify and send a custom location.

Integrated into the Os

Designed to be unobtrusive and allow users to call 911 as usual and have information at hand if needed.

Get help without talking

Text the 911 dispatcher to receive help in an emergency situation where talking is not possible.

"Improved location accuracy, which results in reducing wireless E911 response time by one minute, can result in saving over 10,000 lives annually."

Federal Communications Commission

Interactive Prototype

 

SERVICES one

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique.Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius.

Learn more

SERVICES two

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique.Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius.

Learn more

User Research

interviews & competitive analysis

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.

Personas

Bringing Empathy for the user into the PROJECT

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.

Scenarios

Refining key path SCENARIOS

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.

View Documents

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

Initial brainstorming
Individual ideation
Initial Mockups

StoryBoards

identifying key path and context scenarios

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

Sitemap

illustrating information architecture

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.

Paper Prototype

low fidelity user testing

Using our design sketches as the backbone, we made a paper prototype of our app, with the key screens being the map, the updates, and the profile.

Then, each team member conducted usability tests of our paper prototype with one participant. The four participants ranged in age from early 20s to early 40s and had various levels of experience calling 911. The usability test began by narrating our persona’s (Kingsley’s) scenario as if they were the persona. Then, we asked the participants to perform the following key tasks:

  • Sending their location
  • Filling out the emergency form (descriptions of the situation)
  • Sending updates about the emergency situation to the dispatcher
  • Filling out the profile information

Regarding the testing platform, two group members used the paper copy of the prototype, while the other two group members used a mobile-based, interactive paper prototype (Prottapp). This allowed us to receive valuable feedback related to both the content and the usability of the app. In addition, the mobile version pointed out usability issues that may arise when viewing dense information on a smaller screen.

Quick evaluation findings

reflecting on usability testing

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.

Annotated Wireframes

purpose and functionality of the system

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.)

High-fidelity Mockups

Bringing it all together

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.

Contact

get in touch
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form
The team

Torin Blankensmith

Eric Eckert

Tiffany Lan

Anastasia Erofeeva