Disaster recovery operations — reporting dashboards and field coordination

Accelerating Disaster Recovery Response Through Automation

Legacy tools during active disaster response — fragmented, error-prone, and slow when every hour counted.

Disaster Recovery Operations3–4 monthsCross-functional team

Company

Problem

Legacy tools during active disaster response

Focus

Automation · Clarity

Context

Impact

The centralised dashboard allowed crew captains and project managers to assess operational health quickly — reducing the need to navigate across multiple disconnected systems.
Role-based views and structured approval workflows helped maintain data integrity while supporting collaboration between field workers and backend office teams.
Clear traceability across debris collection, quality, and variance workflows improved confidence during reviews and audits.
Standardised inputs and structured data flows through the Disposal Monitor and Time App reduced inconsistencies in operational reporting.

Overview

Hurricane season hits, and entire neighbourhoods are devastated. Homes are destroyed, trees are down, and debris is everywhere. Amidst the chaos, our client — a vital organisation on the front lines of disaster recovery — faces their biggest roadblock: legacy tools.

They have a dedicated team who works tirelessly to clear debris — sorting it, collecting it, and hauling it away. With no technological advancements, their system remained managed via legacy tools, long and prone to error and miscalculations.

Their work involved quite critical timelines and a large number of field workers and backend teams. Already being in a race against time, imagine a crew captain sifting through cumbersome tools for approvals and deployment — or a dispatcher struggling to track debris collection progress.

Our aim was to supercharge the client's response time and efficiency.

The ecosystem

Across a timeline of 4–5 months, we worked on the following solutions for the problem statements as part of the same ecosystem — four products, one disaster recovery mission.

Four products in the ecosystem

Debris Management Portal

Dashboards tracking debris categories across states via data visualisations and tabulations. Generates reports for all required metrics. Managed by crew captains, heads, and higher authority.

Desktop

Time App

Allows field workers collecting debris to log their time and shifts throughout the day.

Mobile

Case Management

Allows officials to manage fund allocations and track cases of displaced families throughout the recovery process.

Desktop

Disposal Monitor Application

Allows the entire fleet of debris disposal trucks to create entries of debris disposed and associated site details — reflecting in main portal reports.

Mobile

Problem

The messy aftermath of natural calamities

The legacy tools supporting this critical operation were the real crisis. Field workers, dispatchers, crew captains, and regional managers all depended on systems that were fragmented, inconsistent, and deeply prone to error.

There was no single source of truth. Data lived in different tools, updated at different cadences, and trusted by nobody. Approvals were delayed. Debris collection progress was invisible. Decisions that should take minutes were taking hours — in a context where hours matter enormously.

The core problem was not an absence of data. It was an absence of clarity, trust, and shared visibility across roles, tools, and locations.

Understanding the existing scenario

Knowing the who's

In actuality there were 9 different personas across our interviews. Most of their goals started becoming common while going through the interview data. At a high level, the personas can be categorised as on-field personas and backend personas.

At a higher level, most personas were looking forward to having: a streamlined platform, all the details in one place, and automation of manual processes.

Eliza Petrowsky

27y · Senior Analyst

Works with: DQS Team Leaders, Regional Data Managers, Invoice Reconciler

Motivations

Automation
Improving Productivity
Saving time · Cloud Technology

Frustrations

Legacy tools · Losing data
Poor communication

Pain points

Time-consuming. Needs reports and updates sooner than current tools allow.
Ticket and transaction data is scattered — SQL updates needed for simple corrections.

Paul Hernandez

55y · Field Supervisor

Works with: Project Manager, Operation Manager, Debris Monitor

Motivations

Automation
Improving Productivity
Saving time · Cloud Technology

Frustrations

Legacy tools · Losing data
Poor communication

Pain points

No system informing supervisors when monitor or employee is out of bounds.
Redundant ticket creation with no way to resolve errors end-to-end.

Jolene A. Warner

28y · Invoice Supervisor / Reconciler

Works with: Field Data Staff, Project Managers, Data Supervisors, Contractors

Motivations

Automation · Connected data · Saving time

Frustrations

Legacy tools · Load times · Difficulty in usage

Pain points

Using external tools to track invoices — tedious.
Data scattered across several tools. System freezes on simple tasks.

Ratandeep Basu

38y · Regional Data Manager

Works with: Regional Data Managers

Motivations

Automation · Improving Productivity
Saving time · Cloud Technology

Frustrations

Legacy tools · Losing data · Poor communication

Pain points

Setting up projects is too time-consuming compared to existing system.
Automation of several manual activities would save everyone time.

"It would be great to see the automation of several manual processes — and I would like to plan my tasks in an orderly fashion."

Information Architecture

Navigation and Discoverability

This was the portion that took far more explorations than usual. It turned out we were approaching it in the wrong manner initially. I contributed majorly on the reporting segment of this tool post this step.

We decided to break down different segments of the app to gain more clarity. Some pages and even segments seemed redundant and unnecessary through our brainstorming — which was a relief.

Below: information architecture exploration and user flows that informed navigation and discoverability.

Information architecture exploration for navigation and discoverability — Information architecture

User flows for key navigation paths — User flows

Despite having a large number of menus (even after elimination), the navigation that was finalised was kept straightforward and simple — the requirement was to keep the learning curve for users to a minimum.

This project operated within several challenges — rather than constraints — that shaped every design decision we made.

Limited access to direct end users due to operational and time constraints — we were designing for people in the field during active disaster response.
Existing backend systems and data structures that could not be changed — we designed around the data model, not the other way around.
A predefined design system that needed to be followed — visual design decisions were not ours to make freely.
Multiple user roles with different access levels and responsibilities — the same platform had to serve field workers and executives without confusion.
Mission-critical timelines — every screen needed to enable fast, confident decisions. There was no room for cognitive overhead.

[04]Key Decisions

Disaster recovery reporting dashboard — hauling costs, monitoring costs, budget by vendor, and reconciliation charts

Key decision

Finding the right visualisation for the data

Every required dataset had to be visible within minutes of opening a report — not buried behind navigation, filters, or secondary screens.

Rationale

There were different stakeholders that needed different parameters — four different reports for different purposes.

Haul Out

Debris volume/weight by site, day, type

ROW Collection

By zone and contractor

Unit Rate

Per-unit cost, crew productivity

Budget Summary

Allocation, invoicing, reconciliation

Impact

Dashboards structured so essential details are findable within minutes for quicker decisions.
Filters for major categories added to increase efficiency.

Dual-mode reporting: graph and tabular views of operational data

Key decision

Dual-mode data visualisation — tabular and graph simultaneously

Each metric needed the right chart for its data type, screen space, and the persona reading it — often as tabular and graph views on the same screen.

Rationale

Supervisors needed status at a glance; reconcilers needed exact, auditable numbers.

Impact

Same screen presented in both tabular and graph format — catering to both styles of information consumption.

Mega Menu

Ribbon

Panel

Key decision

Simplified navigation for a wide range of stakeholders

Three navigation schemas were explored — Mega Menu, Ribbon, and Panel — before landing on a pattern learnable in minutes for field workers.

Rationale

We explored three navigation schemas: Mega Menu, Ribbon, and Panel. Each represented a different tradeoff between discoverability and simplicity. Users were working on critical, time-bound tasks.

Impact

Final navigation pattern kept straightforward and simple despite the underlying complexity.
Learning curve minimised — a key client requirement for field workers who weren't power users.
Navigation exploration also identified redundant features that were eliminated before build.

Content-heavy layout and information hierarchy in reporting views

Key decision

Content-heavy layouts designed around information hierarchy, not aesthetics

Wireframes prioritised information hierarchy over visual polish — blocking layout structure before committing to detailed design.

Rationale

Most real estate was content-heavy. The question was what grabs attention first, and what hierarchy of elements guides the user to a decision. The visual design system was scalable and accessible by necessity — large number of users, mission-critical context. We blocked out spaces to envision the best layout before committing to detailed design — exploring layouts as structure, not style.

Impact

Wireframing phase was critical — identified hierarchy issues before they became design debt.
Reports section designed so every required parameter is visible upfront — no buried data.
The design system (built by a separate team) was kept accessible and scalable throughout.

Outcome

Reflection

This project involved designing within real operational and system constraints. Limited access to end users and fixed backend structures required decisions to be made based on system understanding, stakeholder input, and observed workflow patterns rather than ideal processes. The reporting segment was where I contributed most — and where I learnt the most. It was challenging to think beyond regular visualisation types, to find the most appropriate chart for every metric, and to fit them meaningfully within the limited screen real estate of a dashboard that had to surface everything upfront. What this project taught me most was the relationship between data density and decision speed. When data is scattered across tools, people don't just lose time — they lose trust. The design problem was never really the interface. It was the absence of a single source of truth that everyone could act on.

Our aim was to supercharge the client's response time and efficiency. Three years later, I think we did.