When I joined Pingotrip, there was no name, no identity, and no product — just an ambition to compete in Iran’s online travel market. Over two years I built the brand from scratch and led product design across five transactional services: flights, hotels, tours, a B2B portal, and an internal back-office.
Product Design Lead — Pingotrip
Pingotrip: Turning a Blank Slate Into Iran’s Full-Stack Travel Platform
My Role
- Product Design Lead, sole design decision-maker
- Owned brand identity and end-to-end product design
Team
- One design partner I mentored into an independent contributor
- Partnered closely with Pingotrip’s product owners on strategy and scope
Platform
- Web only
- No native app
Timeline
- ~2 years
- Zero to full platform
Project Type
- 0-to-1 brand and product build
- Multi-service transactional platform
Domain
- Online Travel Agency (OTA)
- Iran
Key Impacts
- Flight, hotel & tour booking
- B2B and back-office panels
Tools
- Figma (design & prototyping)
- Notion (specs & documentation)
What I Did
- Named the company and designed the full brand identity — verbal, visual, logo, tone of voice, and archetype — from a blank slate.
- Designed five transactional services end-to-end: flight booking, hotel booking, tours, a B2B portal, and a back-office panel.
- Defined a human-centered design philosophy — simpler, warmer, more conversational — as the platform’s real point of difference from other OTAs.
- Built a proprietary design system shared across all five products so a two-person design team could ship at speed without the platform feeling stitched together.
- Mentored a junior designer into an independent, capable partner over the two-year build.
What changed
- Checkout completion rate held above 8% platform-wide, with a +1.55 point lift after the booking flow redesign.
- 340,053 unique users and 407,278 sessions tracked across ~18 months of behavioral data.
- Interface-health tracking showed zero rage clicks in 99.52% of sessions and zero dead clicks in 85.75% — a directly measured, not self-reported, low-friction experience.
- Roughly 6% of bookings are repeat purchases, notable for a two-year-old platform up against OTAs with a decade of brand recall.
- Sessions ending in a completed purchase scrolled ~91% of the page on average — nearly 3x deeper than casual browsing.
Why it matters
Pingotrip couldn’t out-feature OTAs with a decade of head start — matching their functionality was never going to be enough. The one lever actually available was to feel more human than they did: warmer tone, simpler flows, colloquial Persian copy. Every decision in this case study pulls that same lever, and it’s a large part of why a young platform built a loyal repeat-booking base faster than its short history would suggest.
End of TL;DR⊛
End of TL;DR⊛
End of TL;DR⊛
End of TL;DR⊛
End of TL;DR⊛
End of TL;DR⊛
End of TL;DR⊛
End of TL;DR⊛
The rest of this case study walks through how the flight and hotel booking flows were actually built — the constraints that shaped them, and the decisions that didn’t have a clean answer.
What Was Broken?
01
Zero Brand or Product Foundation
Pingotrip had no name, no visual identity, and no live service when I joined. Every early decision — from the logo to the first booking flow — had to be made without an existing product to react to.
02
Fragmented Multi-Service Inventory
Flights, hotels, and tours each run on different provider APIs with different inventory rules and failure modes. The product had to feel like one platform, not five disconnected tools stitched together.
03
Feature Parity Isn’t Trust
Pingotrip was never going to out-feature OTAs that had existed for a decade. Matching their functionality wouldn’t be enough to earn a first booking from someone who’d never heard of the brand.
The Goal
Turn a blank slate into a travel platform people trust enough to pay through.
The goal was never to out-feature bigger, older competitors — matching their functionality wouldn't earn trust on its own. It was to make Pingotrip feel like a knowledgeable, warm, familiar friend: simpler flows, a human tone of voice, and a visual identity built around Iranian users, not translated from somewhere else.
Zero to One
Human-Centered by Design
Flights · Hotels · Tours · B2B · Back-Office|
Flights · Hotels · Tours · B2B · Back-Office|
Flights · Hotels · Tours · B2B · Back-Office|
Flights · Hotels · Tours · B2B · Back-Office|
My Strategic Framework
With no existing product to inherit, I made three bets that shaped every downstream decision — and the first one mattered more than the other two combined.
Bet One
Design for warmth, not just usability
Pingotrip couldn’t win on features against OTAs with years of head start, so I optimized a different axis: simpler flows, a conversational Persian tone of voice, and an orange-led identity chosen deliberately for warmth over corporate blue.
Bet Two
One design system, not five different products
Every service draws from the same component library and interaction patterns. That consistency is what let a two-person design team ship five services without the platform ever feeling stitched together.
Bet Three
Design around real inventory constraints, not ideal ones
Airline and hotel inventory locks, seat holds, and API limitations shaped the UX from day one. I designed the interface to make those constraints legible to the user instead of hiding them.
Craft & Consistency
One Design System, Five Products
Flights, hotels, tours, the B2B portal, and the back-office panel all had to ship fast, with a two-person design team and no room to redesign shared patterns five separate times. So one of the earliest investments was a proprietary design system — not a generic UI kit, but components, tokens, and interaction patterns built specifically for Pingotrip’s own booking logic.
- A shared component library covering search, cart, forms, and payment states across every service
- One color, type, and spacing token set — including the countdown-timer and price-transparency patterns reused between flights and hotels
- Consistent motion and microinteraction rules, so a confirmation animation in the hotel cart behaves the same way it does at flight checkout
- A single accessibility and tone-of-voice standard applied across five otherwise very different products
Decisions, Failures, and Surprises
How It Played Out
The flight and hotel booking flows carry the platform’s core transaction volume. Each decision below went through real critique and iteration before it shipped — not a first idea turned straight into a screen.
One Search Widget for Every Service
Pingotrip needed a single entry point for flights, hotels, tours, and visas — not four separate search experiences competing for the same homepage real estate.
Hypothesis
If every service lived behind its own search form, users would default to whichever one they landed on first and never discover the rest. One searchable surface with service tabs would keep the whole catalog visible.
What I Built
A tabbed search widget — domestic/international flights, hotels, tours, and visas as tabs on one component, anchored at the top of the homepage and results pages.
Surprise
The widget became the de facto navigation for the whole site — users switched services mid-session through it far more than through the main nav, which changed how I prioritized its placement on every page template.
What Didn’t Work
An early version crammed all filters into the widget itself. It got cluttered fast — filters moved to the results page, and the widget stayed lean by design.
Killing the Multi-Tab Price Check
Flight shoppers habitually opened several browser tabs with different dates just to compare prices — a workaround for a feature the product didn’t have.
Hypothesis
If the results page showed price movement across nearby dates directly, people would stop leaving the page to price-shop manually.
What I Built
A horizontal price calendar above the results list, color-coded from cheapest to most expensive across a rolling date range, so a date change was one tap instead of a new search.
Surprise
Users adjusted their travel dates far more often than expected once the calendar made the trade-off visible — date flexibility was undervalued as a lever until the UI actually offered it.
What Didn’t Work
On narrow viewports, the calendar’s real value — seeing the whole price curve at once — mostly disappears when compressed to a few visible days. Mobile shows a shorter window and leans harder on the color coding.
Saying the Quiet Part Before Checkout
Price shock at the payment step is one of the most common reasons a travel booking gets abandoned — taxes, fees, or fare rules that only surface on the last screen.
Hypothesis
Naming the exact pricing behavior early — a “here’s what you should know” banner — would reduce the number of people who bailed out at payment feeling misled.
What I Built
A plainly worded price transparency banner shown before payment, stating exactly what’s included in the fare and what could still change, like fare-class-dependent refund rules.
Surprise
Support tickets about “unexpected” charges dropped noticeably after this shipped, even though the underlying pricing logic never changed — only the framing did.
What Didn’t Work
An earlier draft used generic reassurance copy (“no hidden fees!”). It had no measurable effect on drop-off — specificity is what made the banner work.
Designing Around a Seat Hold You Don't Control
Airline APIs only hold a selected fare for a limited window before releasing it back to inventory — a hard technical constraint, not a design choice.
Hypothesis
If the countdown was visible and honestly worded, users would move faster through the passenger-info step without feeling ambushed when a hold expired.
What I Built
A persistent countdown timer during passenger info and payment, paired with copy that explains why the hold exists rather than just showing a bare number ticking down.
Surprise
Without the explanatory copy, an early version of the timer alone increased abandonment — users assumed it was a manipulative urgency tactic until the wording made the real constraint explicit.
What Didn’t Work
The same timer logic later had to be adapted for hotel bookings, holding multiple rooms at once instead of a single seat — a different technical problem needing the same honest framing.
A Cart, Not a Single Selection
Hotel bookings aren’t always one room — a family might need two double rooms and one single, in varying quantities, in a single reservation.
Hypothesis
Forcing a linear, one-room-at-a-time selection, like the flight flow, would break down the moment someone needed more than one room type. Hotels needed genuine cart logic.
What I Built
A cart-based room selector where users add multiple room types and quantities before checkout, with a sticky sidebar summarizing the running selection and total at every step.
Surprise
Guest-info entry became the real friction point once the cart worked — filling out passenger details separately for every room in a multi-room booking was tedious enough to need its own fix.
What Didn’t Work
Early cart versions let the running total update silently. Adding visibly animated, real-time price feedback on every add/remove mattered more than the cart logic itself for user confidence.
Not Making Someone Fill the Same Form Four Times
A multi-room cart meant a separate guest-info form per room — a pattern borrowed from established OTAs, but one that gets tedious fast without help.
Hypothesis
If most rooms in a booking share the same lead guest, letting people copy that guest’s info into other rooms with one click would remove the most repetitive part of the flow.
What I Built
A “use booking holder’s info” and “copy from first guest” shortcut on every room form, with immediate green confirmation feedback when a copy succeeds.
Surprise
The base pattern — separate forms per room — is standard across the industry, so it wasn’t the win. The smart-copy shortcuts and instant feedback were what visibly reduced complaints.
What Didn’t Work
Copied data still needs to stay individually editable. An early version locked copied fields, which caused problems whenever one room genuinely had a different guest than assumed.
The Trade-Offs
Decisions That Didn't Have a Clean Answer
- Timer honesty vs. urgency: Making the countdown timer explain itself, instead of relying on urgency alone, meant giving up a classic conversion lever — but it was the only version that didn’t read as manipulative once tested.
- Check-in/out request framing: Labeling early check-in/out requests as a “facilitator, not a guarantee” meant setting expectations lower upfront, trading a slightly weaker pitch for far fewer post-booking complaints.
- Cart-level vs. per-room timers: Running the reservation hold at the cart level, not per room, simplified the countdown UX but meant one slow guest form could put an entire multi-room booking at risk of expiring.
Navigating Real-World Constraints
For most of the two years, product design at Pingotrip meant a lean, deliberately agile team — myself and one design partner — working closely with Pingotrip’s own product owners and, most of all, with different parts of the development team, translating real technical constraints like API-driven seat holds into interface decisions. Every decision in this case study, even the small ones, went through real critique and iteration before it shipped; the interface-health numbers in the Results section below are a direct product of that discipline, not an accident. Shipping five interconnected services this fast, without the platform ever feeling stitched together, is the part of this project I’m proudest of.
Note: GMV, transaction volume, and other commercially sensitive figures are withheld here under an NDA with Pingotrip — the metrics in this case study are limited to what I’m permitted to share.
~2 Years, Zero to Platform
From Strategy to Rollout
There was no product to inherit and no backlog to work from — the sequencing below is roughly how the platform came together, service by service.
Months 1–3
Brand & Identity
Naming, verbal and visual identity, logo, and tone of voice — built before any product screen existed.
Months 4–9
Flight Booking
The first live transactional flow: search, results, passenger info, and payment.
Months 10–15
Hotel Booking
Cart-based multi-room architecture, guest forms, and hotel detail pages.
Months 16–20
Tours & B2B Portal
Extending the same design system to tour booking and a B2B portal for agency partners.
Months 21–24
Back-Office & Iteration
Internal management panel, plus ongoing refinement across all live services.
Measured Impact
Results
Metrics below are pulled from ~18 months of behavioral tracking (Microsoft Clarity) and internal funnel data since launch.
GMV and total transaction volume are excluded per an NDA with Pingotrip.
Primary Outcome
8
%+
Checkout completion rate
Held steady above 8% platform-wide, with a +1.55 point lift specifically after the booking flow redesign shipped.
Booking Flow Redesign
Reach
340
K
unique users tracked
340K+ users generated enough signal to trust behavioral patterns, not just anecdotes, when making design calls.
Loyalty
6
%
of bookings are repeat
Modest by subscription-product standards, but notable for a two-year-old OTA up against a decade of brand recall.
Interface Health
99.52
%
of sessions had zero rage clicks
85.75% of sessions also had zero dead clicks — a measured, not self-reported, low-friction interface.
Purchase-Session Depth
91
%
average scroll depth
Nearly 3x deeper than casual browsing — once someone commits to booking, the interface holds their attention instead of losing them.
Engagement
3.32
pages per session, platform-wide
Purchase-session averages ran far higher, often 6–12 pages per session.
Behavioral Shift
Checkout carries more friction than browsing does — and it shows in the clicks.
Positive click rate on top product pages averaged ~91% across the period tracked. On sessions that ended in a completed purchase, it dropped to roughly ~59% — a clear behavioral signal that checkout carries more friction and complexity than browsing does, even though scroll depth and time spent both went up. That gap, not a survey or a hunch, is the argument for continuing to simplify the payment and passenger-info steps.
Before / After
The User Journey
Before
- No brand name, visual identity, or live product
- No transactional service existed — nothing to book
- No design system, no shared patterns across products
- Zero user base to learn from
After
- Full brand identity — name, voice, visual system, logo
- Five live transactional services: flights, hotels, tours, B2B, back-office
- A proprietary design system reused across every product
- A design partner mentored into an independent contributor
Client Feedback
“Pingotrip went from a name on a whiteboard to a platform people actually book through — and design carried a huge part of that.”
{{testimonial_name}}, {{testimonial_title}}
