Firestop App | 2014

How might we make the info-gathering process for firefighters more usable and effective?

Damage payouts from insurance could be reduced by 25% if firefighters arrived to a fire 90 seconds earlier. Their response time depends on a complex system of information transfer, some of which is still based on a paper filing system. Moving all of that information into one accessible place would potentially reduce response time enough to reduce fire damage.

Firestop App was a student-led startup seeking seed funds to do just that. I was brought on to design the beta release of the app to test with several fire departments in the U.S. and was the first designer to work with the app.

It was also one of my first design projects and I keep it in here to show how far I’ve come.


2 months


1 product design (hi there), 2 engineers


Research and planning

The Problem

Responders in firetrucks do not have easy access to the information they need because of:

  • Disparate, incomplete or analog sources of information at crucial moments

  • Inaccurate, slow-to-respond resources

  • Lack of comprehensive access to databases and performance metrics

Before Firestop, responders had been using something like the industry-standard software shown here. The enterprise software and specialty hardware that comes with it could cost the department tens of thousands of dollars and, as of 2014, hadn’t been significantly updated in a decade.

The idea behind Firestop was to serve the firefighters in the truck responding to a crisis with better, more accessible information that was much easier to parse.

In addition, Firestop wanted to give incident command the tools to manage resources and track progress during a crisis. Afterward, we wanted to provide the tools to analyze data from crises to learn from them in a way that wasn’t possible with the leading systems at the time.


Mapping roles

Of the many individuals involved in fire safety, the team wanted to focus on communication and planning for incident command and responders. I used interview data from firefighters and the expertise of our volunteer firefighter/CEO to understand how information flowed between roles and who was responsible for what.


Affinity diagramming

Based on raw interview data from 80 people in various roles in crisis response, I came up with a list and prioritization of needs for our two key roles: responders and incident command.


Workflow analysis

I did some explorations of workflows that responders and incident command would need based on what we found from our research. The idea was to find places where their workflows overlapped and streamline those interactions, and also to make all necessary workflows require as little input as possible.


Turning it into UI

Sketching and wireframing

The interface needed to provide:

  • For responders

    • Resource tracking: seeing that they’ve been assigned, who else is responding, and how far away they are

    • Directions

    • Background of the crisis: building type, history of fires, an image of the façade, nearby fire hydrants, utilities, etc.

    • Updates from dispatch

    • When the crisis is resolved

  • For incident command

    • Timeline tracking, as every second counts — a house fire can double in size every minute

    • Resource tracking: seeing who is available, where they are, and assigning trucks

    • Updates from dispatch

    • When the crisis is resolved


I paid special attention to the areas where incident command and responders would need to communicate, because it had to accommodate a transfer of information.

Building an intuitive information hierarchy was complicated because of the quantity of information and the need to see the right thing at the right time. I solved this by using layer overlays that could be turned on and off for related sets of information and tabs for entirely different workflows.


Usability testing

When I thought I had something useful, I made some paper prototypes and had very kind members of the New York Fire Department come in to give some feedback. I created a series of tasks for both the responder and incident commander role.



I learned that firefighters try to avoid using the radio when possible in case something urgent changes about the situation and the dispatcher needs to get in touch. Streamlining communication to not clog the radios was very important.

Based on how people were using the prototype, I realized something very obvious: people hold iPads and tap with their thumbs like phones. Early explorations had the navigation on the bottom of the iPad, but I moved it to the side to better accommodate how people were holding the hardware.




I designed the Beta version of Firestop App for some experimental partnerships with fire departments in Philadelphia, Princeton, NJ, and San Diego. Responders felt it was a good improvement on the industry-standard software.

However, due to Firestop’s failure to secure a seed round of funding and all of our decisions to go on to grad school instead, the product is now defunct. I hope that will change in the future, because enterprise software in this area has amazing potential to fundamentally change this industry.

Things I would do differently

If I could do this again, I’d focus on each core workflow and test and build out improvements until it was exactly what was needed for the size of the department we were focusing on. It’s hard to tell what precisely is helpful and what isn’t working when there are too many big changes or new features. I’d pick a problem, whether reducing radio traffic or digitizing public records, and start there.

Also, looking at the visual design of this today makes me laugh. I would take the time to build a real visual identity and hierarchy system that pulled the navigation and controls into the background and made the information the focus.