Booking a seat took six steps, and the discount rules only showed up at payment.
Vexere · Bus-ticket checkout. An independent discovery exploration.
- Role
- Independent exploration
- Year
- 2026
- Platform
- Mobile app, checkout flow
- Observed case
- One-way, Ha Noi to Sa Pa, one seat, 530,000đ
- Method
- Evidence audit, hypotheses, JTBD draft, prototype specs, test plan, decision rules
What eight observations can and cannot show
The screens show how the flow is built. They say nothing about how often it hurts anyone.
The brief lists eight observations, E01 to E08. E04 (six milestones after choosing a trip) and E07 (discount conditions differ by method and only surface at payment) carry the problem sentence above. The rest set limits on it.
| ID | Observation | What we can conclude | Still to confirm |
|---|---|---|---|
| E01 | The S Trip card shows a price, “From 530,000đ”. | A fare appears in the trip list. | Which option “From” refers to, and which components the price includes. |
| E02 | 530,000đ stays in the bottom bar through seat, pickup, drop-off and contact. | The interface already keeps the price visible through the flow. | How far people notice that price, and how far they trust it. |
| E03 | The seat screen carries a 450,000đ cabin label while the selected seat totals 530,000đ. The first video shows cabin types at different prices. | How clearly price maps to seat type and position needs assessing. | Which seat type the label belongs to, availability, and why the label still appears. |
| E04 | Six milestones after choosing a trip: seat, pickup, drop-off, contact, trip details, payment. | The current flow splits the task into six milestones. | Which milestone actually causes effort, errors or drop-off. |
| E05 | Contact details are pre-filled in the recording. | In the observed case, contact information was already there. | The experience of new users and of people booking for someone else; which fields are mandatory. |
| E06 | The person operating the app changes payment method, opens the voucher list and goes back several times. | There was one back-and-forth pass between options. | The motive: hunting for a better price, learning, trying features, or being stuck. |
| E07 | The MoMo offer asks for a code entered inside MoMo; the pay-on-board screen says the code does not apply. | Offers and methods carry different conditions, and apply in different places. | Current eligibility, limits, discount or refund mechanics, and whether they can be verified in advance. |
| E08 | The clip ends with a choice to stop paying or view details, and a seat-hold notice. No booking-confirmed screen appears. | The interface has a way back and a seat-hold mechanism. | What triggers an order or hold, the backend time limit, and the effect on people who only look at prices. |
Evidence boundary
The recording runs about 166 seconds. It is not a baseline for booking time: the clip never completes a booking and contains exploratory taps. There is also no ground to say the problem is confined to this route or common across all of Vexere.
Six steps, and the price conditions arrive last
After a trip is chosen, the task is split into six milestones. Where the effort or the errors sit is unknown.
- Choose a seatA seat map with cabin types at different prices. The bottom bar already shows 530,000đ.
- Choose a pickup pointA list of pickup points, sortable, with a search field.
- Choose a drop-off pointThe same pattern again, for the drop-off.
- Contact detailsPre-filled in the recording (E05). Not shown here, because the screen carries personal details.
- Trip detailsA review of the trip with policies and optional extras.
- PaymentVouchers, payment methods and the total sit together here. This is where wallet offers and their conditions appear (E07).
The price is visible from the start. What is not visible until the end is which discount actually applies, and where.
This is a hypothesis, not a finding. It needs behaviour and data before it can be written as one.
Four hypotheses, each with what would change my mind
Every hypothesis names the evidence that would support it and the evidence that would send the work elsewhere.
| ID | Hypothesis | Evidence that would support it | Evidence that would change direction |
|---|---|---|---|
| H1 | Discount conditions appear late, so people struggle to work out what they will pay. | People cannot settle the price before the contact step; they go back and forth because they do not understand the conditions; an early preview helps them understand correctly. | People already understand the cost early; they mostly switch method out of preference or because a wallet is unusable. |
| H2 | Separate pickup / drop-off and contact / confirmation screens create redundant steps, especially for people with details already saved. | Screens exist only to confirm; a merged version finishes faster without more errors. | Separate screens help focus; the merged version increases omissions or misreading. |
| H3 | Tying price to seat type is unclear, so people misread which option they chose. | People confuse another cabin's price, or cannot explain the price of their own seat. | People identify it right away; the problem lies in availability, amenities or other conditions. |
| H4 | People who only want to see the price get pushed too deep into the booking flow. | They must reach payment to compare cost, then leave or leave several holds behind. | They had decided to book before entering the flow; the hold mechanism does not get in the way. |
The same brief drafts two jobs to be done, comparing trips and booking one. Neither has been confirmed by interviews. It is also open whether price is the main deciding criterion, or sits behind departure time, location and how far the operator is trusted.
- Competing explanationsThe real price is wrong for the person, no seats left, an inconvenient pickup or drop-off, an uncertain itinerary, an offer that ran out, a technical error, or no payment method they wanted.
- If this holdsIf people understand the price but cannot find a suitable pickup point, the focus moves rather than carrying on trying to prove H1.
Two prototypes, each testing one hypothesis
A changes how price is shown and keeps the steps. B changes the steps and keeps price presentation. Neither has been tested.
Prototype A · Price and offers early Hypothesis
Tests H1 and H3 without merging any step.
What it changes
- A “View price and offers” entry on the trip card, and a cost breakdown for the selected seat
- Ticket price, extras, surcharges, direct discount and the amount payable at Vexere shown separately
- Payment method placed next to the offer it affects; wallet offers say where to act and what the conditions are
- A specific reason when a code cannot be used; price, seat and offer re-checked at checkout
What it keeps constant
- The six steps and their order
- Nothing unconfirmed is subtracted from what Vexere surely collects
Prototype B · Six steps into four Hypothesis
Tests H2, compared only against a version with the same price presentation.
What it changes
- 1. Seat. 2. Pickup and drop-off together, as two summary cards that open lists to edit. 3. Confirm trip, merging contact and trip details, with saved details shown for checking. 4. Payment, with method, offer and total in one context.
What it keeps constant
- Price presentation, identical to the control
- Selections persist when going back; no pickup or drop-off is pre-selected just to cut taps
- People without saved details still fill in the mandatory fields
Going from six milestones to four describes the design only. It is not a result. Scroll length, how often pickers are opened and missed fields are what B is checked on.
Understand the decision first, then test the interface
Three rounds, each able to say the focus was wrong. The decision rules are fixed before anything runs.
- Round 1: clarify the mechanismInterview people about a real recent booking and watch the current flow. Start with 6 to 8 people who recently searched for or booked a coach, new and returning, recruited by behaviour and not only people who abandoned over a voucher. This is a sample for finding problems, not for inferring rates.
- Round 2: test Prototype ACurrent flow against early price and offers, same number of steps. Alternate version order across participants, use equivalent tasks and price data with a known right answer.
- Round 3: test Prototype BSix steps against four, with the same price presentation. Check effort, scroll length, pickup and drop-off errors, and how easily details can be edited.
- Then an on-product experiment, if conditions allowFix the primary metric, guardrails, eligibility, window and minimum meaningful effect first. Sample size cannot be responsibly stated without baseline data.
| If the result is | The decision is |
|---|---|
| People understand price better, bookings rise and guardrails hold | Consider a rollout within the scope that was verified. |
| People understand price better but bookings are unclear | Weigh the informational benefit and the confidence interval. Do not claim a conversion gain. |
| Fewer actions but more pickup or drop-off errors | Fix the structure, or keep the step separate where errors occur. |
| Bookings fall after prices become more transparent | Check booking quality, price expectations and attribution. Do not blame the UI yet. |
| People mainly struggle with schedule, seats or places | Reframe the problem and research that opportunity. |
The primary on-product metric counts only a booking the backend has confirmed, never a CTA click or a held order.
- Measure whether people understood the price separately from whether a quote rendered. Showing a quote does not prove it was understood.
- Report time to accurate price as median and P75 for those who reach it, and report how many do not. Do not drop failures.
- Guardrails: corrections and cancellations caused by wrong details, price complaints, payment errors, abnormal seat holds.
- Keep behaviour-based events when screens are merged, so pickup, drop-off and contact stay comparable between six steps and four. Event names in the brief are proposals, not confirmed tracking.
- Do not use AI-simulated passengers as research data. Where data is missing, a hypothesis or a plan to collect more is the only valid output.
What stays open
This is a plan and a specification. The checklist of confirmations is still unticked.
- A product manager confirms the business goal and pilot scope.
- Engineering and operations confirm price rules, offers, seat holds and booking states.
- Data confirms tracking and a baseline.
- Research with real passengers, then update the JTBD and the problem statement.
What this exploration does not claim
It does not claim the problem is widespread, that people drop out at payment, or that either prototype saves time or raises conversion. Nothing has changed in the Vexere app, and no runnable prototype or test result with passengers exists. The 166-second recording is not a booking-time baseline. The price of 530,000đ and the six steps describe one observed case, Ha Noi to Sa Pa, one seat. A 20,000đ discount seen in a wallet advert is not assumed: its conditions, quota and mechanics are unconfirmed. The discount in my redesign screens uses fictional data.
Seek Discomfort!
Ready to collaborate? Tell me what you are building.
vuhm.work@gmail.com- Phone
- (+84) 92 7474 800
- Open
- Monday to Friday, 9:00 to 18:00