Case studyProduct design, concept

- Winning the return ticket at checkout

Most travellers book the bus out and leave the way back for later. About a quarter of the travellers I surveyed had booked it on another app. I redesigned the moment RedBus asks about the return, so it can be booked in the same checkout, without a date.

Role

Product designer, solo, self-initiated

Timeline

4 weeks

Platform

RedBus iOS app

Tools

Figma, Claude Code

Watch the prototypeOpen it full screenSee the research boardSee the deck

The problem

The only way to keep a return on RedBus is to buy it, and buying it needs a date. ~74% of travellers I surveyed left it for later.

What I designed

A return you can book without a date. Say how sure you are, pick a day from your window, and move it once if plans change.

Why it matters

Every return booked later is a second commission RedBus can lose. ~26% of the travellers I surveyed had booked a later return on another app.

The prototype, on video

I understand the time constraint, so here’s the whole flow in two minutes.

If you’d rather watch than read, start here. Tia books a bus to Nainital, keeps a return without knowing the date, and moves it when her plans change. It’s recorded from the working prototype, so every tap is what the prototype does.

Tia, bookingTia is booking a bus from Delhi to Nainital for Thursday

Want to use it yourself? Open the prototype, with all 38 screens and 13 states.

Act 1The problem

The return that never gets booked

It starts with one traveller and a ticket she couldn't move.

Tia

Tia booked her return early once. Never again.

Her plans moved and the ticket couldn't. "We regretted it," she told me. Now she books a day or two before and ends up at the back of the bus, where she gets motion sick.

The way out

Delhi → Nainital

Thu, 10 Sep, 23:55, Seat U4

Booked

The way home

Nainital → Delhi

Some day next week. Maybe.

Not booked

The pattern

Most people wait to book the return. Nobody forgets.

I interviewed 8 travellers and ran a survey with 61 responses, 23 of whom had taken a round trip by bus. Every late booking was a choice.

~74%
booked the way back later
0%
forgot
~65%
weren't sure of the date
~26%
ended up booking on another app
Google Forms pie chart, 23 responses: how did you book the two legs? 73.9% booked the outbound first and the return later, 13% booked both together, 13% took the bus only one way.Google Forms bar chart, 23 responses: what made you wait? Not sure of my exact return date 15 (65.2%), plans depended on other people 11 (47.8%), hoping the price would drop 6, worried about cancellation 6, preferred seats or buses 5, usually book together 5, not sure I'd come back by bus 4, forgot 0.Google Forms bar chart, 23 responses: what did you notice when you booked the return later? Preferred seat gone 9 (39.1%), prices had gone up 7 (30.4%), booked on a different app 6 (26.1%), nothing changed 6, can't remember 5, preferred bus full 4.Google Forms pie chart, 23 responses: did you know about FlexiTicket and the cancellation add-on? 39.1% knew about neither, 30.4% knew both and used them, 21.7% knew but never used them, 8.7% knew one.

Survey figures are out of those 23. The charts are the form's own, from its responses page.

What RedBus has

The fix already exists. It's a badge on a bus.

FlexiTicket lets you change your date for free. You meet it on a bus card, never when you decide about the return, and ~39% of my survey had never heard of it or the add-on.

The same promise, as a badge on one bus

a property of the bus, not a way to book

10% off the return, on some buses

and people still book it later

The live RedBus bus list: a FlexiTicket banner, a Free date change badge on one bus, and a 10% return deal.

FlexiTicket: free date change

a banner and a filter, on the bus list

The live RedBus app, August 2026.

Why not FlexiTicket

So why not just use FlexiTicket?

It is FlexiTicket underneath. I didn't add anything it can't already do. But FlexiTicket only helps once you've decided to book, and to reach it you first have to enter a date. The people I was designing for didn't have one.

39.1%

of travellers said that even with a fixed return date, they still book it separately

"I know there is an option but I just prefer okay this option doesn't exist"

Anand, who knew FlexiTicket existed

The app used to ask for a "Date of journey". Now it asks "When can you travel back?"

The knot

The rules made waiting the safe choice.

Staying flexible means juggling seven rules across two products. One of them cancels the other, so people keep their options open by booking nothing.

FlexiTicket

free, on some buses

  • Change the date once
  • Pay the difference if it costs more
  • Nothing back if it costs less
  • Up to 8 hours before

Free Cancellation

₹60 per passenger

  • Cancel for a full refund
  • Up to 6 hours before

Change the date, and the ticket can never be cancelled.

The Free Cancellation you paid for is gone too. RedBus's own help page says so.

Why RedBus should care

A return booked later is often booked elsewhere.

Winning the return inside the first booking is cheap. Losing it is a whole second ticket gone.

~26%

booked it on another app

For RedBus, waiting often means losing the return.

2×

commissions, one booking

A return added now costs nothing extra to win.

Free Cancellation sales

The risk: a movable return might replace the add-on.

The limits

I couldn't hold a seat, set a fare or change a rule.

Someone who doesn't know their return date has no way to hold a return on RedBus. Since RedBus sells other companies' buses, I could only change what the app asks and when.

FlexiTicket's rules, as they are

  • One change, ever
  • Pay the difference if the new day costs more
  • Nothing back if it costs less
  • No cancelling after a change
  • Change up to 8 hours before

My own limit: with the new step, finished outbound bookings must stay at 95% or more of what they are today.

Act 2The design

The return, inside the checkout

Here's Tia's next booking with the new flow. Every scene is a screen from the working prototype.

Scene 1Booking the way out

She books her bus out. Before she pays, the app asks about the return.

How do you book a day you don't know? You say so. It opens on "I'm not sure yet", the answer ~65% of my survey gave.

Opens on "I'm not sure yet"

people who know their date lose one tap

Hi-fi return calendar with 'I'm not sure yet' selected and a fare under every day.

Every day shows its fare

the cheapest bus that can still change date

Scene 2Picking a day

She marks the days she could come back, then picks one.

How does she choose without comparing thirty buses? The days stay a short list, and her bus opens right under the day she picks.

The days stay a fixed list

whether a day has 2 buses or 30

Hi-fi day list with Thu 17 Sep picked and the recommended bus open under it.

Her bus sits under her day

with the ones that beat it on price or rating

Scene 3Before paying

She sees the one catch before she pays.

One change, to any date. The only line in warning colour is the one that costs her: no cancelling after a change.

One change, to any date

she pays only the difference

Hi-fi review screen with the Free date change card: one change, and 'You cannot cancel it after that' in red.

The only warning on the page

no cancelling after a change

Scene 4A week later

Her plans move, so she moves the ticket.

What will it cost? Every day on the calendar says. The new bus stays with the same operator, as RedBus requires.

The rule, before the choice

once she changes, no cancelling

Hi-fi Change day screen: the booking, the note that a changed ticket can't be cancelled, and a calendar with the cost of each day.

Every day says what the move costs

+₹140, None, Full

Scene 5Done

The app tells her what changed, and what she gave up.

The new day is ₹60 cheaper and she doesn't get that back. I kept celebration out of payment, so the good news waits for this screen.

What moved, and what it cost

even when the answer is "nothing back"

Hi-fi Date changed screen: return moved to Tue 15 Sep, ₹60 cheaper and not refunded, and a note that this was the one change.

That was her one change

said plainly, where it happens

Scene 6When things break

When it can't keep a promise, it says what still holds.

There are 13 of these states. Here are three: still loading, nowhere to move to, and a seat someone else just took.

Loading state: five skeleton day cards.
LoadingThe list's shape, before the data
Empty state: no other days to pick, the booking is safe.
Empty"Your booking is safe. Nothing was charged."
Error state: your return seat is gone, your onward trip is fine.
ErrorWhich seat went, then what's still fine

Success is scene 5.

In Figma

Every screen, on one canvas.

The final screens in Figma: six flows, with every way the promise can fail on the right. Open it full size to zoom in.

The RedBus Figma file: six flows (book the outbound, add a return, review and pay, after booking, move the date, cancel and refund) and a board of every failure state, each section headed in red.

Act 3Behind the scenes

Getting here wasn't this clean

I won't walk you through every version. These are the moments that changed the design.

The mess

It started as 102 sticky notes.

Eight interviews and a survey, one observation per note, nothing deleted. Sorting them gave me six clusters and one problem to solve.

The research board: sticky notes from each interview, grouped by traveller.

Part of the research board. See the whole board, with the jobs to be done and the brief.

Sixteen ideas

The obvious ideas died first.

Some already existed on RedBus. Some fixed a problem nobody had. Most still ended at a date picker. One kept the seat and the fare without asking for a date.

The one I picked

Book the last day you can travel

It keeps the seat and the fare without a date, and moves once when plans settle.

Later I moved past it. The final design is the window: you mark the days you could come back, then pick one.

  • RedBus already does it3Add-your-return card, Book both, save ₹X, Badge flexible buses
  • Fixes forgetting, and nobody forgets2Remind in two days, Ask when to remind
  • Holds neither the seat nor the fare3Save the return, unbooked, Book a duration, Operator now, date later
  • Still ends at a date picker2How-sure slider, Teach it your rule
  • Out of my hands2Ask the group, Guaranteed seat at today's fare
  • Folded into the pick2Show what waiting costs, Let the app decide
  • Parked for next1Catch the moment plans settle

Idea 13 lost only on scope. It's what I'd build next.

Where it goes

I gave the return its own step, knowing it was the riskiest place.

I had three places to put it. A sheet on the review screen would have picked the return's boarding and drop points for you, and people choose buses by those stops. Samarth nearly missed a bus over a stop 800m away. Tweaking RedBus's existing screens would only reach people after they had paid.

Rejected

A sheet on review

Rejected

Changes to existing screens

Picked

Its own step in checkout

It was also the only option that could break my 95% limit. So Skip is as easy to see as Continue, and nothing on the step can block you, not even a confirmation dialog.

Attacking it

Then I attacked my own idea, and it came second.

I wrote eight attacks on it. The worst: after a change you can't cancel, so the people least sure of their plans could end up with the least refundable ticket.

Idea A

Book the best day in a window

8 / 10
Idea 16

Book the last day Mine

7 / 10

When I scored every idea on merit, the window idea beat mine. So I built that next.

My mistake

I also wrote something false into the product.

Version 1 told travellers the date could only move earlier. That limit was mine, a shortcut I had stopped questioning. FlexiTicket always allowed later.

Version 1 said

"You cannot move it to a later day."

Now it says

"Move your return to any date, earlier or later."

I fixed it on the screens after payment first, and missed the one where people form the belief.

The demo

My mentor asked three questions I couldn't answer.

My mentor reviewed my work. In the demo I argued how it differed from FlexiTicket before admitting it was the same, and lost the argument. Two of his questions rested on facts I had in screenshots and never wrote down. Now I start by agreeing: it is FlexiTicket underneath, and what changes is what the app asks for.

"Users get free cancellation with FlexiTicket but not with yours."

My answer now

FlexiTicket refunds at least 50%. The full refund is a separate paid add-on.

"You should charge for this flexibility, like they charge for FlexiTicket."

My answer now

FlexiTicket is free. RedBus's own page says "at no extra rate".

"This construct IS a flexi-ticket. Why build it separately?"

My answer now

It is FlexiTicket. What changes is that you don't need a date to use it.

How I1

How I stopped booking the cheapest day.

Version 2 booked the cheapest day in a range, which pushed people to spend their only change. Version 3 booked the last day. Version 4 kept the days still, because a real route runs up to 30 buses a day.

Version 1, Last day screen.
Version 1Ask for the last day
Version 2, Return window screen.
Version 2Ask for a range, book the cheapest
Version 3, one calendar.
Version 3One calendar, one tap or two
Version 4, the question above the calendar.
Version 4Ask first, then the calendar

The real bus list for one day was 14 cards and 4,957 pixels long.

Pricing a day

I got the price on each day wrong twice.

First each day showed its default bus's fare, and the calendar and the day list disagreed by up to ₹230, one tap apart. Then each day showed its cheapest fare, but on 3 of 5 days that bus couldn't change its date. So the price that stood out belonged to a ticket that couldn't move, which is the one thing this flow is for.

Failed

Priced at the default bus

Failed

Priced at the cheapest bus

Now

Priced at the cheapest bus that keeps the date change

The fix cost me a rule I liked: a night bus out used to mean a night bus back by default. Now that's a tag, one tap away.

Checking it for real

So I booked a real ticket to check one rule.

My design needed a date change to stay with the same operator, and nothing I'd read said so. I booked a FlexiTicket bus and opened Change travel date. It was right there.

Same operator, same route

my biggest open risk, closed

The live RedBus Change travel date screen: 'You can select bus from same operator and same route as original ticket'.

Change once, then no cancelling

the rule the whole design leans on

Pushing back

Then my mentor asked: isn't FlexiTicket better?

It moves you to any date, and mine capped you at a week. I kept the week, because it's how you book without a date. I just stopped it from limiting the ticket.

Before

You can change within your week

After

The week picks your day. The change can go to any date.

Both paths now reach 29 days.

Testing

I tested it against my own rules. It failed.

Before testing I wrote down what would kill the design, so I couldn't move the goalposts later. Two of those conditions came true.

Fired

Unsure people tap a single day

Fired

They take the cheapest day and can't move it

Almost

Nobody reads the rules

What they did

One line, read three wrong ways.

The calendar said "Not sure? Tap two days instead." Nobody used the window it was asking for.

"Ok I am not sure"

Vivek, out loud. Then he tapped Skip.

A day, then the next day

Tia's two taps. No window.

Two days in a row

How Sai read "tap two days".

"in this my seat is getting confirmed right?"

Vivek again. He thought every marked day held a seat.

Not one of them read a subheading, in any session.

How I2

How I made the calendar ask first.

Two answers sit above the calendar: "I know my date" and "I'm not sure yet". I borrowed the shape from Swiggy's "When?" toggle and kept one line under it, because two words alone is how Sai misread "tap two days".

Version 3 calendar with 'Tap two days instead'.
Before: v3"Tap two days" read as two days in a row
Version 4 asking 'I know my date' or 'I'm not sure yet'.
After: v4Ask first. The calendar stays right under it.

My mentor spotted this problem three weeks before testing. It took three testers for me to see it.

How I3

Sai asked me to hide the risky buses. I didn't.

He took the cheapest day without seeing it couldn't change, and asked me to show only buses that can. That would hide the cheapest bus on the route, and price mattered to all three testers.

So I made the risk hard to miss

the day and its bus both say it can't change

The day list with Mon 21 Sep picked: its bus cannot change date, and the button reads Book a fixed date.

It names her own answer back

"You said you were not sure yet"

The button changes

"Book a fixed date", not "Review trip"

Sai still said he'd use this over today's flow, and wouldn't tap Skip. He had struggled the most.

What made the cut

Four weeks, one designer. Something had to go.

Each item has the reason it landed where it did. Most of the arguments were about what to say no to.

Must

The design doesn't work without these

  • Book without a date

    This is the idea itself. People wait on the return because they don't know the day yet, so asking them for a date doesn't work.

  • One change, to any date

    The week only helps you pick a day. After that the ticket moves to any date, the same as FlexiTicket. My mentor pushed me here.

  • Every rule as a heading

    In testing, nobody read a subheading. So each rule is the bold line itself.

  • Failure states

    If the new seat goes mid-change, the old ticket stays safe, and the screen says that first.

Should

Built once the core worked

  • Better buses under your day

    Under the bus you picked, up to three others that beat it on something, like price or rating.

  • The full cancel flow

    Four screens rebuilt from the real app, so cancelling works the way people already know.

Could

Next, if this went further

  • Move a whole group together

    If five people booked and only three seats are free on the new day, the group splits. That already happened to Tia. I'd offer the move only when everyone fits.

  • Routes with one bus a day

    There, another day means a 24 hour jump. I haven't designed for it yet.

Won't

Said no, on purpose

  • Reminders

    Of the people who put off the return, 0% said they forgot, so a reminder wouldn't help anyone.

  • Hide buses that can't move

    Sai asked for it. It would hide the cheapest bus on the route, and price mattered to all three testers.

  • Charge for flexibility

    FlexiTicket already changes dates at no extra rate. Charging would make mine worse than what RedBus gives today.

  • Separate return seat and stop screens

    My mentor's idea, and he was right. The app picks them like your outbound, and you change them on the review screen. That took two screens out of the way before paying.

Act 4What's next

What I'd do if this shipped

Nothing here is live, so there are no results yet. Here's how I'd know.

What I'd watch

Three numbers, and when I'd pull it.

If returns rose 8% but outbound bookings fell 6%, I'd roll it back. That's trading trips for returns.

Goal

Returns added before paying

The number this should move

Limit

Outbound bookings, at least 95% of today's

Must not drop below that

Risk

Free Cancellation sales

Might dip, so watch it

Keeping

What I'm taking to the next project.

Three things this project taught me, mostly by getting them wrong first.

1The mentor demo

Write the facts down before the demo.

My mentor asked three questions I couldn't answer. Two of them rested on rules sitting in my screenshots folder, never written up. Now the rules I rely on go in a table before I present.

2Testing

Put the rule where people actually look.

The calendar's hint sat in small text under the heading. Not one tester read a subheading, in any session. Now every rule is the bold line.

3My own mistake

Fix a wrong belief where it starts.

The app said a ticket couldn't move to a later day, which wasn't true. I fixed the screens after payment first, and missed the one where people choose their day, which is where they got the wrong idea.

Thanks for reading.

Got a question, or a better idea? I'd love to hear it.

Email meLinkedIn

Next case study

SideDoor

Designed SideDoor, a referral app where no request is left on read