Skip to content

Design Research and Prototyping

kirtanupa edited this page Mar 3, 2017 · 1 revision

We set out to build a simple emergency notification web tool that would meet the needs of everyday users and administrators. We started with the users first.

Design Research

User Interviews

We firmly believe in starting with the people we are building for. So, we defined two users for emergency and non-emergency notifications: notification recipients - outdoor enthusiasts, tourists, locals - and notification administrators - city or state officials.

We reached out to individuals who worked in emergency response and learned that few, if any, tools exists that allow officials to ping individuals who are nearing dangerous areas or situations.

We connected with avid outdoorsmen & women, and tourists who corroborated general concern around the inability for state and city officials to communicate dangerous scenarios. User interviews demonstrated that their current tools for finding information were complicated to use or served an alternate purpose - weather data acting as a hazard alert system - or used services that were not 100% reliable - unknown data sources, infrequent updates, faulty internet connections while in a park.

Preliminary Research

With our user interview stories in hand, we began a survey of existing solutions to determine how hazard alerts were currently being run. Sites like weather.gov aggregate multiple tools, each drawing data from a different sources and serving niche services: from general weather warning to emergency alerts and hail storms. We immediately noticed a few things:

  • Some services were for profit entities
  • Few of the services disclosed their data sources or the frequency of data updates
  • None visualized real time data for users to see
  • For real time weather data visualizations, web applications ranged from clunky to overly complex.

Initial Concept

Project Noah is a simple, intuitive, real-time map that can notify users via text message if their proximity to an emergency or nonemergency hazard becomes a concern. The tool also allows city and state officials to view hazards on an interactive map and warn users who are too close to any particular hazard via text message. The key value of Project Noah, guided by our research and user interviews were:

  • Simplicity - the applications only inputs are a users’ name, email, and cell phone number before users can view their location relative to hazards in the area
  • Reliable Data - we can use official state-supplied databases that automatically update when new data is available via our data extractor. Further, our open source architecture means anyone can see what data we have and how it’s used
  • SMS Texting - a key insight from interviews was that mobile applications and email services often failed to connect when far from a city center while text message was the most reliable form of communication
  • Mobile Integration - users often do not have a computer available when far from their home or office
  • Admin Access - city or state administrators can easily see users real-time on a map relative to hazards. They can then select a hazard and send a warning to all users nearby to preempt a dangerous situation

Prototyping

MVP

Design MVP: The first mockups were crude, clickable mockups using Balsamiq. The intention was to show a few users a clickable demo without attention or focus on design, but rather basic functionality and user flow.

Production MVP: Our first functioning prototype was delivered at the end of Sprint 1 and it followed the startup ethos of serving a basic utility and nothing more. As a Y-Combinator company, we realized the value in creating a working tool that would serve as a foundation for an advanced product. We hacked together a prototype in a few days by prioritizing the key user need: simple information, delivered quickly and reliably; and, hard coding data to bypass the build out of a data ingestions tool, this allowed users to interact and play with dummy data.

Feedback and Product Iterations Our functioning prototype quickly started evolving with input from user feedback: Version 1 Version 1 User Feedback There are no other hazards on the map, are there only one type of hazard captured? Too many tabs, makes it difficult to focus on the app “Sign up” needs to be more clear that a user would be signing up for text messages

Version 2 The design team created a new design, simpler and easier to navigate by removing tabs and adding more data (hazards). In addition, the sign-up button was removed in favor of a mandatory sign up before using the app. Version 2 User Feedback “HATE that I have to sign up first to use the app!” Labeling each hazard will make the map confusing to read Not all hazards are going to be circles, isn’t this inaccurate?

Version 3 There was a strong reaction across the board against creating a mandatory sign up before using the application - something our design team believed to be a standard request of a user. We came decided to make sign-in optional to receive the benefit of the alert text. Version 3 was our first production level deployment for our application - at the end of Sprint 1. Version 3

User Feedback “...the simplicity is nice!” Hazards are much more accurate representations of real world scenarios The aesthetic feels plain and not exciting Navigating the application is difficult without a location bar, what if I want to plan a trip? There should ultimately be a legend for a map with logos and symbols

The Final Version

The final version of the application was a production-ready deployment and available now at https://project-noah-3a7f7.firebaseapp.com/. We used the US Web Design Standards to create a friendly interface following a standard design schema. We kept the simple user input as the core feature along with real time ingested data. The location bar allows users to zoom in on their current location or view another location if they are planning a trip.

Our key value in creating Project Noah was to create a simple design that would allow users to view their location relative to a hazard, feature reliable data via real-time extracted data, allow for easy SMS texting for administrators and mobile integration. Our final version achieved our initial product specification with remarkable results.

User View - simple, intuitive navigation with a map legend and clickable hazards for detailed information. User View

Admin View - allows local, city, and state administrators to text individuals if proximity to a hazard becomes dangerous. Admin View