Designing flight-tracking dashboards people can act on
An airline operations dashboard is not a map with moving dots. It is a working tool for people who need to notice what is changing, understand why and decide what to do in the next few minutes.
How should a flight-tracking dashboard be designed?
A flight-tracking or airline operations dashboard should be designed around the decisions its users make, not around the data the tracking feed provides. Show normal status quietly, make exceptions impossible to miss, put predicted and actual times side by side, and give each role the view that matches its job.
Live position data is now widely available, so the hard part is no longer getting aircraft onto a screen. The hard part is helping a duty manager, a station team or a customer-service lead understand, in a few seconds, which of many flights need attention and what kind of attention they need. That is an information design problem before it is a technical one.
Which decisions does an operations team actually make?
In Define & Explore we start by listing the decisions, not the data fields. For a fictional regional carrier, an operations control team might need to decide:
- whether a late inbound flight will affect the next departure of the same aircraft
- whether a gate, stand or crew change is needed
- when to inform passengers, and what to tell them
- which situations to escalate, and to whom
- what to hand over to the next shift
Each decision has a time horizon, an owner and a trigger. Watching people work, where possible, often shows that the information behind most decisions is gathered from several places at once. That is where a dashboard can help most.
What should people see first?
Status at a glance
Status at a glance means that someone can look at the dashboard and tell, without reading every row, whether things are broadly on plan and where they are not.
A few design principles help:
- Keep normal quiet. Flights operating as planned should be visible but visually calm. If everything is coloured, nothing stands out.
- Use a small, stable set of states. For example: on time, at risk, delayed, diverted, cancelled. Define each one precisely and agree the thresholds with the people who use them.
- Never rely on colour alone. Pair colour with a label, an icon or position, so the status survives poor screens, glare and colour-vision differences.
- Show when the data was last updated. In live operations, stale data presented as current is worse than no data.
Exceptions and attention states
An exception is not just a red cell. It is a request for someone to look, and the design should say why. “Delayed” tells you little; “Arrival now 40 min after plan, next departure on this aircraft at risk” tells you what is at stake.
Useful attention states usually carry:
- The reason. What changed, compared to what.
- The consequence. Which connections, aircraft rotations or resources are affected.
- The owner. Who is expected to act, and whether someone already has.
- The state of handling. New, acknowledged, in progress, resolved.
Without the last two, the same exception can be investigated by three people or by nobody. Acknowledgement and handover are as much a part of the interface as the alert itself.
How do you show predicted versus actual arrival?
Predicted times are useful precisely because they are uncertain, so the interface should show them as estimates rather than facts. Place scheduled, estimated and actual times in a consistent order, and make it visually clear which ones are confirmed.
It also helps to show how a prediction has moved. An estimate that has slipped three times in an hour suggests something different from one that has held steady. A small history of revisions, or a simple indicator of drift, gives people a sense of how far to trust the current figure.
The broader principle applies here too: a chart is not an insight. A timeline showing that a flight is late is a fact. Showing that it puts a connection at risk is what makes it actionable. Even then, the dashboard can suggest a likely cause, but it should not present a guess as a confirmed explanation.
Should a flight dashboard use a map or a list?
Both, for different questions. A map answers “where is it?” and “what is around it?”, which matters for weather, airspace and diversions. A list or timeline answers “what needs attention, and in what order?”, which is the question most operations teams ask most of the time.
In our experience the list usually deserves the primary position, with the map available alongside it or on demand, linked so that selecting a flight in one highlights it in the other. A full-screen map can look impressive on a wall display and still be slow to read.
How much customization should users have?
Enough to fit the role, not so much that every screen becomes unique. Different roles need different views:
- Operations control needs a network-wide picture and the exceptions across it.
- Station teams need the flights arriving and departing at their location, in time order.
- Customer-facing teams need status in plain language and what has been communicated.
- Managers need trends across days and weeks rather than the live minute.
We usually design a small number of role-based views first, then allow personal adjustments within them: filters, saved selections, column order, alert preferences. Shared definitions of each status should not be customizable, because a common language is what makes handovers work.
Customization is also how a dashboard keeps up. Operations change: schedules shift, new stations open, procedures are revised. In Optimize we watch which views and filters people actually use, which alerts are dismissed without action and where people still turn to a phone or a spreadsheet. Those signals lead back to Define & Explore, and the dashboard evolves with the operation it serves.
If you are planning an operational dashboard, our Insights, Reporting & Decision Support page describes how we approach this kind of work.