Research journal
We will update this section throughout the project with our key findings.
- Most users (55%) prefer to receive emergency notifications by SMS, and then by phone notification (39%) (from survey)
- Users are less interested in "non-emergency" alerts, but users vary in what they consider to be emergencies (from survey)
- Forest fires were identified as the top emergency most people were concerned about (from survey)
- As of November 2016 (latest data), Pew reports that 95% of Americans own a cellphone (feature phone) and that 77% of Americans own a smartphone
- As of November 2016, non-white Americans (Black and Hispanic) were more likely to own feature phones (23%) than white Americans (17%). This means SMS notifications will reach more non-white Americans.
To ensure that we're meeting our users needs, we made sure to engage with them in a variety of ways to best understand what they understood about the information we were requested to show and notify them about.
The problem statement:
The working prototype will be an application that will allow California residents to establish and manage their profile and receive emergency and non-emergency notifications via email, Short Message Service (SMS), and/or push notification based on the location and contact information provided in their profile and/or the geo-location of their cellphone if they have opted in for this service. In addition, the working prototype will provide the authorized administrative users with the ability to publish notifications and track, and analyze and visualize related data. The working prototype does not need to implement any authentication or authorization against an external directory or authentication mechanism.
We, as a team, understand this statement to mean:
- The prototype should allow users to receive alerts about emergencies and non-emergencies via SMS, Email or Phone Notification
- Users should be able to specify where they want notifications for, and how they receive them
- We should help them with location settings, possibly by using geo-location services.
- There are specialist, admin, users of the system that will manually be configuring and sending alerts, based on information from the mapping.
- Admins will want to see the alerts in context, likely on a map.
- Admins will also want to know a little more about the alerts they send, perhaps such as how many alerts have been sent, in which areas, how many alerts are "opened" etc.
We also know from this that there are two main types of user:
- California resident(s)
- State-employed administrator(s)
There may also be:
- Visitors to California
- Residents residing elsewhere seeking information on emergencies in California (for the purposes of planning travel, interest or checking on friends and family etc. during an emergency)
We had some immediate questions regarding how to prioritise the work we were going to do in a short space of time, as well as better understand the user needs of the people who would use our service.
We posted a short survey (using SurveyMonkey) and asked some questions about how people normally find out about emergencies in their area, how they'd like to be notified about them and what in fact they considered to be "emergencies". The data sets we've received for the prototype make no distinction between "emergency" and "non-emergency", so it's important that we understand what the end user would expect from these two categories. Here are some findings.
A lot of people find out about emergencies online from Social Networks, but we were surprised to see how many still read about emergencies in traditional newspapers (offline).
Almost all respondents responded that yes, they would want to be notified about emergencies in their area, and SMS was the preferred way to be notified about them (suggesting this is where we should prioritise delivery).
Download full result summary PDF
- We should prioritise SMS in the build as the first option we make available to end users.
- Users are less interested in "non-emergency" alerts, however, users will vary in what they consider to be "emergencies", so we should allow them to choose for themselves what type of information they'd like to know about.
- Forest Fires were identified as a top emergency type that people were concerned about and considered an emergency, so this would be a good first data set to work with.
This week, we looked at how the users should actually be able to get around the site and understand what their needs would be. Based on the prior weeks work, we knew that we wanted to prioritise the SMS route, since most people did not want email notifications and the SMS option would be available to more people, since it doesn't rely on having a modern smart phone (for push notifications) or mobile email software, app or access. Any cell phone can receive an SMS, making it the best option for reaching the most people in an emergency.
As soon as the UI can be clicked through from start to end, we will be testing it with real users in-person, asking them to try out the site and then asking them some questions about how they found the experience.
Questions / things we'd like to understand better:
- Does the signup flow make sense and are users able to easily follow it?
- Are we using clear language that explains what the site is for and how to use it?
- Is the information about emergencies or non-emergencies clear and understandable?
- Are users able to change their settings easily - is it obvious to them how to change or update their alert preferences, phone number or location settings
Interview notes: Discussing emergencies and how people find out about them, and how they'd prefer to know about them.
Male, 36, California-home owner:
Google, I would usually do that because there was something I had become aware of [via social media] and I wanted to know more about it.
There’s two forms of emergency alerts, stuff pushed to you or stuff you hear about because it’s environmental and you expect something might go wrong, so you want authoritative information.
I’d be looking for news stories on google and looking to see if there was a government website.
I’d like to be able to go to google news and find out about an emergency (like a flood or something), and then be able to find an option to go to a service to sign up for alerts [in future].
Maybe it should be like amber alerts, where you’re opted in to begin with then you have to opt out.
Interviewers note: Amber Alerts are a nationwide system to alert people of child abductions. It utilises the "Wireless Emergency Alert" centralised system to notify the public via cellphone, electronic traffic boards, radio and television. https://www.amberalert.gov/
Female, 60, out-of-State resident:
Usually someone posts on Facebook, I get most of my news there. I'll usually go and ask someone who lives in that area then if they're okay [if it's something bad], or check their facebook profile. I would like to know when something happens in areas that my family live in.
Discussing alert frequency:
Male, 26, California resident:
If I had to sign up to get alerts and they were sending too many, I'd probably try and block it off or ignore it. I'd rather be able to go to a place and look at what's going on than be told about them all the time. Unless it was able to be really specific about where I care about. If I got alerts, I'd want them to be about things I really, really, need to know about - not just "news" or whatever.
As there is now a working prototype available on our staging URL, served by Heroku, it's now easy for us to do some in-person user testing or remote user testing using Validately.
Generally, we found that people were able to follow the very simple sign-up flow we'd set up, however, offering multiple options for types of emergencies to sign up for turned out not to work so well.
Our users don't know why they would have to select different types of emergencies. So, to address this, we've decided to simplify the options to just show "emergencies" or "non-emergencies" as options for what types of notifications to receive. Issue 58 addresses this.
We did some quick user research to find out more about the administrative user who the prototype description says is responsible for publishing (emergency and non-emergency) notifications. Our research identified the California Governor's Office of Emergency Services which looked like a promising start.
As we researched more about the Office of Emergency Services, we discovered the California State Warning Center. This division of the Office of Emergency Services is:
staffed 24 hours a day, seven days a week. The mission of the CSWC is to be the central information hub for statewide emergency communications and notifications. The CSWC is staffed with Emergency Notification Controllers, Emergency Services Coordinators and Senior Communications Coordinators. The CSWC serves as a highly reliable and accurate “one-stop” resource for emergency management, law enforcement and key decision making personnel throughout the state.
We also found information about the volume of notifications that the State Warning Center deals with:
Last year, staff in the CSWC handled 63,000 calls and more than 50,000 actionable incoming emails. The CSWC also received reports of about 9,000 hazardous material spills, which resulted in more than 226,000 spill notifications to federal, state and local government agencies. In addition, CSWC staff made over 981,000 notifications due to weather related warnings, fires, seismic events and other potential events that could have emergency management impacts.
The description of the State Warning Center included the titles of staff. Our assumption is that "Emergency Notification Controllers" are the possible administrative users of this prototype. By looking for Emergency Notification Controller job descriptions, we were able to find the CalHR specification for Emergency Notification Controller.
This CalHR specification describes the typical tasks that this user would perform as well as information about the minimum qualifications that such users would have.
We used this research to form the basis of our administrative user persona.