125+
Stations live on RAMP
Enter the password to view the RAMP Upload work.
Case study · Pablo Casanova · Sr. Product Designer
Scan./Verify./Push back on time.
Alaska Airlines’ below-the-wing operations app — load plans, pit-by-pit bag scanning, cargo, exception handling, and load submission to Central Load Planning, on one device in the ramp agent’s hand. It replaces a fragmented stack of desktop and legacy mobile tools.
The 30-second version
Situation, Task, Action, Result — the whole story compressed to what a hiring manager needs before deciding to read on.
Alaska loads a huge daily operation below the wing across a fragmented stack of legacy tools. The old flow hurt ramp safety and on-time (MBR) performance — and blocked the technical integration with Hawaiian Airlines.
Own the end-to-end UX for a single, ramp-native app that replaces RSA Mobile and the S4A / SmartSuite desktop detour — without losing any functionality agents depend on.
Audited the legacy workflow, reframed the app around the ramp sequence, and designed pit-by-pit scanning, load verification, and first-class exception flows — each pressure-tested in its own design review.
Live at 125+ stations with 85% of scheduled flights submitted via Upload. Upload-related delay minutes fell 85→24 week over week, with the max single delay under 10 minutes.
Why now
The legacy way of uploading commodities and loads was straining at the seams — and the stakes were the operation itself.
Sub-optimal scanning generated poor data and created weight-and-balance risk.
The merger brought new requirements the legacy stack simply couldn’t absorb.
Tool-switching and manual reconciliation quietly added minutes to every turn.
Agents were siloed into role-specific apps; shipping anything new was slow and risky.
How might we create a less complex, singular app that supports the new requirements from the Hawaiian Airlines merger?
Problem
Getting a plane loaded and off the gate on time is a race against the clock. But ramp agents were stitching the job together across disconnected systems — a legacy mobile app for scanning, and dense desktop load sheets (O97Bs) reachable only through S4A / SmartSuite after a flight was submitted at origin.
To answer a simple question — is there cargo on this inbound, and where is it? — an agent had to toggle between tools, cross-reference weights and pit locations by hand, and hope nothing changed. Every context switch was time on the clock and another chance for a bag to end up in the wrong place.
“Agents lacked direct visibility into inbound load information within the app… forcing users to toggle between multiple tools to determine if cargo is present and where it is located.”
Scans and loads bags and cargo, pit by pit, gloves on, clock running.
Owns the aircraft’s balance and sign-off — needs live, trustworthy counts.
Directs the operation but couldn’t see inbound cargo without leaving the tool.
Handles what comes off — blind to inbound load details until too late.
Solution
Everything an agent needs to load an aircraft and submit the load, in one app, in the order the work actually happens on the ramp — readable from ten feet, glove-friendly, honest about what’s left to do.
Learn and operate the app with little training — usable on day one, on a live ramp.
Solve complex problems and errors inside the experience, not by escaping to another tool.
Everything the legacy apps could do, the new one must do — nothing left behind.
The load plan opens with flight, tail, ETD and gate up top; a bag summary broken out by transfer / local / interline / thru; and the cargo manifest below. One Start Upload begins the job, and the pit overview lays out the aircraft’s compartments the way the agent sees them — each pit its own workspace with live counts.
Working a pit is scan-first, with manual entry and offload always a tap away. Each bag is confirmed against the plan in real time, and heavy bags are flagged inline so weight and balance stay honest.
The edge cases are the operation. Each one gets a designed path instead of a dead end.
A clear resolve path, not a hard stop.
A guided flow when a tag won’t resolve.
Same-aircraft bags handled without re-work.
Cancellations, tail swaps and offloads keep the load in sync.
The original ask that started it all: bring O97B essentials — destination, commodity code, pieces, weight, pit, remarks — into RAMP alongside bag data, so agents assess a load without switching tools. Containers load through the same scan-and-confirm model as bags, toward the same submission.
The last step before submission is the one that matters most. Load Verification puts planned vs. loaded side by side for every pit, with a running countdown to departure, so a mismatch is caught on the ramp — not in the air. When counts reconcile, the agent adds crew, confirms, and sends the load straight to S4A.
Explorations
The hard part of loading an aircraft isn’t the happy path — it’s the exceptions. I worked these through as scenario studies: one messy, real-world situation at a time, annotating the design decisions as I went.
Decisions & why
The old pit screen led with a dense table of fields. RAMP leads with a single scan target.
Gloves, weather, time pressure. A big scan action is faster and far less error-prone than editing rows mid-load.
Every pit shows what should be there and what actually is.
Nothing ships on a guess. Surfacing the delta protects weight-and-balance — a safety issue, not a nicety.
Thru-flights, tail swaps, unknown destinations and heavy bags each got a designed path.
The “rare” cases are someone’s every shift. Treating them as errors would push agents back to the old tools.
The missing view initially showed the whole flight; we scoped it to the current station.
Shipped from real launch feedback — cut the noise agents had to wade through to the bags they could actually act on.
Impact
RAMP Upload rolled out across the network and replaced RSA Mobile as the way stations load aircraft and submit loads before takeoff — tracked week over week against real departure performance.
What I owned
Operational software lives or dies on its edge cases — the “rare” flows are someone’s every shift. Designing for a live ramp reset my defaults toward clarity over density, and shipping station-by-station taught me to treat launch as the start of the design, not the end.