NSW Official Emergency App

Context

Challenge

In 2020, Australian Data and Digital Council ran a project to explore the possibility of establishing a national all hazard communication service.
This led to the start of the HazardWatch program.
The challenge was to develop a single solution providing citizens real time access to critical hazard information during emergency events.
Several major events that followed led to the Hazardwatch program becoming a priority for the NSW Goverment:

• An expert inquiry into the 2019-20 bushfire season, resulting in a set of recommendations in relation to preparedness and response
• The new Australian Warning System (AWS) had just launched
• During the project the 2022 Eastern Australian floods occurred which let us prioritise flood warnings and proved to be the first real-life test for Hazardwatch

My involvement

I worked on this project as part of an Acellerator agency called "DNA" within the Department of Customer Service (DCS).

My involvement was throughout the whole design process:
Service Design heavy in its early stages but later our compact team size required me to jump into UX/UI mode to bring ideas to life.

Approach

Our team consisted of 4 Service Designers, spread between the different work streams of the program: customer research, customer experience and agency publishing experience.

My main focus was initially on understanding the needs of citizens and designing the best experience for them. I conducted research, created current- and future states, and conducted interviews.

After we validated initial ideas I worked on the overall look and feel of the product (UX/UI) and planning its features. This included a Design System and various Prototypes.

We used our own human-centered process with time-boxed stages and tailored it to our needs.

Process

Below is the approach we roughly followed, with the aim to get to a working MVP in about 6-8 months:

Stakeholder Management

Stakeholder management was key to success on this program as it required various agencies to be aligned.

A challenge we discovered early on was that we needed to ensure our HCD approach received the dedicated time commitment from each key agency representative: BOM, RFS and SES.

In setting up time to regularly collaborate and co-design the service we had to ensure emergency staff wasn't limited in their daily work commitments, especially during the flood events in 2022.

Research

I interviewed stakeholders, tested concepts, tested prototypes and conducted many interviews with people involved in emergency situations.

Being able to talk to people with first hand experience provided us with highly valuable insights. I mapped out real-life experiences and explored where the gaps were and what role authorities could play in terms of filling these gaps.

Research was synthesised into categories and these included:

• Alerts — The timing, structure and clarity of emergency messaging
• Preparation — Do citizens understand what they need to do to be prepared?
• Response— How do we take into account different contexts, e.g. some citizens are more prone to floods than to fires
• Painpoints — What are key pain points of citizens and emergency staff?
• Post-event — What role can we play in recovery? How can we ensure we measure and learn?
• Message Continuation — Cross-channel intgeration, social media, messaging apps: how do we ensure seamless intgration and continuation of the messaging?

Eventually we arrived at 3 How Might We statements:

1. Enable citizens to act right
   How might we design for user needs so that we can empower them to make the right decisions during critical moments?
2. Data harmonisation
   How might we ensure data alignment and integration, so that a consistent and reliable data source is created and maintained for more efficient national consumption?
3. Improved governance
   How might we improve ownership, collaboration, governance, and adjudication across jurisdictions, different level of governments and agencies?

Solution

Core concept

Our hypothesis derrived from citizen research focused mostly around alerting citizens and a place where these messages would come together as a single trusted source of truth, empowering Australians to prepare and respond to any hazard.
However, on the agency side we learned the need was more centered around publishing or broadcasting platform. Here, the challenge was to reduce the time to get an emergency warning out.

Eventually we realised the service would entail an ecosystem consisting of 3 main pillars:

Citizen Experience

After the Discovery phase we started working on a prototype. During this phase my focus was on the HazardWatch site and I also looked after the UX and UI side.

Try out some of our ideas by clicking through one of our prototypes:

We learned from prototype testing with customers and then prioritised the following features:

Watchzones
Goal: to allow customers to set multiple Watchzones and receive alerts.
When we tested our first mockups it included a "Save my location" feature. However, we soon learned that people typically looked at a few different locations and not all were actually theirs: they watched for beloved others as well. This resulted in a new concept: watchzones, a well received feature that remains well used today.

Standardised alerts
Goal: To uplift the individual agency warnings to the new Australian Standard (AWS).
This provided to be a challenging task as each agency had their own system.
Warnings have different levels of severity and the levels of the agencies would not match those of the newly adopted national standard.

Clustering and highlighting affected area
Goal: combine multiple warnings of potentially different severity levels and or category into a combined view.
During the Scale phase it quickly became obvious we needed to expand the capability to showing larger amounts of data. New challenges came up: how to display overlapping watchzones? What mulple hazards within the same catchment? How do we deal with agencies that are not ready yet to adopt the AWS standard?

For each of the features above (and many others) we initially ran Discovery sprints to arrive at hypothesis on what to build. After we documented what we believed would be a good solution we built this into a prototype that we then proceeded to test with citizens who had recently been affected by a flood or fire. Depending on the results we would then either revise or push to production and learn from real-life use.

Publishing side

To enable the front-end we needed to streamline the publishing side as well.
We structured templates to create consistent, clear warning messages for different formats, ranging from SMS texts to social media messages to the actual full detail warnings on the Hazardwatch platform. The effectiveness of these messages was validated in user testing sessions.
Colleagues also improved workflows and guided emergency warning publishing staff in their new ways of working. This included the new publishing system and warning dashboards to measure performance.

Outcome

• Over a million views in the first 6 months (before the app was officially launched!)
• Secretary's Award 2023 Winner
• App is currently no.71 in iOS App store (25 Sep 2023)
• A major outcome of the program was that we managed to reduce the publishing time from 30 to 3 minutes for emergency warnings. Time is critical in emergency situations