ESP

ENG

Zone Pricing Seats

End-to-end redesign of seat selection pricing for a bus travel platform

2 Design iterations, refined using real using data

Faster Checkout at the seat-selection step after V2 shippedΒ 

Year

2026

Role

Lead Product Designer

Tools

Figma | Hotjar | Claude | Mixpanel

About This Project

Zone-based seat pricing was a redesign of how a bus travel platform showed seat prices β€” moving from a single “starting price” to a transparent, zone-based system, driven by both a user pain point and a business need to introduce revenue management.

A number that changed the moment you picked a seat.

Where the Price Stopped Making Sense

The schedule list showed a starting price β€” “from S/75” β€” but that number only ever applied to the cheapest seat on the bus. By the time a user picked a seat on the upper floor, the price had quietly become S/90. Hotjar recordings showed people clicking between seats repeatedly, visibly hunting for the “right” price, and the client was fielding direct complaints about it.

At the same time, the business was rolling out a revenue-management strategy that priced seats by zone β€” with no way to communicate that to users without it feeling like a bait-and-switch. A user problem and a business need, pointing at the same redesign.

Looking Outside the Product

Two mental models for pricing by seat.

Before designing anything, I looked at how airlines and ticketing platforms handle seat-based pricing.

Airlines lean on distinct colors per service tier β€” built for comparing packages, not raw price.

Ticketmaster uses a single hue, shading from light to dark, to signal price directly on the venue map. Our seats weren't different products β€” they were the same seat at a different price. That distinction shaped everything after.

When Feedback Doesn't Tell the Whole Story

Good reviews from the wrong room.

The first version leaned toward the airline model: five distinct colors, one per zone. Before shipping, we tested it with a handful of people close to the client's team β€” not actual end users.
They responded well, and we moved forward assuming it was solved.

Once it reached real users, Hotjar told a different story: people were still switching between seats, still confused. Metrics barely moved β€” the complaints we'd hoped to reduce hadn't really gone away. The problem wasn't the color system itself β€” it was who we'd validated it with. People who already understood the pricing logic internally weren't a stand-in for people encountering it cold.

Simplifying to What Actually Works

One color, one gradient, one clear signal.

With that lesson, V2 stripped the palette down to a single hue: darker seats cost more, lighter seats cost less.

Closer to the Ticketmaster model, simplified further since we didn’t need venue sections β€” just a clear price gradient, plus a running price breakdown by zone and passenger, visible before committing to a seat.

What Changed in the Numbers

Fewer complaints, faster decisions.

Complaints tied to pricing confusion dropped meaningfully after V1 shipped β€” but it was V2’s gradient that moved actual behavior: users completed seat selection measurably faster on average.

A small window of time on its own, but it was the exact step we were trying to unblock, and it held consistently.

What i learned

Positive feedback isn’t validation if it comes from the wrong user target.

The biggest shift in this project wasn’t a color choice β€” it was learning to distrust “it looks fine” from anyone who wasn’t the actual end user, and to wait for real usage data before calling something solved.