Umair Yahya
All work

One journey skeleton carried a bank’s travel platform across four verticals and two languages.

TravelShop, 2025 to 2026. A white-label travel platform for one of Egypt’s largest private-sector banks: flights, hotels, car rentals and experiences, paid with the bank’s cards, reward points, or both.

Travel Shop

    What the happy path doesn’t show

    • ArabicThe layout mirrors. Card and phone numbers don’t.
    • Free bagThree a year, counted per traveler.
    • Split paymentCard and points in one payment.
    • Price changedThe new total beside the old one.
    • Session expiredBookings and saved details stay safe.
    • Bag benefit failsThe back office follows up.

    12 booking states and 25+ edge cases, designed before launch. The ones in this demo light up as you reach them.

    Book a flight in English or Arabic. The model compresses the flight path into six screens, built from the real ones.

    Role
    Lead Product Designer, through an agency. August 2025 to June 2026, remote with the bank’s teams.
    I owned
    The customer shop on web and mobile in English and Arabic, the operations portal, the emails and vouchers, and one design system.
    Worked with
    The bank’s engineering, compliance, loyalty and finance teams, two flight suppliers, a hotel supplier, and car and experience providers.
    Shipped
    Flights and hotels, live to real customers in four months. Verified.

    Points that nobody could spend.

    Cardholders built up reward points with few ways to use them. Every unredeemed point was a growing liability for the bank, and its most valuable customers booked their travel somewhere else.

    The answer was a travel shop inside the bank’s own secure environment, paid by card, by points or by both. It was not a consumer travel site. It was white-label and API-first, so other banks could rebrand it with their own loyalty rules, card benefits and suppliers. Two products shipped together: the customer shop, and a portal for operations, support, finance and loyalty.

    • Several suppliersEach returned different data. The primary flight supplier changed mid-project.
    • Three ways to payCard, points or a split, with the conversion done for the customer.
    • A benefit that might not applyThe free bag could be granted, already included by the airline, or rejected.
    • Payment before ticketingMoney could clear before the airline issued the ticket.
    • Two reading directionsEnglish and Arabic at full parity, with every string reviewed by the bank.

    When the flight supplier changed, I ran joint workshops with the bank’s engineers and the new supplier’s technical leads to map the new API and agree on the revised journey. The launch stayed on schedule.

    Four months, so the research was a benchmark.

    A launch date four to five months out ruled out a full discovery phase. I benchmarked more than 10 travel products instead, chosen for mobile quality, Arabic maturity and relevance to a bank customer in Egypt, and recorded what to borrow, what to reject and why.

    Borrowed

    • Google FlightsSpeed and calendar pricing
    • AlmosaferThe closest reference for Arabic-first flows

    Rejected

    • Expedia, WegoClutter and ad weight
    • Booking.com, AgodaCrowded mobile flows

    Six things could not change: the launch date; desktop replacing mobile as the launch target on short notice; brand guidelines enforced down to color and tone; supplier reality, with incomplete fare rules and slow price checks; banking rules reviewed by compliance; and full Arabic parity. The benchmark gave every module the same patterns, and those made the first decision possible.

    Six decisions that shaped the product.

    Each came with a cost, and each was decided with the people who would live with it. The piece beside each one works.

    One journey skeleton for every travel vertical

    Chose
    One structure every vertical inherits, from search to after booking. A customer who learns flights already knows hotels, and a new module inherits the pattern instead of inventing one.
    Instead of
    Designing each vertical around its own supplier’s data: separate products under one logo, and several times the work against the deadline.
    Decided with
    The bank’s product and engineering teams, who agreed on the structure from low-fidelity wireframes before any visual work.

      One design system, configured for two typefaces and two directions

      Chose
      Typography as a token layer in one system. The brand set one typeface for mobile and another for desktop, and Arabic needed its own. Each became a configuration of the same components, which is also what the next tenant needs.
      Instead of
      A design system per platform: double the maintenance, and guaranteed drift under deadline pressure.
      Decided with
      The owners of the bank’s brand guidelines, and engineering, who implemented typography as tokens.

      The component never changes. Only the token values do; orange marks the ones that moved. The typefaces stand in for the bank’s mandated ones.

      The real flight details header, from the same components in English and in Arabic.

      The free baggage benefit, designed for partial failure

      Chose
      Describe the benefit as value, apply it when possible, and give a clear fallback. The confirmation and the email say exactly whether it was applied, and a structured claim lets the customer recover the cost.
      Instead of
      Showing the benefit only when it could be guaranteed, which buries the perk, or always promising it and cleaning up in support.
      Decided with
      The bank’s loyalty and compliance teams, with the flight supplier’s rules setting what could be guaranteed. No part of the project took more rounds with the bank.

      A model of the three confirmation variants. Wording is simplified from the real screens.

      A module-first operations portal, not one portal per role

      Chose
      Each capability designed once as a master module, then tailored per role through permissions: navigation, columns, tabs, actions and exports.
      Instead of
      A separate portal for each of the five roles, drifting apart and multiplying every future change.
      Decided with
      Bank finance and loyalty, platform operations, customer support and tenant admin.

      One bookings module, seen by four of the five roles. Columns and permissions are simplified to show the principle.

      The real bookings module in its master version, shown with sample data.

      Honest labels over optimistic ones

      Chose
      Where the system could not change a booking automatically, make it a request: an eligibility check, a structured form, one active request per booking, and a status the customer can follow.
      Instead of
      A button that looks like an instant edit, quietly backed by manual work.
      Decided with
      Operations and customer support, who own the manual workflow behind the request.

      Switch the label to see what each one promises. The steps follow the shipped request flow.

      Loading and uncertainty designed as content

      Chose
      Three stages: standard, extended, and failure with a way forward. When the price moves, a dialog shows the old and new totals, so the customer can accept or search again.
      Instead of
      A spinner until timeout. In travel, silence during a delay feels like something has gone wrong with your money.
      Decided with
      Engineering and the flight supplier, whose price revalidation timing set the three stages.

      Pick what the supplier does, then continue to payment.

      The real price update dialog: the new total, the previous total, and two ways forward.

      Failure states are journeys, not exceptions.

      Before launch, 12 booking states and more than 25 edge cases were designed, not discovered in production. Each has a clear title, a plain explanation and a next step.

      11 of the 12 named states in the shipped lifecycle. Each card summarizes what the customer is told.

      The shipped session-expired state: it says why, confirms bookings and saved details are safe, and lists what happens next.

      Arabic, designed rather than translated.

      Because typography was a token layer, Arabic was a configuration of the same system, not a second one. It still needed its own rules, and terms such as refundable and points redemption were translated for their legal and financial meaning.

      Mirrors

      • Navigation, tabs, breadcrumbs and steppers
      • Back and forward chevrons, carousel direction
      • Filter rails, list markers, checkmark placement
      • Calendar grid and date picker flow
      • Alignment, defined as start and end

      Does not mirror

      • Logos and wordmarks
      • Clocks, timers and media controls
      • Phone numbers and card number grouping
      • Airport codes and Latin brand names in Arabic text
      • The chevron and checkmark glyphs themselves

      The hard cases live in mixed strings: Latin airport codes inside an Arabic sentence, currency placement, truncation direction and weekday order. Passport lines, card numbers and email addresses stay left to right inside right-to-left forms.

      Flight results at full parity in both directions.

      The rest of the product, on the same structure.

      Hotels turn supplier board types into five plain meal plans. Car rentals show the daily price, deposit and insurance up front. When points fall short, the split becomes the default, with the breakdown shown.

      The mobile flight path: results, details and confirmation.
      Experiences on the same skeleton, with a split payment of points and card.

      What shipped, and what I would change.

      • VerifiedFlights and hotels went live to real customers in four months, inside the bank’s deadline.
      • VerifiedThe platform passed supplier certification, including the hotel supplier’s formal API sequence. An external gate, not a self-graded one.
      • VerifiedThe bank extended the scope after launch, and the contract ran its full term.
      • VerifiedA second tenant, with its own card benefits and branding, was set up mainly through configuration.
      • Internal testA booking took 5 clicks on average from search to confirmation, against 9 to 12 on leading competitors.
      • ReportedSeveral test users said they could complete a booking on their own, a first for the bank’s travel products.

      What I can claim

      The structure, the system and the states, and the launch they made possible. Without production analytics, conversion, revenue and support effects stay unmeasured.

      What I would do differently

      Push for research with real cardholders before finalizing the flows. The benchmark was right for the deadline, but more validation would have saved later iterations, above all on the baggage benefit.

      What it taught me

      In live-inventory products, the error, pending and recovery states carry more trust than the happy path. And supplier data should never dictate the interface: the layer that translates it is the product.

      Verified on the record: a live product, a public page or a project document. Internal test measured by me or the team, outside production. Reported someone told me; I have not seen the data.

      Building something harder than it looks?

      Open to Principal and Lead Product Design roles, in Dubai or remote.

      umairyahya48@gmail.com

      LinkedInResume