PRE-UX RESEARCH · 21 SEPTEMBER 2026 · v0.02
Fewer detours.
A next step when things fail.
The desktop research pass is complete for all eight customer journeys in this checkout. The largest opportunities are payment recovery, clear completion states and keeping the right eSIM context. The existing purchase path is already short.
Status: source-based findings and proposed journeys, ready for design review. No production changes, live payments, participant study or measured time savings. “Complete” refers to this desk audit, not proof that the product has no dead ends.
How to read the findings
Observed means visible in the local page scripts/templates; it does not mean reproduced against live services. Proposed means a research recommendation. Unverified marks a provider, device, backend or user-behaviour question.
A map box is a screen or state, not a click. Counts below use one activation for a link/button/bookmark, and one field task for entering or selecting a value. They exclude scrolling, reading, individual keystrokes, wallet/provider actions and phone settings. Opening a collapsed phone menu adds one activation per menu use. Saving an order link is counted separately because browser methods vary.
These are conditional action budgets derived from controls, not recordings of people. No seconds or percentages are claimed. Network settlement and fulfilment time cannot be reduced by deleting interface steps. Benefits such as fewer searches, app switches and repeated entries need user validation.
Scope includes purchase, installation, returning customers, top-up, renewal, bulk, pricing/help and interrupted payment; staff tools and future tracker features remain outside this pass. Existing API usage was read, but backend implementation and payment-provider screens were not audited.
Eight reviewed journeys
01 · Buy an eSIM
Observed: home.js · continueHomeCheckout / initHomePage; order.js · initOrderPage / handleOrderError; storage.js
Plan, balance and payment method are chosen on Home. The method button creates checkout, saves session handoff data and navigates to the order; payment opens automatically when the pending response permits it. Saving the displayed order URL is advice, not a required confirmation step. Price minimums may increase balance when Altcoins is clicked; network-fee detail is in a tooltip.
Proposed: compare plan and full payable amount → choose payment → order with automatic invoice → payment status → installation.
Keep the short path. Make adjusted amounts and fees visible before commitment, including with touchpad/touch and keyboard; do not rely solely on hover. Add an explicit save-link action that does not block payment. Preserve selection after errors. Initial stock-load failure currently ends with a toast and removes the loader, with no dedicated retry.
Decision: prioritise continuity and clarity over removing another click. Provider totals, confirmation states and denied-storage handoff remain verification items.
02 · Install and connect
Follow-up research: direct installation links exist for iOS and Android. Read platform evidence, proposed UX and device-validation requirements. The original baseline below describes the current site.
Observed: order.ejs; order.js · updateQrFields / copyInputValue / showSimInfo; faq.ejs
QR, address, activation code and unified string are available. Same-phone instructions explicitly ask for manual entry. Activated SIM details are hidden behind Show. Clipboard failure has no visible feedback in the copy handler. Installation and network help sit in the FAQ; the order has no direct installation-FAQ link.
Proposed: choose “this phone” or “another device” → supported direct handoff or appropriate manual/QR instructions → device setup → connection help if needed.
Offer paths without forcing an extra chooser when the next action is clear. Direct installation is a feasibility question, not an existing feature or a guaranteed one-click setup. Keep copy/manual fallback and explicit copy success/failure. Link directly to the relevant FAQ answer.
Recovery: preserve installation details and offer help; do not recommend deletion/reinstallation as a generic retry. Current template distinguishes one-time NO NUMBER/IDENTITY eSIMs from DATA.PLUS. Device-specific guidance requires separate verification.
03 · Return to the right eSIM
Observed: order.ejs; order.js · renderOrder / loadBalance / handleOrderError; storage.js
The saved private order URL opens status and balance automatically. There is no account-based order list or visible self-service lost-link recovery. The page stores one IMSI in localStorage. A later visit to another order can replace it, while Top up uses a generic /topup link. This creates a possible wrong-SIM context mismatch across tabs; occurrence is unmeasured.
Proposed: saved link → identifiable eSIM summary → relevant action with explicit SIM context. Missing link → actionable help using whatever evidence the customer still has.
Make save/copy discoverable and identify the SIM before money is added. Keep manual identifiers for customers entering directly. Support must not promise a fresh private link without an agreed ownership-verification process; someone who lost a link may also lack the requested order reference.
Recovery: clear invalid-link and balance errors with an actual support route. Treat private order URLs/activation details as access credentials; do not automatically copy them into external support URLs or research analytics.
04 · Add balance
Observed: topup.js · loadTopupData / payment callbacks; order.ejs; public-page.js · setupCheckoutPolling; success.ejs
Top up reads stored IMSI, validates it on input/change and opens payment from a method button. Processing/Settled events clear all inputs. There is no explicit return-to-origin order link or receipt state in that handler. The standalone success template offers Home, FAQ and Pricing, but no order return. Its use by each provider is unverified.
Proposed: chosen eSIM → amount and visible total → payment → pending/credited status for that same eSIM → balance or explicit return.
Preserve identity and amount until outcome is understood. Acknowledge Processing separately from credited balance; avoid implying settlement is final solely because an event arrived. Recheck without asking the user to reconstruct the form. Validate complete identifiers and distinguish invalid input from service failure; repeated requests during typing add avoidable noise.
Recovery: retain a transaction reference and expose its real state. Current top-up does not save its invoice/token for the shared legacy polling mechanism, so purchase-style Resume/Create invoice recovery cannot be claimed here.
05 · Keep the number
Observed: renew.js · initRenewForm / loadData; order.js · RenewBtn; renew.ejs
Renew passes the number in the URL and prefills from storage. Lookup shows current expiry and price; payment events reload the lookup. There is no explicit before/after confirmation or return to the original order. Lookup failure only marks the field invalid; submission failures are all described as an invalid number.
Proposed: chosen number + current expiry → price → payment → pending or confirmed new expiry → optional return.
Keep the prefill that already exists. Show old and new dates together after confirmation; customers checking an expiry need not be forced back to the order. Preserve the number and use a visible retry for service failures.
Recovery: verify payment status before inviting another attempt. Interrupted renewal has the same missing transaction persistence as top-up. A disconnected/reused number is a service-policy question; do not promise that paying can restore it.
06 · Buy several eSIMs
Observed: bulk.js · initBulkPlans / continueBulkCheckout; order.js · renderOrder / finishOrder / initOrderControls
Quantity and balance update totals and delivery wording. Bulk payment method is selected on the bulk plan card, then auto-opened on the order page; it is not a second choice on that page. Any returned bulk record calls finishOrder, even if status is processing, stopping polling and hiding status actions. Download remains available with an incomplete-order confirmation.
Proposed: quantities and delivery expectation → payment → completion status → complete CSV, with clearly labelled partial export if needed.
Keep progress updating and provide retry/support without restarting a paid order. Do not disable Refresh as the earlier review suggested. Do not remove partial exports without learning how bulk customers use them. A CSV navigation/download error has no dedicated recovery UI in the order template.
Recovery: preserve the same order and offer retry for download failure. API availability for progress and readiness, partial-export meaning and bulk users’ needs must be confirmed.
07 · Coverage and help
Observed: rates.js / rates.ejs; faq.js / faq.ejs; header.ejs / footer.ejs
Pricing has separate country selectors for two plan families, reset on page initialisation. There is no explicit plan/destination handoff back to buying. FAQ, Pricing and support are independent branches, not four mandatory successive screens. FAQ hash opening exists on initial page load.
Proposed: question or destination → relevant answer/rates → resume the original task; support only when needed.
Use country once across comparison, retain the relevant plan and link to the appropriate FAQ answer from the task. Retain manual family/country changes. Fix the content gaps recorded below before adding new navigation.
Recovery: a rate-loading error needs retry and useful fallback; an unanswered question needs actionable contact. Do not automatically send private order links to support. External wallet recommendations and destination availability were not evaluated in this local research pass.
08 · Interrupted payment
Observed: order.js · updatePaymentState / handleOrderError / scheduleCheck; storage.js; successpurchase.ejs
Same-session New invoices can resume. Paid/processing/settled states move to preparation and automatic checking every ten seconds while pending. Only one pending checkout record is stored per session; a later checkout can replace it. Without the matching record, an unpaid order may repeatedly show “still pending” without a payment action. Expired/invalid invoice states have no replacement flow.
Proposed branches: payable → resume existing invoice; paid → wait/check fulfilment; verified expired/unpaid → safe replacement if supported; unknown/unavailable → retry status or support.
Do not infer nonpayment from a closed window or slow callback. Unknown, partial/late-payment, failed and expired states need explicit agreed outcomes before offering another invoice. Show time expectations only when supported by service evidence, and give escalation rather than endless “check again”.
Recovery: support resuming from the order identity where authorised, without depending only on the originating tab. The legacy purchase-success page already supplies an automatic redirect and Continue link when its script runs; avoid inventing another confirmation page. With script execution unavailable its placeholder is not a working fallback.
What this research establishes—and what comes next
All eight journeys now have an evidence-backed baseline, proposed shorter path, recovery review and priority. The remaining work is validation of proposals and external dependencies, not an unfinished pass through the map.
Before approving detailed UX
- Payment/backend owner: agree authoritative invoice and fulfilment states, late/partial/duplicate payment handling, replacement rules, top-up/renewal return contracts, bulk progress, and safe order-link recovery. No backend work was performed.
- Support owner: review anonymised categories for lost links, post-payment non-return, install trouble and wrong-SIM confusion; confirm available recovery evidence and response expectations. No messages sent and no support data accessed.
- Device research: verify current official installation options for supported iOS/Android devices and plan restrictions, then test same-phone and second-device setup. No claim of one-click compatibility is made here.
Proposed usability study
Start with 5–8 formative sessions spanning new crypto/eSIM users, returning customers and at least one bulk customer. This is a discovery sample, not a statistically representative benchmark. Include laptop touchpad/keyboard and physical phones. Use safe prototypes or mock payment states, not real charges.
| Task | Conditions | Evidence to record |
|---|
| Choose a plan for a destination and start payment | Compare families; fee/minimum adjustment; plan data fails once | Actions, repeated country entries, time finding full price, unaided retry |
| Recover a checkout | Close/reload; fresh session; second checkout; expired, unknown and paid-but-pending states | Correct next action, no duplicate payment attempt, status comprehension, support route found |
| Top up and renew the intended SIM | Two order tabs; cleared storage; invalid and failed lookup; delayed payment | Correct SIM/number, fields re-entered, returns/searches, recognition of confirmed balance/expiry |
| Install and find relevant help | Same phone; another device; copy fails; no connection | App switches, time to useful instruction, successful fallback, no inappropriate reinstall advice |
| Retrieve bulk purchase and lost order | Partial/processing result; download fails; no saved link or reference | Understanding partial export, progress checks, successful retry or actionable escalation |
Compare current/proposed prototypes with the same start/end states and balanced task order. Measure active task time separately from settlement/fulfilment waits; record completion, missteps, repeated entry, backtracking and confidence. Report observed differences and sample limits, not assumed savings. Keep access URLs, activation codes and customer identifiers out of research logs.
Proposed acceptance criteria: every blocked state has a useful next action; no new payment is suggested while previous status is unknown; identity survives top-up/renewal; users can distinguish pending from complete; all visible help controls lead to content; core controls work without hover or a mouse. These criteria are targets, not test results.
Document validation
The research HTML and linked flow-map annotations are checked separately for readability, working internal links and layout across desktop/phone browser profiles. All six cases passed 14 checks each: chromium 153.0.8010.12, firefox 155.0, webkit 26.6 at desktop 1440×900 and emulated phone 390×844. Checks covered research links, eight annotations, retained flow tabs, page overflow and uncaught exceptions. Those checks do not validate the product journeys, physical phones or payment integrations.