Case study
A UX/UI concept for a digital coordination tool for wildfire operations, designed so that everyone from the smoke diver at the fire front to the rescue central can work from the same situational picture and make safer, faster decisions together.
Project
Wildfires move fast and the teams fighting them are spread 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 and were developing sensors, drones and AI cameras alongside their fire blocking net. The brief was an open map-based coordination and communication system for fighting fires, and my part was to evaluate the existing software and define 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.
“What I remember is that I felt like I had no overview at all.”
Anton, firefighter, on the 2018 wildfires
“Knowing where each other are during a wildfire would be pure gold.”
Andreas, firefighter and crew leader
“The hardest part is getting everyone to understand, so that everyone is on the same page. Everyone needs the same situational picture.”
Ted, fire chief and incident commander
“Usually you try to find the fire, and then you know you are in the right place. But if you are meant to build a containment line before the fire arrives, and all you get is a direction, it can be really hard.”
Anton and Emma, experienced firefighters
“The fire service is fairly old fashioned.”
Johan, fire protection engineer
“This feels spot on. It is really good for the people higher up.”
Andreas, on the concept
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
Possible roles: Smoke Diver 1 and 2, chauffeur
Works closest to the danger, follows orders and does physically demanding work. Motivated by fighting dangers, saving people, animals and nature, and fulfilling the mission.
“What I remember is that I felt like I had no control whatsoever” — from one of the major fires in 2018.
Level 2
Possible roles: Team leader, Smoke Diving Leader, Officer
Plans ahead for the station, evaluates risks, leads the team and gives orders to field workers. Keeps contact with the team, commanders and other team leaders.
“I want to know where my team is and that they have received the right instructions”
Level 3
Possible roles: Fire engineer, Incident commander
Joins larger operations where several stations cooperate. Keeps contact with the stations and rescue central, and is responsible for the overall situational picture and risks.
“I want to personally look everyone in the eyes and make sure they know the risks”
Level 4
Possible roles: Rescue central, SOS, MSB
Monitors operations and dangers across the country, makes sure enough resources are available, gets alerted by civilians and sees that the right help is sent.
“Where should we send the helicopters?”
The persona posters were translated into English for the portfolio; the originals were used in interviews with the fire crews.
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 role-based map views for the four user levels, explored how teams and members should be organised, and tested shorter labels and clearer grouping to keep the interface readable under pressure.
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 designed a full icon library covering vehicles, teams, sectors, markers, sensors, weather, buildings and hazards, each one produced in the colour set used to separate teams and sectors on the map.
The icons were built in Figma using Iconify icons and Figma object tools, then adjusted and unified so every symbol shares the same visual weight, stroke balance and recognisable silhouette. That kept the style consistent across the whole map without the icons being hand-drawn.
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 end product kept being iterated on, both while I was on the project and after. My contribution was to build bonds with the users, understand their needs and priorities, and create things that could be put in front of them and tested. I have kept an eye on the project since, and I am happy to say that much of my work laid the groundwork for the software as it is today.
Looking back, what shaped the work most was not any single feature, but the conditions the tool had to work under.
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.
Focusing on the icons that the firefighters already use would probably have felt more natural for them. That is something we started looking into during my last period on the project.
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.
The next part of the project is to scale the solution down, design it for the different devices the crews work on, and carry on with user testing. Above all, the contact with the users needs to stay.