Emergency Services (Revised)

Context

Our client was a government emergency services agency responsible for tracking and publishing real-time hazard alerts across a region.

‍

My role included:

Workshopping with clients/stakeholders to gather requirements
Design highly complex workflows for various different events
Work within an agile team on tight time-frames (6 weeks) to prepare for bushfire season.
Rapidly prototype to create high-fidelity wireframes to hand off to developers

‍

Background

A change to the way Australian's receive emergency messaging was introduced

The Australian Warning System (AWS) is a national effort to standardise the approach to information and warnings during emergencies like bushfire, flood, storm, extreme heat and severe weather events.

There are different alert levels - Advice, Watch and Act, Emergency. All of them come with their own messaging which can be applied to a wide variety of hazards.

Brief

Create an internal tool for managing and publishing warnings with a consistent UX across all scenarios.

‍

Make sure all warnings could be easily updated and amended

Publish warnings and warning areas that align to the AWS messaging

Create a design for rapidly evolving situations with limited information.

Challenges

The initial brief did not entail the full complexities of the scope

I was brought on board as a designer for a short one-week stint. However, as the project progressed, I found myself delving deeper into the complex requirements and processes outlined by the clients, which extended my role to a six-week engagement.

‍

Stakeholder management

This was an internal product which meant the clients were also the users.

My strategy for navigating this:

Co-creation is key! Getting everyone involved meant increased advocacy for solutions.
If a decision was disputed, exercise caution on communicating how urgently it is needed.
Having a visual representation of the processes help validate design discussions

Information architecture

Designing the workflows and logic

As the product designer, my first step was to condense all these requirements into concrete diagrams. This usually helps not only visualise the information architecture but also a great way to gain consensus of requirements with stakeholders.

‍

There were 3 main workflows for which processes had to be designed for:

‍

AWS Event: These are hazards standardised under the Australian Warning System. These usually have warning areas associated with them.

‍

‍

AWS (no CAD): Includes a non-standard hazard but needs warning area. This helps encompasses novel hazards or area-wide hazards.

‍

General Hazard: This category includes most everyday hazards such as car-crashes or ambulance responses. Important to note that most AWS events start as a general hazard and have to be upgraded to an AWS incident.

Designing the solution

Initial concepts and guiding principles

‍

LEADING DESIGN PRINCIPLES

Be able to navigate quickly and efficiently in emergency situations

Manage events easily by creating a condensed information architecture

Keeping elements and components consistent for faster development

Final screens

Home page

‍

‍

Manage Incidents

‍

‍

‍

Create a warning area

‍

Reflections

We achieved all of the requirements in a condensed time-frame, although I would have liked to extend beyond what we were tasked to do

Further steps

Redesign and optimise the public facing aspect
Conduct usability testing or run A/B tests to determine most efficient processes
Explore widening the IA and incorporating useful metrics in the homepage

Emergency services publication