Selected work / 2026

MomenticketDesigning around a seat that expires.

ROLE
Product designer
TIMELINE
Spring 2026

A reservation countdown on every screen, from search to confirmation.

01Problem

A bus seat is not a search result. It expires while you book.

Momenticket sells cross-border coach tickets — Kyiv to Warsaw, Warsaw to Lviv — so a booking is not one choice but several strict ones. The route resolves to named terminals rather than cities. Passenger names have to be entered in Latin script as they appear in the document, because the coach crosses a border. And behind all of it a specific seat is held on a timer, so the flow is racing a clock that the person can see.

02Research

The hard parts were the states between the happy path.

  • Autocomplete has to disambiguate across borders. Typing three letters returns a Polish city, a Bulgarian one and a Ukrainian one, plus two separately named Warsaw terminals — so every result carries its region, its country and, for a station, what kind of station it is.
  • Passenger details are stricter than a domestic ticket: Latin script as in the document, one guaranteed seat each, and a seat map that only some coaches have. That pressure is what makes saved passenger profiles worth building.
  • Nothing is safe while the countdown runs, so every payment state has to answer two separate questions — what happened to the money, and what happened to the seat.

03Process

01 / Search — the route landing page arrives with the origin already filled, and the work sits in what follows: autocomplete that groups locations across three countries, date shortcuts and range selection, passenger controls, and errors a person can actually recover from.
01 / Search — the route landing page arrives with the origin already filled, and the work sits in what follows: autocomplete that groups locations across three countries, date shortcuts and range selection, passenger controls, and errors a person can actually recover from.
02 / Route selection — cards stripped back to what decides a purchase: departure, duration, transfers and price. The full breakdown stays one tap away, and on mobile the purchase bar is fixed so the price never scrolls out of reach.
02 / Route selection — cards stripped back to what decides a purchase: departure, duration, transfers and price. The full breakdown stays one tap away, and on mobile the purchase bar is fixed so the price never scrolls out of reach.

04 / Key decision & trade-off

Keep the countdown visible, even when the payment fails.

Rejected

Hiding the reservation clock during checkout. It reads calmer, and it avoids putting a ticking number next to someone typing their card details.

Accepted trade-off

A visible countdown is pressure, and on the failure screen it sits directly beside bad news. I kept it because the alternative is worse — a seat that quietly disappears while the person is still trying to pay. So the failure state answers both questions at once: the money was not taken, and the seat is held for twelve more minutes.

05Final solution

A form that cannot dead-end, and a checkout that keeps the seat.

Two flows carried this project. In the search form almost all the design work was in states and validation rather than layout. In the booking flow it was in failure — what the screen says when money and seat can move independently of each other.

A transparent path from passenger details to payment.
A transparent path from passenger details to payment.
Every outcome gives users a clear next action.
Every outcome gives users a clear next action.

Checkout runs as three visible steps with the price held in context and no forced registration, then every payment outcome resolves to a clear next action — verification that tells you not to retry, failure that confirms the money was not taken and the seat is still held, and success that offers the account with the bonus it would have earned.

06Outcome

Reflection

The handoff file is unusually complete — flows, states and error strings are specified, and the search form has written documentation behind it. What it does not contain is measurement, so the outcome tiles stay empty until the team supplies live figures. Reviewing it also surfaced small copy defects worth fixing before build: the error under the destination field asks for a departure city, passenger count appears as «пассажир», «квиток» and «Пасажири» across three screens, and «Гарантоване» and «дані» are misspelled on the passenger card.