Case study
A coordination tool for wildfire operations, built so that everyone from the smoke diver at the fire front to the rescue central works from the same situational picture.
Project
Wildfires move fast and the people fighting them are spread out over large areas with poor coverage. The recurring problem is not a lack of effort, it is that nobody has the same picture of what is happening: where the fire is, where the teams are and what resources exist.
INCA (International Carbide Technology) has worked with fire protection for over 30 years, with products built to predict, prevent and protect. Alongside their fire blocking net they were developing sensors, drones and AI cameras, and wanted a digital system to tie all of it together and actually help out during a wildfire.
The brief was open: a map based coordination and communication system for fighting fires. INCA WFS places operations, sectors, vehicles, sensors and teams as objects on a shared map, and what you see and can edit depends on your level in the organisation. My part was to evaluate the existing software and to define and prioritise the functions it needed.
Phase 01
The users are the people who actually fight fires: firefighters and rescue services, both in planning roles and out in the field, with forest owners as a secondary group. To understand their work, and to judge what the existing software could already do, I combined four ways of gathering information.
Five firefighters in different roles — fire chief, fire engineer, smoke diver and two commanders — both remotely and on site, including a visit to Johannes fire station. Separate interview guides for field workers and leaders, paired with a demo of the current software. The feedback was overwhelmingly positive, and the later visits confirmed what we had already found.
Heavy at the start to learn the domain, then running quietly through the whole project as new questions appeared.
The existing software evaluated against Nielsen's ten heuristics, on both mobile and desktop, to find where it broke down under pressure.
Field tests and feedback documents that INCA had already collected, used as a starting point instead of asking the users the same questions twice.
Phase 02
The organisation around a wildfire is layered, and each layer sees the fire from a different distance. We built one persona per level, with their traits, motivations, difficulties and needs, and used them to decide what each view in the tool should show.
Level 1
Smoke divers and drivers working closest to the fire. Physically demanding work where they follow orders, and struggle to pass on a proper picture of the situation with only a radio.
“What I remember is the feeling of not having any grip on the main task” — from one of the large fires in 2018.
Level 2
Leads a team in the field, hands out orders and keeps contact with commanders and other team leaders. Hard to keep an updated picture through speech alone.
“I want to know where my team is and that they got the right instructions”
Level 3
Joins larger operations where several stations cooperate. Responsible for the overall picture, the risks and for getting the right information to the right people, fast.
“I want to personally look everyone in the eyes and make sure they know the risks”
Level 4
Rescue central, SOS and MSB. Follows operations across the country, gets alerted by civilians and decides where personnel and resources should be sent.
“Where should we send the helicopters?”
The personas were written in Swedish so the fire crews could read and correct them themselves.
Turning everything we had heard into something buildable took a few steps, most of them together with the rest of the INCA team.
A workshop with the INCA team where we sorted, grouped and prioritised everything gathered so far. The point was to get everyone involved, not just the designers, so the priorities were shared from the start.
Long sessions of mapping and arguing about how the pieces fit together, at kitchen tables as much as in meeting rooms.
Built from the four behaviour types: each need traced to the functions that answer it, so every feature had a reason to exist.
All functions written down as stories in Jira, then mapped and sorted to decide what belonged in the MVP and what could wait.
What it means
The system is built for the rescue services rather than forest owners, and for every kind of operation, not only wildfires.
Why
The needs of the two groups barely overlapped, feedback said the tool would be useful far beyond forest fires, and there simply are not enough wildfires in Sweden to build for that alone.
What it means
Content and functionality divided across four user levels: Front Force, Team Leader, Operation Coordinator and Overseer.
Why
Nobody needs everything. Giving each role only what is relevant keeps the tool fast to read and use in a stressful situation.
What it means
A simple indicator with three states: arrow up (getting worse), straight arrow (unchanged) and arrow down (improving).
Why
The fire services already think in trends, and it gives an instant read on every operation, sector and team.
What it means
Colour coded icons, a dedicated fire icon and danger zones that can be drawn out, with notifications sent to anyone entering the zone.
Why
Gives a quick overview, builds a shared understanding of the situation and directly improves safety in the field.
What it means
Roles and teams are easy to change, and a team leader can reassign members or add vehicles in advance.
Why
The fire services reshuffle roles and teams constantly. The system adapts to their workflow instead of forcing them to change it.
What it means
Photos can be taken and sent in the chat, and pinned onto the map where they were captured.
Why
Faster than typing, and a photo gives a realistic picture of the situation that words rarely manage.
Phase 03
Most of the thinking happened on paper. I sketched the map view, the object list and the add and edit flows, then annotated screenshots of the existing app to show exactly what should change and why.
Phase 04
A map full of objects only works if you can read it at a glance, with gloves on, in daylight or in smoke. I built a full icon library covering vehicles, teams, sectors, markers, sensors, weather, buildings and hazards, each one drawn in a single style and produced in the colour set used to separate teams and sectors on the map.
Phase 05
The whole system is built around a live map, but nobody needs all of it at once. Each role gets its own default view with the information that matters to them, and can dig into more detail when they want to. Below are the three views, each with the problems it solves and how the interface answers them.
The rescue center receives the alarm, creates the operation and assigns stations and personnel. Their main view lists every active operation and station, with a trend icon that says whether a situation is getting worse, holding or improving, and a place to request more resources.
Whoever is responsible for an operation talks both upwards to the command center and downwards to the sectors. Their view holds the goal, the risks, who is in charge and which stations are involved, and lets them plan digitally by creating sectors, adding people and vehicles and placing markers.
Field users start in their own sector and can step into their team. Everything is trimmed down to what they are supposed to do right now, plus fast ways to tell everyone else what they are seeing: markers as points, lines or polygons, and photos placed straight on the map.
Outcome
The result is a coordination tool where the map is the shared truth of the operation. Every level sees the same fire, but the amount of detail and control follows their responsibility, so a smoke diver is not buried in overview data and the rescue central is not stuck in the details of one sector.
Designing for a high stress environment meant cutting anything that was not needed in the moment. Clear icons, one consistent way of handling objects and a predictable place for back and confirm did more for usability than any new feature would have.
We could have tested the interface in a real exercise earlier. Firefighters use the tool outdoors, in movement and under stress, and that is very hard to simulate sitting at a desk.
How much a domain has its own language. Learning the levels, the terminology and how an operation is actually run was the real design work, the screens followed from it.
Validate the object logic and the icon set with crews during a field exercise, and look closer at what the tool should do when the connection drops.
Things I took with me