Context
Over 2 days, we were tasked to design and build a crowdsourcing tool for citizens to contribute to early detection, verification, tracking, visualization, and notification of wildfires.
Problem Space
High risk users
We chose to focus on people living in country because these areas are often underserved, prone to large bushfires and evacuation scenarios are often life or death.
Fires are tricky
Bushfires and wildfires are often unpredictable, fast moving and poorly understood. People underestimate how long a fire takes to reach them and once it does, it is difficult to tell which direction it's spreading in. This is life threatening and has lead to people's deaths.
People don't make good decisions in crises
Bushfires don't just threaten lives, they threaten the property and sense of history that is attached to houses and belongings. Although illogical, people often make the decision to stay put rather than leave for safety. As such, the solution needed a way to work around this bias, but not subvert control from users.
The Human Story
There is a real human cost to the problem space explained above. One story that anchored our project was that of farmer Kym 'Freddy' Curnow. This local news article about Freddy articulates how '[He] was meant to be leaving the area with a neighbour when he spotted vehicles travelling in the wrong direction — towards the fire'. Freddy died as a result of trying to help others who were victims to the difficulty and danger of bushfires.
What I did
I designed rough mocks of a responsive web experience providing:
- Early detection of wildfires (location and movement)
- A way for users to contribute to fire detection through crowdsourcing
- Simple onboarding for users to start receiving alerts
Our Goal
Empower people to make informed decisions in a fire by providing fire direction and intensity information backed by social proof.
Design Rationale
Experience Flow
The most important to answer for users was "is there a fire?". The flow then had to cater for users providing feedback to the system.
Mobile First
A mobile-responsive website would provide the most value to users because it provides a low barrier to entry when time is a valuable but scarce resource in reacting to a nearby fire. We focused on the responsive view due to time constraints.
Accessible
Focusing on responsive web was also an intentional inclusive design decision to cater for users living in remote areas (e.g. non-suburban areas) where fires are more common. Notifications would be served using a text delivery service. We believed that a stand-alone mobile app would've hindered adoption.
People are often unprepared for fast moving bushfires. An easy to remember, quick to access, mobile optimised website would provide the most value to users who have only a few minutes to act.
Multiple Data Sources
To allow users to make informed decisions, the result screens combine satellite data, user reported data and wind direction:
- The NASA API satellite data (the red squres) only provides a rough guide to the fire's location and size
- Adding visual anchors (the red dots) that indicate users who have seen the fire provides other users with an aid in estimating where the fire is and how serious it is
- Adding wind direction allows users to make an informed decision about which direction to flee the fire
We came third!
We didn't see that one coming...
Regrets and Learnings
Better Visual Design
This was my first time using Adobe XD our team were pressured with the time restritions of the hackathon. I felt I could've given more thought to finessing the visual design. Looking back, the aesthetics aren't a reflection of my skill or craft.
Sketch First
In hindsight, sketching ideas on paper would've meant more time to help with the front end dev. Meaning we would have been able to demo more features. This was also our first hackathon as a team, so we were still teasing out efficient ways of working.