FireShield

Relevance of the Problem

While wildfires impact specific locations, the importance to address them is three-fold: land, money and people.

Fun Fact: Fire does not discriminate - even Miley Cyrus lost her house in the Woolsey Fire. Anyone in a wildfire prone area could be affected, if not prepared.

Research Method

These research methods made the most sense for our project, especially considering it was my first quarter studying online. The switch to online studying made it harder for us to perform other methods we could have done (such as diary studies, etc.). Interestingly, a large portion of our research came through our subject matter experts as you will see later. It was hard accessing people who lived in wildfire prone areas because we had no contacts in the area and finding them online was a slow process.

Key Findings

1. While fire suppression gets a lot of attention, fire prevention and preparedness need to be focused on more.

Fire suppression was where a large amount of focus was put in the industry. The problem is that suppression is reactionary and does not come from a place of being ready. This is not to say there were not efforts made in prevention or preparedness, but the innovation was not happening in these sectors.

2. With rising populations in wildland-urban interfaces and the natural importance of wildfire, communities needed to be better adapted for living in such areas.

In our research we discovered the term, "fire-adapted communities."

A fire-adapted community is “a human community consisting of informed and prepared citizens collaboratively planning and taking action to safely coexist with wildland fire.” (fireadapted.org)

This discovery become central to our design process. We knew this is where we had aim. We also discovered there are a few key elements to such communities primarily consisting of hardened homes and maintained defensible space.

A hardened home is a home made with materials that are least likely to get caught on fire. The most vulnerable part of a house was the roof.

Defensible space is defined as the buffer between your house and a forest fire. In total, it covers three zones of a total of 100ft. Different precaution must be taken in each zone.

3. Although we are not quite there yet, living in a ‘fire-resistant’ home can be safer than evacuating in many cases.

Based on Jack Cohen's research, it is possible to design a house that is safe to stay in during a forest fire instead of evacuating and getting caught due to traffic otherwise. We knew, as a group, this theory was far reaching but a direction we should move towards.

4. People are not always encouraged to act early, at least until they were either affected by a fire or had a close call with one.

Optimism bias is a big part of this. People don't believe it can happen to them until it does.

Affinitization

Through our research, we landed at 526 data points which we were subsequently able to group into 10 groups (including a few outliers):

1. Communication (Responders and Agencies)
2. Evacuation
3. Ignition Causes
4. Prescribed Fires
5. Technology
6. Fire Suppression
7. Fire Prevention
8. Data
9. Wildfire Preparedness
10. Increasing Fire Threat

These groups helped us understand the areas we could focus on and what we knew for each area. The highlighted sections are the ones we decided to focus on.

How Might We

Target Users

Persona 1

Persona 2

Competitor Analysis

Our competitor analysis revealed where opportunity existed in our problem space. As a team, we were definitely interested in ZoneHaven as a company; so much so that we actually had an interview with the company's CEO discussing some of his thoughts on the topic. However, we knew that ZoneHaven wasn't not necessarily focused on preparedness in the same way we wanted to be. Outside of focusing on preparedness, another big focus for us was scalability. We knew our product had to be scalable to be effective in the long term.

Our Concepts

Through a series of ideation, we landed at two concepts: FireLock and FireCommune.

After feedback from our professor and further discussion, we decided to move forward with the first concept mixed with some of the community features of the second.

This amalgamation would come to be FireShield, final concept we would move forward with.

FireShield is an integrated smart home system that enables the house’s defensible to be visually mapped and simulated on to create a home that is ready (at least in theory) for shelter-in-place.

Fleshing Out The Concept

With a concept solidified, we created storyboards to explain what our concept would look like in action. This helped us understand how the system would work and poke any holes in the concept we had.

While this explained our core functionality, we looked at what a full complete solution with all necessary features would look like. This prompted us to list out all the features we wanted to focus on.

Card-Sorting

We conducted some card-sorting to figure out how to most effectively group our features within the app. We decided to do closed card sorting (where the groups are predefined) because we knew roughly how the groups would work. In total, we card sorted with 21 people.

Through this exercise, we discovered three things:

1. Some of our labeling vocabulary was too confusing for the average person.

We changed official vocabulary such structure ignition potential to clearer terms such as Fire Threat Level.

2. Our groups can be nested within each other because they have a good amount of overlap.

3. At times, there was confusion in the difference between lockdown, simulation and forecast.

Our solution was to properly train the user in the differences during onboarding because these words were perhaps as simple as it could get.

Prototyping

Sitemap/Blueprint

While the sitemap above does not cover every page of the app, this high level look into how the app would be structured was directly influenced by our card sorting and enabled us to understand how our app would be structured. The sitemap showed us that we had a narrow but relatively deep hierarchical structure while the organization scheme was task-based and topical.

Development of the Wireframe

Within the app, we knew there were a lot of different tasks the user could perform within the app. To develop effective wireframes for these tasks, we created a task analysis for each of our major tasks and then prototyped directly based off of that. An example of the transition from task analysis to wireframes is shown below (the example uses mid-fi wireframes).

User Testing/Solution Evaluation

The development of our prototype above fails to show some of the iteration we did on our design through user testing and other evaluations. To conduct our user testing, we used the user testing software, Maze, particularly because we had to do the testing remotely. Not only did the tool make the online environment easy to understand, but we were able to gain other metrics too. These testers were home owners, but not all of them lived in wildfire-prone areas (due to our limited access to such an audience). Similar to users, we tested our prototype with two of the experts that had previously helped us.

In two rounds at different stages of prototype fidelity, both the users and experts were taken through a total of seven tasks on the app:

1. Basic Login
2. Running a simulation
3. Running a test lockdown
4. Adding a item to the home inventory
5. Browsing and filtering community members
6. Checking community leaderboard and contacting community members
7. Checking the fire forecast

Our user testing showed us many of the areas our app was falling short. A few could have ended up being more problematic than just a bad experience too. The example above shows how we were using a percentage rating system to describe the level of safety one's house had. This could be problematic because while a 95% rating still has a 5% chance to burn, it could become a liability for us as a company. Furthermore, percents did not assign clear meaning.

Is there a tangible difference between 74% and 75%?

The new system used color and words to more generally describe the safety of one's house.

In addition to the observations we made while user testing, each participant completed a USE survey so that we get a quantitative understand of where we stood. We were also able to evaluate whether or not we were making good changes by comparing the results of the two rounds.

FireShield was the first UX project that I worked on after the COVID-19 pandemic started. This experience was unique on so many fronts. Everything from team communication to research was moved online with a team spread across geographic boundaries in different time zones. Here are a few things I learned from this experience:

1. Although not a replacement for users, experts can provide very valuable insight when its hard to get in contact with users.

It was incredibly hard to get in contact with our users. Not only were we separated geographically, we, as designers, did not know anyone ourselves who lived in places prone to wildfires. To fill in those gaps, we reached out to over 25 experts all across the world (including Australia) out of which we talked to 11. These experts were able to provide so much insight into a topic we knew very little about. These experts were also able to provide us the perspective of our users because they were all homeowners in areas prone to wildfires. So while we were not able to talk to as many users as we would have liked, the knowledge of these experts proved pivotal to our design process.

2. Start expensive, then scale down

As a team, we knew our solution was not the most affordable system for all users. LiDAR sensors don't come cheap but we knew that this was just the start. We designed our solution to be a proof of concept, showing the possibilities of such a system. Similar to how Tesla started with the Roadster and scaled down over time to the most affordable model yet, the Model 3, we planned for our solution to be a starting point in creating fire-adapted commuities. We knew this would not happen over night, but we hoped one day there could be a world where humans finally defeated fire.

3. Online team management is a whole new beast.

As the project lead for FireShield, I knew I had some additional responsibility. Managing a team online is not easy and online meetings are also not as engaging as those in person. One team member was also living in a time zone 12 hours ahead of the rest of the team. As the project lead, I had to navigate these difficulties whether it was finding the best meeting times or assigning tasks. In the end, I know there was room for improvement, but with the support of my great team, we ended up doing pretty great.

TL;DR: Here are some of the key lessons/reflection points I took away from this project:

• Experts can provide very valuable insight when its hard to get in contact with users.
• Our solution didn't need to be perfect for all our users at once. We had a relatively expensive solution which we planned to scale down over time.
• Managing a team online and across time zones is difficult but with careful planning is possible.