Designing for people about to board a plane
People open an eSIM app at the airport, in a hotel lobby, on the edge of losing connectivity. That context dictates everything: short information, few steps, one tap copy for every code, and video guides because nobody reads manuals. This article covers the buy, pay, activate, identity and support flows I designed for this travel eSIM product, plus the UI guideline holding it together. Screens are low resolution with brand marks blurred.
Buy, pay, activate
The catalog gives each plan one card, with data, validity and price carrying the decision. Payment splits by platform: iOS and Android each order their methods, credit card and PayPal form two paths, and success, top up success and failure each get their own ending page, with failure stating the next step outright. Activation is where eSIM loses people: QR install first, manual entry as fallback, one tap copy on the SM-DP address and every code, and a short video per step.
Login, passport scan and ID verification
Some markets require verified identity, so sign up carries one decision point: scan an ID or type it. Scanning runs through a third party component and always lands on a review page where users check what was read; passports get their own path with rescan by document type. The ruling principle is the fallback: every scan can be skipped into typed entry, because when a verification component fails, registration must not die with it.
The UI guideline behind it all
One living UI guideline holds the product together: components, flows, per size states, cut pictures and marketing artwork share a single canvas, each block tagged with its status. Support lives there too, with contact us accepting camera and file attachments, because the most common report from the road is a screenshot. The guideline earns its keep across time zones: engineers follow the spec without waiting for me to wake up and answer.
