Case study · Service design

RepApp

RepApp replaced the paper list travel reps carried into every airport arrival.

RoleUX & Interface Designer
DisciplineService design · Field research
ContextItaka · Travel
Year2020 — 2023
PlatformOffline-first tablet
An arrivals hall, a rep, the day’s excursions on screen. The tablet took over the job the printed A4 used to do here. Interface reconstruction, 2026, composited into a photo.
An arrivals hall, a rep, the day’s excursions on screen. The tablet took over the job the printed A4 used to do here. Interface reconstruction, 2026, composited into a photo.
At a glance
Problem
A rep met every flight with a printed A4 list and 100+ names to check. The same data was entered three times, and the airports often had no signal. The busiest hour of the trip ran on paper.
My role
UX & Interface Designer. I spotted the unserved reps during Itaka’s platform redesign and owned the service design from there: field research, MVP definition, interaction design and prototypes, and field testing at airports. Engineering by the in-house dev team, within a small design team.
Value
  • 50%+ faster: the rep clears the airport in less than half the time the paper list took
  • Retyping gone: one offline entry replaced the Excel evenings and the manager’s re-entry, 30%+ less back-office work
  • 1.44M passengers: handled through the app in 2023, three years after launch
Shipped product, 2020 · figures reported by Resabee Travel Tech
01 · Origin

Nobody had designed anything for the destination reps yet

The project surfaced during Itaka’s platform redesign. The destination reps meet flights, run transfers and sell excursions across more than 100 destinations, and no one had built a tool for them. That gap became a brief.

A destination rep with the printed Itaka clipboard and pen — the guest-facing job, and the paper tool, that no one had yet designed for.
A destination rep with the printed Itaka clipboard and pen — the guest-facing job, and the paper tool, that no one had yet designed for.
02 · The problem

A rep met every flight with a printed A4 list and over 100 names to check

Everything on that paper was typed into Excel that evening, then retyped by the department manager into our enterprise system. The same information was entered three times.

The printed A4 arrivals list — ticked by hand at the gate, then keyed into Excel and re-keyed into the enterprise system. The same data, entered three times. Reconstruction, 2026.
The printed A4 arrivals list — ticked by hand at the gate, then keyed into Excel and re-keyed into the enterprise system. The same data, entered three times. Reconstruction, 2026.

Nothing could assume a signal

Destination airports frequently had no working internet. Offline was not a fallback, it was the condition the whole architecture sat on.

Offline-first: the airport had no signal, so every action was captured on the device, queued, and reconciled with the enterprise system only on reconnection. Diagram, 2026.
Offline-first: the airport had no signal, so every action was captured on the device, queued, and reconciled with the enterprise system only on reconnection. Diagram, 2026.
03 · Buy-in

The first pitch failed, because it made the wrong case

The first pitch led with efficiency for the reps. The room was deciding on budget, and travel had just stopped. A second pitch, built on research and on what competitors were already doing, passed. The first argument had been correct and irrelevant at once.

The competitive slide from the winning pitch — every operator already equips its reps; Itaka was the last one on paper. Reframed from “efficiency for the reps” to a gap the room could see. Reconstruction, redrawn 2026; competitors anonymised, grid illustrative.
The competitive slide from the winning pitch — every operator already equips its reps; Itaka was the last one on paper. Reframed from “efficiency for the reps” to a gap the room could see. Reconstruction, redrawn 2026; competitors anonymised, grid illustrative.
04 · Research

The pandemic emptied the destinations and opened the research window

Reps are normally impossible to reach, abroad and in motion through peak season. In 2020 they were employed with almost no guests. Two to three months went into interviewing around ten of them, and into building the observation instrument our Product Owner then used at destination airports.

05 · Scope

Only features that helped the rep and earned money at once could ship

With no budget, anything doing only one of those jobs could not survive review. That rule decided the scope, and cut the feature the reps needed most.

What was scoped out

  • Reporting and system integration. What reps needed most. It shipped later.
  • Contactless check-in. Blocked on the consumer app’s backlog, not on us.
  • Anything that could not defend itself commercially.
The MVP rule as a 2×2 — a feature had to help the rep and earn money to ship. Only the top-right quadrant survived; reporting, the feature the reps needed most, was cut for later. Redrawn 2026.
The MVP rule as a 2×2 — a feature had to help the rep and earn money to ship. Only the top-right quadrant survived; reporting, the feature the reps needed most, was cut for later. Redrawn 2026.
06 · Device

The reps chose the tablet, and their reasoning was about their hands

Both options went to the reps. They had worked from A4 held in both hands and turned toward the guest. A phone would have changed the format and the tool in one week. The tablet kept the gesture, and let them show excursion video while selling.

A4, tablet and phone at true relative size. The tablet stayed close to the page, so the two-handed, guest-facing gesture survived — and left room to play excursion video; the phone was too small to show or to share. Reconstruction, redrawn 2026.
A4, tablet and phone at true relative size. The tablet stayed close to the page, so the two-handed, guest-facing gesture survived — and left room to play excursion video; the phone was too small to show or to share. Reconstruction, redrawn 2026.
07 · The build

The MVP followed the arrival in the order it actually happens

Three tabs, matching what a rep does between gate and coach.

  1. Attendance — search by surname or reservation number
  2. Hotels — which group goes where
  3. Transfers — which coach, what time, both directions

Excursion sales sat alongside, also offline.

The three-tab MVP in sequence — Attendance, Hotels, Transfers — built to follow the arrival in the order it actually happens, on one offline app. Interface reconstruction, redrawn 2026.
The three-tab MVP in sequence — Attendance, Hotels, Transfers — built to follow the arrival in the order it actually happens, on one offline app. Interface reconstruction, redrawn 2026.
The Excursions tab: local trips browsed and sold beside check-in, offline, with video to show the guest. Interface reconstruction, 2026; offers, prices and photos illustrative.
The Excursions tab: local trips browsed and sold beside check-in, offline, with video to show the guest. Interface reconstruction, 2026; offers, prices and photos illustrative.
08 · The decision

We built check-in around the passenger, and field testing proved that wrong

Our database stores people individually, so that is how the first build worked. In the field a family of five walked up as one group and the rep tapped five times. On paper, one stroke of a pen covered all five. Digitising the data model would have made the job slower than paper, so we rebuilt check-in around the reservation.

A night arrival met from the rebuilt list: the family that walks up as one group is one row, one tap. Interface reconstruction, 2026, composited into a photo.
A night arrival met from the rebuilt list: the family that walks up as one group is one row, one tap. Interface reconstruction, 2026, composited into a photo.
Checked in as a group by default, opened traveller-by-traveller only when the field needs it.
Checked in as a group by default, opened traveller-by-traveller only when the field needs it.
09 · Constraint

The reps warned us about sunlight before we built anything

They warned us in interviews that nothing would be readable in full sun, and testing confirmed it. Across 100 destinations we could not solve this for one climate, so contrast went into the hardware specification.

The same list indoors and in direct sun — contrast as a functional decision, written into the hardware spec. Interface reconstruction, 2026.
The same list indoors and in direct sun — contrast as a functional decision, written into the hardware spec. Interface reconstruction, 2026.
10 · Outcome

Over 50% less time at the airport, and a whole layer of retyping gone

Once reporting connected to the enterprise system, the rep’s Excel work and the manager’s re-entry disappeared.

The Excursions tab in a rep’s hands at the gate: local trips browsed and sold from the tablet, offline. Interface reconstruction, 2026, composited into a photo.
The Excursions tab in a rep’s hands at the gate: local trips browsed and sold from the tablet, offline. Interface reconstruction, 2026, composited into a photo.
Reported by Resabee Travel Tech
50%+
less time at the airport
30%+
less back-office work
1 442 793
passengers handled in 2023, three years after launch
11 · The tension

Gamification lifted sales, and the unease it left has stayed

When reporting shipped, we added points and team rankings showing who sold most each month. Sales rose sharply. The pressure to repay the hardware was real, and so is the discomfort of publishing individual figures inside a team that lives and works together.

The gamified team-standings view — points and a monthly ranking of who sold most, individual figures visible to the whole team. It lifted sales sharply, and named a loser every month. Interface reconstruction, redrawn 2026; names and figures illustrative.
The gamified team-standings view — points and a monthly ranking of who sold most, individual figures visible to the whole team. It lifted sales sharply, and named a loser every month. Interface reconstruction, redrawn 2026; names and figures illustrative.
12 · Lessons

What the project taught, and what would change next time

  • A correct argument is not a persuasive one. The criteria the room used had to be found first.
  • Both product-changing findings came from watching, not asking.
  • Systems carry assumptions about their users. Passenger-level check-in came from the schema, not a choice.
  • Resources are worth negotiating before saying yes, not after.
  • Whether the reps trusted the sync went untested. A rep who does not keeps a paper backup, and the paper stays.
  • GDPR draws the line for shortcuts. A throwaway build with guest data can only go so far.

Today I would prototype before the first pitch, not after the rejection.