When the algorithm meets the operator
Designing a tool that turns optimization algorithms into departure plans that airport baggage operators actually trust, adjust, and use every day.
- Problem
- Copenhagen Airport had to absorb years of peak baggage growth without buying new infrastructure, while planning stayed manual and split across three organizations.
- Role
- Sole product designer. From discovery and field research, through a 5-phase testing program, to go-live.
- Outcome
- Shipped for summer 2026 and now in production at Copenhagen Airport.
Role
Product Designer
Timeline
Q1 2025 to March 2026
Company
Bagstage
Client
Copenhagen Airport
It replaced manual, template-based planning across the airport’s entire departure operation: 100+ chutes and 500+ daily departures, in one shared tool.
Deferred new infrastructure
The planning layer behind absorbing four summers of peak growth without new baggage equipment
One shared tool, three teams
Replaced fragmented manual planning that was split across three organizations
Validated with real operators
A 5-phase testing program run on-site at CPH before go-live
Copenhagen Airport (CPH) handles over 30 million passengers a year. During summer peaks, the baggage system was already running out of capacity. More flights during peak hours, growing transfer volumes, and larger aircraft were all putting more pressure on existing infrastructure.
The airport needed to get through the next four summers without buying new equipment. The only option was to optimize how existing resources are used.
Before
Manual, template-based planning
Fragmented across 3 organizations
No algorithmic allocation
No shared planning interface
No way to validate plan quality before production
After
Algorithm generates optimized plans overnight
Operators validate and adjust in one shared tool
Manual re-optimization after any changes
Plans export to legacy system for execution
100+ chutes, 500+ daily departures optimized
Users & Stakeholders
Three organizations, each with different tools, different priorities, and different mental models of what a good plan looks like.
Primary User
Baggage Operator
Plans departure allocations 2–4 days ahead. Reviews what the algorithm produces, adjusts handler areas, creates override rules, and exports plans. 2–3 people at CPH do this daily.
Secondary User
Baggage Handler
Receives plans and adjusts within allocated chutes. View-only access in DOM. Works for a ground handling company: SAS Ground Handling (SGH), Aviator, or Menzies.
System Partner
Legacy System Vendor
Owns the legacy planning system. All plans must export there for operational execution. Integration design was a joint effort.
How do you let an operator trust a plan generated by an algorithm they don’t fully understand?
The algorithm weighs hundreds of constraints: flight schedules, segregation requirements, handler agreements, chute load types, opening times, and demand predictions. It produces a full allocation for 500+ daily departures. The operator then needs to look at that output and decide: is this good enough to send to the handlers?
I identified four surfaces the module needed. Each addresses a different part of the trust equation.
Gantt View
Inspect the output
Area View
Configure the inputs
Manual Rules
Constrain the algorithm
Optimization
Control the workflow
How does the day look?
The main interface. A horizontal timeline showing every departure assigned to a chute, color-coded by ground handling company. Unallocated flights stay pinned at the top, always visible.
Why a Gantt chart? Because operators think about a day left-to-right, early-to-late. The layout had to match that mental model. Why unallocated flights at the top? Because they’re the first thing an operator needs to act on: anything the algorithm couldn’t place is a problem.
Who has which chutes?
A spatial view of the physical baggage hall. This is where operators set up infrastructure constraints before the algorithm runs.
The design choice: Show the hall as it physically exists, not as a settings form. When operators say “SGH has boxes 1–8 plus the flex,” they’re thinking of the physical space. The area view mirrors that. Key interaction: Select multiple chutes, reassign them to a different handler, re-run the optimization. One action, system-wide impact.
The algorithm should respect this.
Operator overrides that constrain the optimization. Rules capture domain knowledge the algorithm doesn’t have: airline preferences, operational habits, historical patterns.
The design decision: Rules as natural-language constraints, not algorithm parameters. An operator shouldn’t think about constraint weights. They should think: “Emirates always gets box 14.” The system translates that into a hard constraint for the solver.
Validated in Phase 3 testing: operators accepted manual rules as the way to control the algorithm. Zero critical defects. The concept and interaction patterns are solid for the MVP, with refinements planned for version 2 based on real usage data.
Run it, review it, trust it.
The algorithm runs overnight and generates optimized plans for the next 4 days. Operators review the output each morning. If they change something in the Area view, or new flight data comes in, they can trigger a re-run directly from the interface.
The design principle: Make the algorithm’s status always visible. Operators don’t need to understand how it works. They need to feel in control: constrain it (rules), inspect its output (Gantt), override its inputs (area view), and know when it’s stale.
Overnight Run
Algorithm optimizes next 4 days
Review Plan
Operator checks Gantt, identifies issues
Adjust
Change areas, add rules, update config
Re-optimize
Manual re-run, review updated plan
Export
Push to legacy system
5 phases, 4 months, real operators
I wrote the full test plan, ran every session at Copenhagen Airport, classified all defects, and produced findings reports that fed directly into the engineering backlog.
Gantt Chart
Removed technical labels, added bag counts and segregation to tooltips
Area View
Discovered cascade direction mental model mismatch on multi-row sub-areas
Manual Rules
Validated core mental model. Zero critical issues. Refinements for version 2
End-to-end
Full workflow validated, login through export. Baggage handler view-only mode confirmed
Infrastructure
Box infrastructure configurations, load types, disabled boxes, save scope
Each phase used structured task scenarios, comparing observed against expected behavior and classifying defects as Critical, Major, or Minor. Findings were shared with the full project group across all three organizations.
The system went live for summer 2026
Avoided Capital Expenditure
Four summers without new baggage infrastructure
The airport’s goal was to absorb peak growth through optimization alone, not by buying new equipment. DOM is the planning layer that makes that possible, covering 100+ chutes and 500+ daily departures.
Efficiency Target
“If we start from using 100% of the time and we get to using only 50% or less, then we’re good already.”
CPH Baggage Operator, on moving planning off manual templates
Reflection
Trust comes from control
Operators never asked how the algorithm works. They asked: can I constrain it? Can I inspect its output? Can I override it? Trust came from feeling in control, not from transparency about internals.
Real users changed every phase
The most valuable feedback came from people who’ve done this work for years. Chute labels, cascade direction, flight number formatting. Things no designer catches from a desk.
Cross-org design is negotiation
The sub-area cascade looked like a UI mismatch, but it was really about how the three organizations think about space. At this level, design is as much about reaching agreement as it is about drawing interfaces.