Don’t Slow the Line
A native boarding app for airport agents, designed against a stopwatch and tested on a real flight.
Boarding a real flight with the app, June 2026. Faces blurred for privacy.
Breeze airport agents currently board flights using the same reservation software used across the airport, designed for a desktop screen rather than for standing at a gate with a line of guests. We’re building a purpose-built native mobile app for that job: navigate to your flight, scan boarding passes, resolve exceptions, and capture bag revenue, end to end.
The project has two goals:
- •Capture bag revenue at the gate. Carry-on bags purchased after check-in currently slip through unpaid; boarding is the last moment to catch them.
- •Create a real per-guest boarding event. Downstream systems work off the whole manifest today, so connection tracking, partner integrations, and on-board services run on stale or coarse data. A per-guest event stream would give them something better to work from.
The app is mid-rollout, so this case study is a snapshot of work in progress rather than a finished story.
Boarding can’t get slower, so I started by timing it
The project has one constraint that everything else defers to: if the new tool slows boarding down, it’s worse than no tool at all. Before designing against that, I wanted a real number for how fast boarding is today.
So I timed it: two real boarding sessions, a stopwatch lap for every guest scanned, 196 measured scans cross-checked into a baseline to design against.
The distribution mattered more than the average: one in ten scans ran eight seconds or longer, and the worst interruptions (hard-to-read passes, manual lookups, guest questions) ran 17 to 36 seconds.
Design against the slow tail, not the happy path. The exception flow, not scan speed, is what decides how long boarding takes.
A card the agent reads in under a second
The heart of the app is the card that appears after every scan, glanced at for well under a second while boarding a line. The core design is stable; the exception states keep evolving as testing surfaces new cases.
Ready state, a clean board, a duplicate scan, and a system error, captured from the working prototype. The duplicate reports when the guest boarded without logging a second one; the error tells the agent what to do next.
Identity first, status redundant. The guest’s name is the headline: the agent confirms a person, not a code. Service codes the agent must act on (wheelchairs, exit rows, special assistance) surface as pills alongside it.
Some scans block, most don’t. Roughly 90% of scans need no action, so passive results clear themselves and the scanner stays live. A wrong-flight scan blocks hard: the agent has to resolve it before boarding anyone else.
Prototypes people could hold
A camera-based scanner is hard to evaluate in a Figma frame. I built a faithful web re-implementation of the scanner (every state, animation, and swipe-to-dismiss gesture) so agents and stakeholders could walk the whole flow on their own phones instead of a laptop screen.
The same idea carried into testing and handoff: a mock flight with guests assigned across all 21 service codes, so a tester scanning printed passes at a desk would hit every card state the design defines, and the card design moved into the production React Native screen myself, so engineering reviewed working code instead of static specs.
The first real flight
In June 2026 the app boarded its first revenue flight, Provo to Las Vegas. I analyzed the full recording afterward, frame by frame, against the baseline I’d measured at the start.
Three angles on that first production boarding. Footage is edited to protect passenger privacy.
Gross throughput ran about two seconds per guest behind the current system, which is roughly what I’d expect from a first live run. The encouraging part was where the time went. The fastest sustained stretch matched the baseline mean, so the happy path already keeps pace with a system agents have used for years. The gap came from a handful of 10 to 30 second exception stalls (a wrong-flight party, connection retries) and ordinary first-run learning.
One flight isn’t a conclusion, but it points the same direction as the benchmark: boarding time lives in the exceptions, so that’s where the design effort keeps going.
Taking a payment without stopping a line
This part is active design work right now. The app’s second mandate is catching unpaid carry-on bags at boarding, which means taking a card payment, at a gate, mid-line. We’re building it on Apple’s native Tap to Pay on iPhone. Airlines have used Tap to Pay for in-flight purchases; we haven’t found one doing it at the gate, inside the boarding flow.
The design carries the same line-pressure constraint as boarding itself: the amount is final before the phone is extended, so the guest sees one total on Apple’s own payment sheet and taps.
The payment flow prototype: amount confirmed before the tap, Apple’s system-drawn payment sheet, and the approved state. The middle screen is deliberately a labeled replica: Apple draws it, so the design work is everything around it.
The receipt details and the payment processor’s specifics are still being worked through with product and operations, and the design will move with them.
The most useful thing I did on this project was also the cheapest: standing at a gate with a stopwatch before designing anything. Having a baseline changed the conversations. Questions that would have been matters of opinion became questions about a number, and when the first live flight happened, there was something honest to measure it against.
The other thing this project keeps teaching me is about medium. Every review that mattered happened on a phone: a web prototype at a gate, printed test passes at a desk, working React Native code with engineers. The closer the artifact gets to the real thing, the better the feedback gets.
Where things stand now: the scan flow is in production testing, the payment flow is in design, and per-scan instrumentation is next. I’ll keep this study updated as the app rolls out.