Global airline / Airport operations / Experience leadership
Tomorrow Kept Logging Into Yesterday.
Reimagining airport work, then building the design organization to carry it forward.
An agent needed to help a passenger. The newer application could not finish the job. The old terminal could.
I directed the experience transformation: reimagining airport work across desktop and mobile, working directly with client executives to advance the vision, and building the experience organization from inception. I defined roles, interviewed and selected delivery-team talent, staffed and structured the team, and established its design-to-engineering operating model.
BRIAN DAVID HENDERSONTHE PROOFFollow the Story
The upgrade that sent people backward
Years of accumulated complexity had made employee workarounds part of the passenger experience.
I remember a desktop environment carrying roughly 10–15 years of accumulated requirements, restrictions and workarounds. The newer application sat alongside older terminal tools that employees still needed to get through the day. Modernization had arrived. The old system had kept its job.
The research contained a telling comparison. One agent described rebooking in the terminal in less than 30 seconds, with one or two steps. In the newer application, the same kind of task could take one to two minutes and five steps.
This agent-reported comparison explained a behavior that a dashboard might otherwise label resistance: people returned to the tool that let them finish.
Other findings were harder to shrug off. An agent working in the terminal fallback could be logged out of both applications because the newer system considered them inactive. A passenger’s reservation could change without the electronic ticket being properly linked. Seat information could be stale. During disruption, an infant’s ticket might not change with the parent’s.
The employee had to notice the gap, know the workaround and carry the task through it. The passenger still expected an answer.
A broken employee experience does not stay behind the counter. A reservation, ticket or family traveling together can become the point where an internal systems problem reaches the person asking for help.
Experienced agents had accumulated extraordinary operational knowledge. They knew the shortcuts, the exceptions and the places where a clean-looking workflow would break. Newer employees faced a different problem: learning enough of that accumulated knowledge to function confidently.
The temptation was to make the newer application easier to use and call it modernization. Our early research and airport shadowing revealed a larger opportunity. We could reconsider how the work was organized, what an agent needed at each step, and how much of the system’s internal complexity the employee should have to absorb.
The old terminal had earned its place through usefulness. A future experience would have to earn its place the same way.
Legacy flight-service workspace and a proposed redesign, shown for context. This is not a measured task-time comparison.
Start with the work. Let the applications catch up.
I directed a shared-workflow strategy and early mobile vision; our team gave it research depth and design substance.
76 operational subprocesses mapped Across 12 core processes in the original research program.
60+ pain points identified Documented employee-experience research findings.
The engagement began with a small team and room to imagine something better. I led the original experience strategy and innovation work, including an early mobile prototype I designed to show what a more connected airport experience could become.
I worked with our researchers and designers on the questions, participated in discovery, and directed synthesis into strategic choices. Senior stakeholder interviews and airport observation gave us different views of the same operation: what the organization wanted to change and what employees needed to get the job done.
The question was practical: what should an airport employee be able to do when the passenger or operational problem is standing in front of them?
An airport has many roles, but those roles do not inhabit separate worlds. Gate agents, ticketing agents, [customer-service specialists] and other customer-service employees encounter overlapping needs: find a customer, understand a booking, change a seat, resolve an exception, handle a disruption. Rebuilding a separate experience around every role risked preserving the fragmentation in a newer form.
I pushed the direction toward shared business processes, with appropriate access for the employee doing the work. Gate-agent workflows gave us a useful starting point because they crossed so much of the operation. From customer lookup, we could design a clearer progression into the task while accounting for the exceptions experienced agents knew would arrive.
Our team mapped 12 core processes and 76 subprocesses, identifying more than 60 pain points. An earlier ATW readout recorded 62 improvement opportunities; the later final readout summarized 30-plus recommendations and 26-plus priorities. Those successive research and prioritization views gave us a way to turn a broad ambition into choices.
A feature could be connected to the process it changed, the roles it affected and the business measure it was intended to support. Researchers supplied the detail that made those choices credible. Designers and product colleagues made the implications tangible in workflows and prototypes.
That also changed the training question. New employees needed a clearer path through the task, with fewer historical workarounds to memorize. Experienced agents needed the exceptions they depended on to remain possible. Starting with customer lookup and carrying context through the workflow let us pursue both, without assuming that fewer screens alone would make the job easier.
Mobile made the ambition more tangible. An employee moving through the airport needed continuity: relevant customer and flight information, permission to act, and the ability to manage more than one piece of work without repeatedly starting over. My early prototype explored that opportunity. Later mobile concepts included concurrent tasks, role-dependent capabilities and a task tray that could keep work accessible.
There was already a mobile product in the environment. Our contribution was its future-state direction and its relationship to the desktop experience. The desktop and handheld could serve different situations while sharing the logic of the operation.
The proposed check-in flows made that relationship visible. A roaming employee could help resolve a passenger’s documentation issue; desk-based service remained available when the situation required it. The design followed the passenger’s need across devices and people.
That was a more useful future than asking every role to become an expert in another collection of disconnected tools.
Target-state check-in mapped across the customer, mobile employee and desk agent. Proposed process, not deployment evidence.
She knew every reason it couldn’t be done
Executive sponsorship helped reopen inherited constraints. Keeping a veteran designer in the work turned knowledge into advocacy.
One of the most consequential conversations involved a colleague who had helped design the original desktop application years earlier.
She knew it intimately. She also knew the decisions behind it: requirements that had been rejected, restrictions that had become permanent, compromises people had learned to live with. As the redesign progressed, those old rules kept returning to the discussion.
From her perspective, she was protecting the work from mistakes the organization had already made. From the team’s perspective, the future was beginning to resemble the system we were trying to move beyond.
She was being seen as a detractor. Some people considered removing her from the effort.
I saw knowledge we could not afford to throw away. I chose to retain her expertise and challenge the inherited restrictions, rather than remove the person who understood them. I spoke with her about what had changed.
My direct relationships with senior client leaders were consequential here. We had executive backing for a broader operational transformation, which gave us room to challenge constraints that an application redesign might simply inherit. I could bring that context into our conversation: the limitations she remembered deserved to be examined again. A previous refusal did not have to become a permanent design requirement.
The conversation gave her a different way to use what she knew. She began challenging inherited requirements herself, anticipating obstacles and helping the team question complexity that no longer needed to be there.
Her expertise had not changed. The permission to use it differently had.
That distinction mattered to the experience we were building. A redesign can quietly become a preservation project when every historical restriction returns as an unquestioned requirement. Keeping the knowledgeable person in the conversation gave us a better chance of separating operational necessity from the residue of old decisions.
Leadership, in that moment, meant giving institutional knowledge a future.
Build the runway before the traffic arrives
A compelling vision needs more than agreement. It needs an organization capable of making it real.
The original innovation began with a small team imagining a different way for airport employees to work. Turning that ambition into an enterprise transformation required something considerably larger.
The challenge wasn't simply designing better screens. It was establishing a design organization capable of supplying a growing engineering program with coherent, research-informed experience decisions.
I led the creation of that capability: establishing the Design and Innovation organization, defining its team structure, recruiting talent, planning capacity, and building the Design-to-Build operating model. I worked directly with senior client executives to secure alignment and investment in the people and practices the transformation needed.
We had substantial foundational work to do. Research needed to become shared workflows. Concepts needed to mature into interaction designs. Product priorities, experience architecture and development dependencies had to work together.
Our designers, researchers, product partners, client specialists and engineering colleagues each brought expertise that the larger transformation depended on. My responsibility was to organize those contributions around a common vision, give the team the backing to do excellent work, and establish a reliable way to move from innovation into implementation.
That meant making the capability repeatable. Onshore leadership and an offshore design lead coordinated complementary responsibilities. Shared components helped designers avoid solving the same question repeatedly. Experience epics, roadmaps and program-increment planning connected priorities to engineering dependencies, giving the team a way to carry decisions and their context into the next stage of work.
The design organization ultimately supported an engineering effort that, in my recollection, grew to more than 100 developers across approximately 12–15 sprint teams.
At that scale, experience leadership becomes organizational leadership. It's about how decisions are made, how talent is deployed, how priorities remain aligned, and how teams retain the context behind what they're building.
The point wasn't to keep designers busy or produce more deliverables. It was to create a sustainable capability that could carry the original experience vision into development.
The prototype showed what was possible. The organization gave us a way to pursue it.
Working organization model connecting onshore and offshore experience teams. This model does not establish staffed headcount or reporting relationships.
Planning board showing five sprint columns and linked dependencies. It does not establish sprint completion.
Forty-five minutes, multiplied
A historical scenario puts the annual labor-capacity opportunity at $93.75M–$112.5M, with its assumptions visible.
$93.75M–$112.5M in gross modeled potential annual labor-capacity value An illustrative full-participation extrapolation informed by an owner-reported, aggregated 25% task-time improvement measured across several workflows during the engagement. The measurement scope and representativeness require source reconciliation; the enterprise financial extrapolation is not realized savings or an independently validated forecast. The assumptions appear in Chapter 5.
The business significance becomes clearer when you consider how much employee time a fragmented workflow can consume across a large operation.
A historical business-case scenario assumed 25,000–30,000 potentially affected employees, each spending three hours a day on relevant tasks over 250 workdays. Under a hypothetical 25% reduction in task time, the potential recovery would be 45 minutes per assumed workday.
Across that full assumed population, those forty-five minutes become 4.69M–5.63M potential annual hours of employee capacity. At an assumed $20 per labor hour, that is $93.75M–$112.5M in gross modeled potential annual labor-capacity value.
These are illustrative, full-participation scenario figures. The population, task time, improvement rate and labor value were not independently validated. They are not measured productivity gains, an established rollout population, net financial benefit or realized payroll savings.
The scale still matters. Recovered time could create room for service, exception handling and operational work that otherwise competes with navigating the systems. Turning that capacity into a business result would depend on what actually changed, who adopted it and how the organization used the time.
For an experience leader, that makes workflow design an investment question. Which repeated moments consume the most effort? Which changes could remove that effort without removing necessary controls? What needs to happen in the product and in the organization for the potential to become real?
The research, future-state design and delivery capability gave the program a way to pursue those questions with considerably more substance than a new interface alone.
The prototype had to outlive the room
The team carried the vision into development reviews and limited agent testing, with an organization built to sustain the work.
The work progressed into development reviews and agent feedback. I recall testing with a small group of roughly ten agents and some limited desktop use or testing before my transition. The work had moved into development and limited evaluation; a global rollout is not established by that record.
The team had produced more than a vision. There were mapped processes, prioritized opportunities, desktop and mobile concepts, design work for implementation, and an organization learning how to supply that work to engineering. Researchers, designers, product colleagues, engineers and client partners each made the next stage possible.
Years later, I have seen airport employees using an evolved application and recognized elements of the experience direction we explored in those early prototypes. That is a personal observation of continuity, not a verified release history or adoption measure.
It matters to me because I remember how small the beginning was: a few people trying to imagine a better way for airport employees to work.
The idea grew. So did the demands placed on it. I directed the experience ambition, maintained the executive relationships that helped it advance, and built the capability to pursue it. The team gave that ambition its depth: the field insight, the difficult design decisions, the prototypes and the implementation work.
That was the leadership job: make room for a future worth building, then give talented people the direction, backing and working conditions to build it together.
A future-state experience earns its significance when it can leave the conference room and keep going.
Proposed experience across desktop, tablet and handheld devices during the design program; no independent rollout claim.
What would your people do with the time the system takes?
Let’s talk about the experience you want to create, and the organization it will take to deliver it.