Protected case study

Enter the password to view the RAMP Upload work.

Case study · Pablo Casanova · Sr. Product Designer

RAMPUPLOAD

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.

Role Sr. Product Designer Type Operations mobile app Timeline 2025–26 Status Live Scale 125+ stations
RAMP Upload splash screen on an iPhone
125+
Stations live on RAMP
85%
Flights submitted via Upload
24
Delay min / week · down from 85
<10
Min · max upload-related delay

The 30-second version

Skim it in four beats.

Situation, Task, Action, Result — the whole story compressed to what a hiring manager needs before deciding to read on.

STARSituation · Task · Action · Result
SSituation

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.

TTask

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.

AAction

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.

RResult

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 tool that loads the plane had become a liability.

The legacy way of uploading commodities and loads was straining at the seams — and the stakes were the operation itself.

Driver 01
Ramp safety

Sub-optimal scanning generated poor data and created weight-and-balance risk.

Driver 02
Hawaiian integration

The merger brought new requirements the legacy stack simply couldn’t absorb.

Driver 03
MBR / on-time

Tool-switching and manual reconciliation quietly added minutes to every turn.

Driver 04
Feature velocity

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?

The framing question I set for the work

Problem

One aircraft, five tools, zero margin.

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.”

From the RAMP problem statement
<b>S4A.</b> The admin desktop system Central Load Planning still uses to see how many bags and cargo are expected on each aircraft. RAMP removed the ramp agent’s detour into it — it didn’t replace S4A.
S4A. The admin desktop system Central Load Planning still uses to see how many bags and cargo are expected on each aircraft. RAMP removed the ramp agent’s detour into it — it didn’t replace S4A.

Four roles, one fragile handoff

On the ramp
Ramp agent

Scans and loads bags and cargo, pit by pit, gloves on, clock running.

Owns the load
Lead / LC

Owns the aircraft’s balance and sign-off — needs live, trustworthy counts.

Planning
Assigner

Directs the operation but couldn’t see inbound cargo without leaving the tool.

Recovery
Offload agent

Handles what comes off — blind to inbound load details until too late.


Solution

RAMP Upload, end to end.

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.

The principles we set

Principle 01
Ease of use

Learn and operate the app with little training — usable on day one, on a live ramp.

Principle 02
Empower the user

Solve complex problems and errors inside the experience, not by escaping to another tool.

Principle 03
No loss in functionality

Everything the legacy apps could do, the new one must do — nothing left behind.

The flow, end to end

One pass through the app: enter the flight, work each pit bag by bag, resolve what does not match the plan, then verify and submit — the map the screens below walk through.

Enter the flight Flight 01 Overview 02 Load plan 03 Pit selection 04 Work the pit Scan bag 05 Bag on the plan? Exception path no Unexpected bag Resolve inline resolved yes Loaded to pit 06 Verify and submit Missing bags 07 Review load 08 Load verification 09 Counts reconcile? no → work the pit again yes Submitted 10 Flight 01 Overview 02 Load plan 03 Pit selection 04 Scan bag 05 Bag on the plan? no Unexpected bag Resolve inline resolved Loaded to pit 06 Missing bags 07 Review load 08 Load verification 09 Counts reconcile? yes Submitted 10
End to end. Ten steps, two decision points — the exception path and the reconcile loop are where the design work went.

Start with the plan

The load plan opens with flight, tail, ETD and gate up top; special-handling flags (DG, AVIH, WCHR) called out where they can’t be missed; and a bag summary broken out by transfer / local / interline / CAG, drilling down pit by pit. 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.

<b>Load plan.</b> Flight, tail, ETD, gate, special-handling flags and a pit-level bag summary — one Start Upload to begin.
Load plan. Flight, tail, ETD, gate, special-handling flags and a pit-level bag summary — one Start Upload to begin.
<b>Pit overview.</b> Each compartment its own workspace with live bag and cargo counts — and missing bags surfaced up front, not discovered at the belt.
Pit overview. Each compartment its own workspace with live bag and cargo counts — and missing bags surfaced up front, not discovered at the belt.

Scan, pit by pit

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.

Pit selection. Bags and cargo for the compartment, reviewed before committing to it.
Pit selection. Bags and cargo for the compartment, reviewed before committing to it.
Working the pit. Pit 2 locked in — scan-first, with manual entry and offload a tap away.
Working the pit. Pit 2 locked in — scan-first, with manual entry and offload a tap away.
Scan first bag. The pit becomes a live workspace; counts move as bags land.
Scan first bag. The pit becomes a live workspace; counts move as bags land.
Bag scanned. Tag, type and total confirmed against the plan — correctable on the spot.
Bag scanned. Tag, type and total confirmed against the plan — correctable on the spot.
Color-coded bags. Priority, heavy and claim-at-gate ROC each read at a glance.
Color-coded bags. Priority, heavy and claim-at-gate ROC each read at a glance.

Handle the exceptions

The edge cases are the operation. Each one gets a designed path instead of a dead end.

Off-plan
Unexpected bag

A clear resolve path, not a hard stop.

Routing
Unknown destination

A guided flow when a tag won’t resolve.

Continuation
Thru-flights

Same-aircraft bags handled without re-work.

Recovery
IRROPS

Cancellations, tail swaps and offloads keep the load in sync.

<b>Unexpected bag.</b> Resolve on the spot — keep the load moving.
Unexpected bag. Resolve on the spot — keep the load moving.
<b>Plan changed.</b> A new revision surfaces immediately — never loading to a stale plan.
Plan changed. A new revision surfaces immediately — never loading to a stale plan.

Cargo, in the same flow

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.

<b>Load cargo.</b> Containers handled in the same pit workspace as bags.
Load cargo. Containers handled in the same pit workspace as bags.

Verify, then submit

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 works the exceptions, clears the safety checklist, and sends the load straight to S4A.

Missing bags. Bags and cargo on the plan but not on the aircraft, each with its last scan.
Missing bags. Bags and cargo on the plan but not on the aircraft, each with its last scan.
Review load. A guarded confirm before the flight moves into review and submission.
Review load. A guarded confirm before the flight moves into review and submission.
Load verification. Planned vs. loaded per pit, countdown to departure, then send to S4A.
Load verification. Planned vs. loaded per pit, countdown to departure, then send to S4A.
Flight submission. Flight, ramp lead and loaded totals checked one last time.
Flight submission. Flight, ramp lead and loaded totals checked one last time.
Submission confirmation. Dangerous goods and the safety checklist acknowledged before submit.
Submission confirmation. Dangerous goods and the safety checklist acknowledged before submit.
Flight submitted. Sent to Central Load Planning, with crew and load time on record.
Flight submitted. Sent to Central Load Planning, with crew and load time on record.

Explorations

Designing for the edge cases.

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.

Exploration: blocked and NIL pit states
Blocked & NIL pits. Making it unmistakable when S4A has blocked a pit — so a lead agent knows it must be empty before sending the load.
Exploration: unknown bag destination flow with design notes
Unknown bag destination. Routing a bag whose tag won’t resolve — choose from valid destinations only, sorted per route, with haptics. Design notes captured inline.
Exploration: loading cargo into a pit
Cargo into the pit. Surfacing how much cargo a pit still needs, and confirming each container the same way as a bag.
Exploration: guarding a pit change when cargo is unloaded
Leaving cargo behind. Guarding the pit change — if planned cargo isn’t loaded yet, catch it before the agent walks away.

Decisions & why

Every call, and the reason behind it.

Before · legacy pit selection
Legacy pit selection screen
After · working pit
Redesigned working-pit screen
Decision 01
Scan-first, not form-first

The old pit screen led with a dense table of fields. RAMP leads with a single scan target.

Why

Gloves, weather, time pressure. A big scan action is faster and far less error-prone than editing rows mid-load.

Decision 02
Planned vs. loaded, always on screen

Every pit shows what should be there and what actually is.

Why

Nothing ships on a guess. Surfacing the delta protects weight-and-balance — a safety issue, not a nicety.

Decision 03
Exceptions as first-class flows

Thru-flights, tail swaps, unknown destinations and heavy bags each got a designed path.

Why

The “rare” cases are someone’s every shift. Treating them as errors would push agents back to the old tools.

Decision 04
Missing bags, scoped to the station

The missing view initially showed the whole flight; we scoped it to the current station.

Why

Shipped from real launch feedback — cut the noise agents had to wade through to the bags they could actually act on.


Impact

Shipped, adopted, measured.

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.

125+
Stations live — Alaska & Horizon network
85%
Flights via Upload — single reporting week
85→24
Delay min / week — max single delay <10 min
Safer
Purpose-built flow cuts the guesswork the old stack forced on agents
Ready
A modern foundation that unblocks the Hawaiian Airlines integration
One device
Bags, cargo, verification & submission off the desktop detour
Faster
Feature-by-feature architecture makes the next capability less risky

What I owned

Role & reflection.

  • 01End-to-end UX for the RAMP loading experience — from workflow audit to shipped flows.
  • 02Problem framing — authored the framing question, hypothesis and principles.
  • 03Core interaction model — pit-by-pit scanning and load verification.
  • 04Exception design — thru-flights, IRROPS, unknown-destination, heavy & unexpected bags.
  • 05Design reviews — ran a review per feature with product and engineering.
  • 06Launch & iterate — folded real station feedback back into the product.

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.

What I took from it
Design
UX Workflow auditUX Interaction designUI Mobile systemUX PrototypingUX Design reviews
Domain
Ops Below-the-wingOps Load planning / S4AOps Baggage & cargoOps IRROPS
Ways of working
Team Cross-functionalTeam Launch & iterateTeam Station feedback

Employee satisfaction

The ramp graded it.

RAMP ESAT is the satisfaction index the agents themselves answer. Between H2 2025 and H1 2026 — the first full period after rollout — the overall score moved 21 points, and every driver we designed against moved with it.

Overall ESATEmployee satisfaction score
H2 202555.3%
H1 202676.5%
▲ 21.2 pts
Reliability
77.8%
▲ 22.2 pts
H2 2025 55.6%
Efficiency
82.1%
▲ 22.1 pts
H2 2025 60.0%
Ease of use
80.0%
▲ 17.8 pts
H2 2025 62.2%
Data accuracy
71.1%
▲ 22.2 pts
H2 2025 48.9%
Connectivity
77.8%
▲ 13.4 pts
H2 2025 64.4%