Smart Home System

A LiDAR-based smart home system designed to help protect communities prone to wildfires


FireShield is an integrated smart home system that uses sensors to visually map one’s defensible space allowing the user to see wildfire vulnerabilities on their property. The system consists of LiDAR sensors meant to be placed around the exterior of your property and a mobile app that creates a digital twin of the user’s home. This product is built on Jack Cohen’s research that states a fire-ready house can in cases be safer than evacuating in the case of a wildfire. Although this exact vision may be a little future-forward, the real goal is to create fire-adapted communities.


  • Project Lead
  • Content Strategist
  • Interaction Designer


  • Figma
  • Maze
  • Adobe Creative Cloud

Project Gallery

Vision Video




  • Discovery
  • Define
  • Develop
  • Deliver
  • Reflection


Problem Area

Although natural disasters get a lot of attention, there is a lack of modern technology used in these sectors . The absence of technology leaves room for quite a bit of uncertainty and error which is why we thought it might be a little interesting to look into these misfortunes though the lens of digital twin technology.

Relevance of the Problem

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


An average of 72,400 wildfires cleared an average of 7 million acres of U.S. land each year since 2000.


The Insurance Information Institute estimates that insured losses from the Camp Fire totaled between $8.5 billion and $10.5 billion when the fires occured.


According to Verisk’s 2019 Wildfire Risk Analysis 4.5 million US homes were identified at high or extreme risk of wildfire, with more than 2 million in California alone.

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

1. Secondary Research

Various new articles, governmental websites, and academic papers

2. SME Interviews

7 Subject Matter Experts

3. User Surveys

18 Respondents

4. User Interviews

3 User Interviews

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.” (

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.



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

Primary HMW

How might we create fire-adaptive communities as people continue to move into wildfire-prone areas?

Secondary HMWs

How might we encourage people to act early?

How might we help residents lower their structure ignition potential?

Target Users

  • aged 30-50
  • home and property owners
  • financially strong (the first version would be relatively costly)
  • live in fire-prone areas such as California

Persona 1

Click for fullscreen view
Click for fullscreen view

Persona 2

Click for fullscreen view
Click for fullscreen view

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.
A very early look at what we thought FireShield would be like.

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.

Click for fullscreen view
Click for fullscreen view

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.


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.



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

Evolution of the homepage prototype from drawn lo-fi to digital mid-fi

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
An example of a change we made as a result of user testing

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.


After research into LiDAR technology, we chose to power our sensors using the Velabit LiDAR sensor by Velodyne due to many reasons including their compact size and relatively cheap cost. However, the most important part was that there was an onboard data processing unit which was important to keep our sensor size small.


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.
  • Discovery
  • Define
  • Develop
  • Deliver
  • Reflection