Enterprise UX
Senior UX Designer
2019
Lido Flight 4D — Flight Dispatching System
An airline dispatcher is accountable for 20–40 live flights at the same time. The open question on this rebuild was never how the product should look. It was what a dispatcher should be able to hold in view at any moment, how a single flight’s data should be organised, and who gets to decide which flights matter.
I joined Nagarro’s team as Senior UX Designer on the rebuild for web. Setting up research alongside design rather than ahead of it, we resolved information architecture, layout, and dispatcher workflows to ship the production web MVP powering 25% of global commercial flights across 125+ airlines.
One product, 125+ operators, and no single right default
This is the constraint underneath almost every decision that follows. The same screens serve a low-cost carrier optimising turnaround and a long-haul operator managing codeshares, and those operations put pressure in different places. So a default that suits one operator is not neutral for the rest — it is a quiet claim about whose work counts as typical. Wherever the range was genuinely wide, the answer had to be a mechanism the dispatcher controls rather than a default we picked on their behalf.
Full-Service Carriers
Lufthansa, KLM, Air France. Long-haul complexity, codeshares, tight regulatory oversight
Low-Cost Carriers
EasyJet, Wizz Air. High frequency, thin margins, fuel and slot efficiency critical
Cargo Operators
Weight, payload, dangerous goods constraints driving every flight plan
Regional Airlines
AEGEAN, SriLankan, Malaysia Airlines. Smaller ops teams, high per-flight accountability
We were handed a modernisation brief. The problem was situational awareness.
The brief described a dated interface. What sat underneath it was a product that had never taken a position on what a dispatcher should be able to see at once. A dispatcher is accountable for 20–40 flights running simultaneously, but the legacy product could only show them one task at a time. Opening a single flight to check its weather took away the view of everything else they were responsible for, so they came back and rebuilt that picture from memory — dozens of times a shift. That is a gap in the product definition, not in the visual design, and restyling it would not have touched it.
The surrounding constraints made it harder. Every routing, fuel and weather call is auditable afterwards, so ambiguity in the interface carries real cost. The same screen serves a low-cost carrier optimising for turnaround and a long-haul operator managing codeshares, which put pressure in different places. And the users are experts with years of muscle memory on the old tool, which means a redesign can make them slower before it makes them faster. None of that is fixed by making the interface look current.
Dispatcher’s shift
20–40 flights
Managed simultaneously, not sequentially
Every decision is auditable
Regulatory + safety constraints on all changes
Time-critical exceptions
ATS plan review · weather · NOTAMs · MEL
Coordinates with 6+ roles
Pre-planner · ATC · Perf. engineer · Ground
The legacy system
25 yrs
desktop paradigm
7 separate products · no integration
modal-based · window-per-task
no user research ever conducted
Ground-up redesign as modern web app
Nagarro UX team · Surbhi Singh
What we had to design toward
6
delivery slices scoped in week one. We shipped the first.
7 → 1
separate products the shared component library was built to cover
0
usability sessions run on the product before this engagement
How might a dispatcher inspect one flight in full detail without losing awareness of the thirty-nine others they are still accountable for?
Which broke into three product questions
Each of these is a product decision before it is a design one, and each was being settled by opinion when I arrived because there was no evidence to settle it with. They are the spine of everything that follows: the research in section 05 exists to answer them, and section 09 is where each one lands.
What stays on screen while a dispatcher works inside one flight?
Everything, something, or nothing. This one decides the shape of the workspace, so it had to be settled before any other layout question was worth asking.
Should a flight’s data be organised around the system, or around the decision being made?
The legacy product exposed data roughly as the database held it. Changing that means committing to a claim about how dispatchers actually reason through a flight.
Who decides which flights matter — the product, or the dispatcher?
With 125+ operators running different operations, whatever the product surfaces by default is a position on whose work is representative.
What I owned, what I influenced, and what I didn’t decide
Senior UX Designer on a team of one other designer, 2 PMs and around a dozen engineers in India, working alongside the Lufthansa Systems product team in Gdańsk. The product had no research function when I arrived, so establishing one was part of the design job rather than a precondition for it. In practice that meant I owned how the three questions got answered — the evidence, the options and the argument — without owning the decision about what we would build first.
What I did
- Set up the research function itself: recruitment, session protocols, moderation and synthesis
- Ran 5 dispatcher interviews and observational sessions during live shifts
- Reframed the brief from visual modernisation to situational awareness, and made the case for it with evidence
- Turned findings into the information architecture for flight detail, then defended that structure when it was reopened later
- Explored competing layout models and built the InVision prototypes used to decide between them
- Ran 6 usability sessions across 3 participant groups and fed results back into each iteration
- Contributed to MVP scope planning and the six-slice split
Where it was shared
- Scope and the six-slice plan were set with Shalien Kishore and senior leads. I contributed; I did not decide.
- Stakeholder workshops were facilitated by Charlene. I was a participant.
- Wireframes and the v1 component library were built with the Gdańsk designers.
- Visual design and high-fidelity screens were delivered by the wider team.
- The programme spanned 7 products and 6 slices. I worked on Slice 1.
Research set up to settle decisions, not to produce a report
Discovery
Stakeholder workshops
MVP scope & 6-slice plan
Research
5 dispatcher interviews
Ecosystem & empathy maps
Ideation
Design Studio sessions
3 layout patterns tested
Prototype
InVision interactive flows
Wireframes to high-fidelity
Test
6 usability sessions
3 participant groups
No one had researched this product with its own users before, so there was no backlog of findings to design from. I set up the research and ran it alongside the design work rather than ahead of it — we couldn't afford to spend the first quarter learning before we produced anything. Every track below was chosen for a question it could close: the interviews and shift observation to answer Q1 and Q3, the ecosystem map to establish where the dispatcher actually sits in the decision chain, and the prototype tests to check whether our answers survived contact with the people who would live in this product.
Workshops first, to establish what we were actually building and in what order
Who was in the room
Project owners
Project managers
Requirement engineers
What we aligned on
Product architecture
Business goals
Team structure
Output
6-slice MVP plan
Slicing by dispatcher task rather than system boundary meant we could ship one slice and learn, instead of designing all of it and shipping none
Three parallel research tracks
Stakeholders described a modernization problem: the product looked dated. Dispatchers described a working problem: they kept losing their place. That gap is the whole reason this project needed research rather than a redesign — the two groups were describing different products. Running the tracks in parallel surfaced the discrepancy in the first weeks, early enough that we could design from what we watched dispatchers do rather than from either account of it.
Ecosystem Mapping
Roles around the dispatcher
Pre-planner, ATC, ground
User Interviews
5 airlines: EasyJet, Wizz Air, BA, Air France, Thomas Cook
Observational Research
Dispatchers during live shifts
Multi-monitor, real context
Six sessions, three types of participant
Access to real dispatchers was limited, so we recruited across three groups to widen what we could learn: EasyJet for high-frequency short-haul pressure, LSY for depth on the system itself, and the Lido Help Desk for day-to-day dispatching context. It still wasn't the full range of operators on the platform, which is the main caveat on everything the sessions told us.
EasyJet
Airline representatives
LSY
Business consultants
Help Desk
Lido dispatchers
All 6 sessions run remotely on InVision prototypes, two per participant group
Sprint cadence
Two-week sprints, each closing with a stakeholder review and a team retrospective.
Retrospectives
With the team split between India and Gdańsk, problems tended to surface as slow drift rather than open disagreement. Running retros every sprint was how we caught that drift while it was still cheap to reconcile.
Why it mattered
Halfway through, engineering moved the timeline and fuel management came off the plan. We had design work in flight on it. Because scope was already sliced, we could drop that slice and pick up the dashboard redesign at a sprint boundary rather than renegotiating the whole roadmap.
The flight list was not navigation. It was situational awareness.
Three observations came out of the interviews and shift observation. Individually none of them settles anything. Read together they answer Q1, and that answer is what the rest of the design followed from.
Observation 1
Parallel attention, not sequential focus
They hold 20–40 flights at once. Any layout that shows one flight at a time is working against the job.
Observation 2
Spatial memory across windows
They found things by where they sat on screen, not by reading labels. Position had to stay stable.
Observation 3
Every modal costs them the overview
Opening a flight hid the list they were monitoring. This became the thing the redesign had to solve.
Put together: the flight list was doing more work than a navigation menu. It was where a dispatcher held their picture of the shift. Anything that covered it, however briefly, made them rebuild that picture by hand. That reframing is what turned a visual modernisation brief into a structural one.
Which answers Q1: the list is not a screen you navigate away from, so the workspace has to be built around it staying. Stated that way it stops being a layout preference and becomes a product constraint — and the set of viable layouts collapses to the ones that can honour it. Every option in section 08 was judged against this, which is why the evaluation took days rather than sprints.
We tested the wrong answer to Q1 early enough that it was cheap to be wrong
Our first prototype kept the legacy mental model and gave it a modern surface: one flight at a time, opened in a modal. It was the cheapest possible version of the answer the team already assumed was correct, which is exactly what made it worth building first. It went into the first usability session and did not survive it.
Flight detail as a modalA visual refresh of the existing pattern. Cheaper to build and familiar to anyone who had used the old product.
It reproduced the original problemOpening any flight covered the list. Dispatchers lost sight of everything else they were accountable for, exactly as they had on the desktop tool.
The surface was never the problemA modern-looking modal fails for the same reason an old one does. The interaction model had to change.
Q1 was settled by evidenceThe list stopped being a screen to navigate away from and became a fixture the workspace is built around — a position we could defend later without re-running the argument.
Three ways to hold detail and overview at once
With the modal ruled out by evidence rather than opinion, the question narrowed: which structure gives a dispatcher depth on one flight and continuity across the rest? Three were viable, each buying something at a different cost. We sketched all three and argued them on paper, where changing direction is free and nobody has to defend a sunk sprint.
Three layout patterns sketched before any digital tools opened
Approach
Design Studio sessions: we sketched competing layouts by hand and argued them out on paper, where changing direction costs nothing
3 patterns evaluated
Full-screen drill-down
Inline expansion
Three-panel persistent
Selected
3-Panel layout
The only one of the three that satisfied the Q1 constraint: the flight list stays on screen while a dispatcher works inside a single flight
Three product decisions, and the alternatives we turned down
This is where Q1, Q2 and Q3 land. Each had a cheaper or simpler alternative that someone on the team was actively arguing for, and in each case the research pointed somewhere else. What each decision bought and what it cost is set out below, including the trade-off we still had not resolved when the slice closed.
Flight list, detail, and route map all on screen at once, instead of opening a flight in a modal or a full-screen view. The list stays visible no matter what a dispatcher is doing.
A dispatcher is responsible for 20–40 flights at the same time, and during observation we watched them track status by where things sat on screen rather than by reading labels. Any pattern that replaces the list with a detail view asks them to hold that picture in their head instead. Our own first prototype used a modal and failed in the first session for exactly that reason.
Shipped in the MVP and tested well across all three participant groups. It cost us list width, though: some dispatchers asked for a larger flight list, and that density trade-off was still open when Slice 1 closed.
Full-screen drill-down. Visually cleaner and simpler to build, and it was genuinely on the table. It buys screen space by taking away context, which is the thing dispatchers could least afford to lose.
Flight detail split into tabs by decision domain (FLIGHT INFO, ROUTE, NOTAMS, WEATHER, REMARKS, MEL/CDL, POSITIONS, EVENT LOG) rather than mirroring how the data is actually stored.
A single flight carries an enormous amount of unrelated data. The legacy product exposed it roughly the way the database held it, which meant dispatchers had to know the system's structure to find anything. In interviews they described their work as a sequence of questions instead: is the route fine, what's the weather doing, is anything on the aircraft deferred. The tabs follow that sequence, so an experienced dispatcher can go straight to the one they need.
Shipped as the flight detail structure in Slice 1. The part that mattered beyond the MVP is that it is extensible: a new data domain arriving in a later slice becomes a new tab rather than a renegotiation of the layout. Choosing a structure five other slices could grow into was worth more than choosing the one that fit Slice 1 most tightly.
One long scrolling page with anchors. Much easier to build. But expert users don't browse, they jump, and a scroll turns a known destination back into a search.
Dispatchers choose their own columns, with quick filter chips above the list and urgency carried in colour through a "time to react" column, so the most pressing flights surface without anyone having to go looking for them.
This was the clearest thing the interviews told us. A low-cost short-haul dispatcher and a long-haul dispatcher were watching genuinely different columns, because their operations put pressure in different places. Any single default we picked would have been wrong for most of the operator base, and with 125+ operators on the platform there was no version of "one sensible default" that survived contact with the range.
This was the strongest result in testing. Column customisation was the most positively cited feature across the six sessions. Dispatchers specifically described feeling more in control, and the filter chips were called out for making the list faster to work through.
Saved views and role-based presets. More powerful, and a fair amount more to build and maintain. What we actually observed was dispatchers setting their columns at the start of a shift and leaving them, so the lighter mechanism covered the real behaviour at a fraction of the cost. Scoping to observed behaviour rather than imaginable behaviour is what kept this slice shippable.
From one thing at a time to persistent awareness
One decision did more work than the rest of the redesign combined. It is easier to see as a sequence than as a screenshot.
- Scan the flight list
- Open one flight, list disappears
- Read what you needed
- Close it, return to the list
- Rebuild the picture from memory
- Repeat, dozens of times a shift
Every inspection cost the overview. The reconstruction step was invisible in the interface but real in the work.
- Flight list stays on the left, always
- Select a flight, detail fills the centre
- Route map holds context on the right
- Nothing covers the list
- Move to the next flight directly
Inspection and overview stop competing for the same space, so the reconstruction step disappears from the loop entirely.
The legacy tool gave a dispatcher one thing at a time. Checking the weather on a flight meant leaving the view that showed them everything else they were responsible for. In observation, that was the moment the work got harder: they were rebuilding their picture of the shift from memory every time they came back.
So the flight list stopped being a screen and became a fixture. It sits on the left permanently; selecting a flight fills the centre panel and the route map on the right, and nothing covers the list. A dispatcher can look at one flight in detail without losing sight of the other thirty-nine, which is the part the old tool never allowed and the part that had to be true before anything else we designed mattered.
The trade-off is real and worth naming: a permanent list is a narrower list. Several dispatchers in testing wanted more room for it, and we hadn't resolved that density question by the end of Slice 1.
Slice 1, in production
Flight planning and monitoring — the slice a dispatcher is inside continuously, which is why it was chosen as the MVP rather than the slice that was easiest to build. The screens below are the ones dispatchers tested and the ones that went into production, and each carries one of the three decisions above.
What shipped, what testing showed, and what I still cannot tell you
Slice 1 shipped in 2019 and went into production use. Slice 2 continued on the same research process, component library and delivery rhythm rather than starting over. The three answers were product bets, and being precise about which parts of the evidence support them — and which parts I simply don’t have — matters more to me than a headline number would.
What shipped
- Flight planning and monitoring as the MVP slice
- Persistent three-panel workspace: list, detail, route map
- Flight detail organised by decision domain across 8 tabs
- Dispatcher-controlled columns, filter chips and a time-to-react indicator
- v1 component library covering the remaining slices
What testing showed
- 6 moderated sessions across 3 participant groups
- The persistent-context approach tested well in all three groups
- Column customisation was the most positively cited feature
- Filter chips were called out for making the list faster to work
- The modal prototype failed in session one and changed the design
What remains unknown
- We shipped without analytics, so I have no production behaviour data
- No task-time, error-rate or adoption measurement at Slice 1 level
- Participants covered 3 groups, not the full operator range. Long-haul and cargo dispatchers were never tested
- The list-density trade-off was still open when Slice 1 closed
The figures below belong to the wider Lido 4D programme. They followed the redesign and the organisational move to Scrum@Scale, and I am not claiming them as outcomes of the work in this case study.
Programme-level context: not a direct outcome attributable to Slice 1
Reported across the product organization after the redesign and the move to Scrum@Scale.
Release planning accuracy across the programme once scope was predictable and teams shared a component library.
Standardized delivery cycles, replacing unpredictable shipping windows. The Lido User Group Forum, where 50 to 80 airlines benchmark operational data together, kept shaping the roadmap from here.
What the sessions sent into the next iteration
- A larger flight list view. The persistent list bought continuity at the cost of width, and that trade was not settled.
- Recalculation directly from the flight list, rather than only inside the Calculations tab.
- More granular control over notifications.
What outlasted the slice
UX research practice established
Recruitment, session protocols, running them, synthesis. It ran for the first time on Slice 1 and Slice 2 started with it already in place, which meant the next team argued from evidence rather than from opinion.
Design system at scale
A v1 component library shipped with Slice 1, built to carry the remaining slices. Two offices, one set of patterns, decided once rather than per screen.
Delivery infrastructure for Slice 2+
Slice 2 began on the same research process, component library and sprint rhythm, rather than rebuilding them.
Three things I'd change if I ran this project again
Design system before screens, not alongside them
We built the component library while designing the screens that used it, and the two kept drifting apart. Every time we settled a pattern, work already finished had to be revisited. With designers in two offices, that reconciliation cost showed up on every deliverable rather than once.
Settle the foundations, spacing, type, colour, core components, before screen work starts, even if that means a slower first sprint.
Push harder for a wider participant range from day one
Our sessions covered EasyJet, LSY and the Lido Help Desk, which is a narrow slice of an operator base in the hundreds. Long-haul and cargo dispatchers work differently and would have put far more pressure on the three-panel layout than the groups we had.
Negotiate 2 or 3 additional operator types at project scoping, before committing to any layout pattern.
Ship with analytics, not without them
We shipped clean, no instrumentation. Prototype behaviour and production behaviour diverge, especially for expert users under real pressure. Slice 2 had no production signal to start from.
Wire analytics and session recording before launch, even a lightweight setup. Interview data is good; observed production behaviour is better.
What this changed about how I work
Research is how you close a product question, not a phase before design
I arrived expecting to finish research and then start designing. There was no time for that, so the two ran together. The modal prototype failing in session one was worth more than another month of interviews, because it tested a decision instead of a hypothesis. I now build the thing early specifically so it can be wrong while being wrong is still cheap.
Expert users don't want it simpler
Looking at an interface that dense, my instinct was to strip it back. That instinct was wrong. Dispatchers work this tool every shift and would rather see more and judge for themselves than have a designer pre-decide for them, which is why customisable columns tested better than any default we could have chosen. For an expert user, density is not the problem. Unpredictability is. I stopped treating simplification as automatically good.
Designers should be in the scoping conversation
I used to treat scope as something handed to design. The six-slice split came out of week-one planning with Shalien Kishore and the senior leads, where I contributed rather than decided. But the shape of those slices determined whether there was a coherent experience to design at all. Had they been drawn around system boundaries instead of dispatcher tasks, no amount of craft downstream would have fixed it. I push to be in that conversation now.
Write the reasoning down, not just the decision
The three-panel layout kept being reopened by people who had not sat in the sessions, and re-arguing it from memory each time was slow. Once the evidence travelled with the decision (dispatchers hold 20–40 flights; a modal makes them hold it in their head), those conversations ended in minutes rather than a sprint. Across two offices and two time zones that was the difference between moving and stalling, and I have written decisions down that way since.
The brief was to modernise a 25-year-old interface. The work turned out to be defining what the product was for — what a dispatcher should be able to hold in view, how a flight should be structured, and who decides what matters. Watching dispatchers work, and testing a wrong answer early enough that being wrong was cheap, is what turned those three questions into decisions the rest of the programme could build on.