The 72 hours

The hard part starts after the report

The 72 hours is an independent concept for the time between reporting a delayed bag and getting it back. Passengers receive status updates, but it can still be difficult to tell what is known and what happens next.

I worked across research synthesis, service design, UX/UI and prototyping to separate confirmed information from estimates and unknowns.

How can the app be clear about uncertainty without making a promise?

The tools already exist. The problem is what passengers can make of the updates

The research began with SITA’s Baggage IT Insights 2026, using data for 2025. Although mishandling rates fell by 23%, the information passengers receive while waiting remained the focus of this concept.

Lufthansa, KLM and Air France already support reporting, case tracking, delivery updates, item location sharing and expense claims. I did not redesign baggage tracing systems such as WorldTracer. I changed how their updates are presented to passengers.

• 24M, Bags mishandled in 2025
• 39%, Linked to transfers
• $6.3B, Annual industry cost in 2025

Industry figures: SITA, Baggage IT Insights 2026. These describe the context, not results of this project.

The research behind the decisions

Reports, airline guidance and product documentation informed the concept. The screens show a sample scenario and are not connected to WorldTracer or a live airline service.

• SITA · Baggage IT Insights 2026
• Read the published findings
• SITA · WorldTracer
• Lufthansa
• KLM
• Air France
• Apple Support · Find Lost Item
• EUR Lex · Montreal Convention
• ICAO · Revised liability limits
• W3C · WCAG 2.2, Contrast (Minimum)
• Apple Developer · UI Design Dos and Don’ts

The airline knows more than the passenger sees

I mapped three moments in a sample recovery case to compare the operational event with the passenger’s experience. The sample ends with delivery on 15 March at 15:12, approximately 72 hours after the report.

Flight details, dates and case references are illustrative.

From report to return

Four moments organise the journey. Booking details are already filled in when the passenger confirms the case; the interface then explains the search, the recovery and the remaining actions after delivery.

01 / Report

Confirm the case and booking details.

02 / Wait

Understand what the airline is doing.

03 / Recover

Follow progress, keeping confirmed and expected separate.

04 / Resolve

Confirm delivery, organise expenses and prepare the claim.

Prioritise the current state over stage numbers

I made the status larger and separated the next update. The last confirmed scan stays visible, so a planned flight does not look like a delivery promise.

Found does not mean on its way

A confirmed location is not a delivery estimate. The interface separates what the airline has verified from a plan that can still change. When a bag is found, its delivery date can remain unknown.

Confirmed location ≠ delivery date.

Confirmed

A verified airline event.

Expected

A current plan that may change.

Passenger provided

Information from the traveller or their tracker.

Unknown

Information not yet available.

No new update does not mean the search has stopped

The overview keeps the last confirmed scan visible, explains current system activity and states what will trigger the next update. This gives waiting a clear context without inventing progress.

A shared tracker location stays separate from airline confirmed information. The location sharing reference includes an approximate location, a seven day link expiry and the option to stop sharing.

Explain expenses without promising reimbursement

While the bag is delayed, the interface explains essential purchases and asks passengers to keep receipts. The airline decides which costs it will reimburse. After return, the sample case shows the 21 day written delay claim deadline.

The research distinguishes the 1,519 SDR baggage liability limit from a spending allowance or automatic reimbursement. The claim deadline reference is Montreal Convention Article 31(2) and 31(3); damage has a different deadline. Carrier procedures vary.

Design references: KLM baggage guidance, Montreal Convention and ICAO’s revision effective 28 December 2024. These are the rules used in the concept, not a live claims service.

When support opens, the case is already there

Before chat or callback starts, the agent receives the case reference, bag description, confirmed and expected events, tracker status and saved expenses. The passenger should not need to reconstruct the whole story.

Case history

Reference, bag details and verified events.

Current context

Expected recovery, shared location and saved expenses.

Two changes that made the next step clearer

In the status overview, I made the current state larger and gave the next update a separate line. The earlier design gave more prominence to stage numbering; the revision prioritises what the passenger needs to know now.

In support, I moved the case summary above the contact options and clarified which details are ready for the agent. The case context comes before the choice between chat and callback.

These are design iterations, not usability test results.

Movement marks a change in status

The prototype sequence moves from searching, to a confirmed match, to an assigned recovery flight. The last confirmed scan stays visible even after a flight is assigned.

Transitions use 250 to 500 ms with ease out timing. A crossfade provides the reduced motion alternative.

What I checked. What still needs testing

I checked contrast, touch targets, state labels, reduced motion alternatives and 120% text scale reflow on five key screens. No text collisions or clipping appeared in those prototype checks.

Each update identifies its source and status. Confirmed and expected use different wording, and support retains the case history. I did not run passenger usability tests or connect the prototype to a live baggage system. Full Dynamic Type, keyboard, screen reader and browser zoom behaviour require a coded build.

Can passengers distinguish confirmed updates from estimates without extra explanation?

• 7.9:1, Ink / Confirmed Blue contrast
• 44×44, Touch target design criterion
• 120%, Text scale reflow check

Calculated pair: #0D2135 / #84BCDC = 7.937:1. Prototype checks are not accessibility certification.