AnandGatta
Work About Resume Experience Contact
Back
Paratransit · Mobile app

Rider App Booking Flow, Redesigning the Booking Experience for Paratransit Users

Services
Product design · Mobile UX
Role
Product Designer
Timeline
2026 · 8 weeks
Platform
iOS Mobile

A rider-first booking experience for paratransit users, reduced to the decisions that matter, with clearer maps, accessible controls, and confident confirmations.

The redesign turns a high-friction routine into an inclusive, predictable journey for people who depend on reliable transport.

Old design & new design
Old design, legacy paratransit booking screens
New design, redesigned booking flow
Walkthrough
01 / The challenge

The most critical flow had grown bloated.

The booking experience is the single most critical flow in our rider application. Over successive feature additions, it had grown bloated and confusing. Passionate daily users found themselves facing unnecessary cognitive friction when executing routine trips.

This redesign recovers clean, rapid utility while respecting the visual instincts of seasoned riders.

Role
Product Designer
Duration
8 weeks
Focus
Booking, Accessibility, Information Architecture
Platform
iOS Mobile
02 / The problem

Booking asked riders to move between disconnected screens before they could review the route and confirm the trip.

The screens separated address entry, trip preferences, and confirmation. My design question was how to keep those details understandable without removing information riders need before booking.

03 / Audience mapping

Design scenarios

These illustrative scenarios make the design priorities concrete. They are assumption-based planning aids, not interview participants or validated research personas.

D
Older rider
Illustrative scenario · Routine appointments

Design need: clear pickup details, understandable labels, and a visible booking confirmation.

Potential friction to consider
  • Disconnected steps can be difficult to follow
  • Small touch targets are difficult to tap accurately
  • Can't visually verify her route on the map
  • Jargon labels that aren't clear
  • Dependence on phone support when the app is unclear
Design goals
  • Book rides to weekly dialysis appointments reliably
  • Understand exactly when the ride will arrive
  • Know the fare cost upfront before booking
  • Confirm pickup and drop-off locations visually
M
Rider using a wheelchair
Illustrative scenario · Mobility requirements

Design need: keep mobility requirements and trip details easy to review before confirmation.

Potential friction to consider
  • Repeated transitions between single-purpose screens
  • Mobility aid selection required every single time
  • Small dismiss controls may be difficult to target
  • No booking summary to review before confirming
  • Repetitive data entry that should be saved
Design goals
  • Book accessible rides accommodating his wheelchair quickly
  • App remembers his mobility aid requirements automatically
  • Review complete booking details before confirming
  • Complete bookings with fewer steps
04 / Strategic methodology

The design process

01
Discover

Review the existing screens and booking sequence; use secondary references for context.

02
Define

Identify interaction risks and define the route, trip-details, and confirmation groups.

03
Design

Explore layouts, map feedback, and reusable controls in the booking prototype.

04
Deliver

Document the interface, component behavior, and questions for usability validation.

Design objective

Make route entry, trip details, and review easier to follow. Completion time and abandonment are measures for future validation, not results claimed in this case study.

Team & context

The booking interface sits within a wider transport service. Changes to the rider flow need to preserve required trip information and work with dispatch, eligibility, and fare rules.

05 / Design rationale

What shaped the redesign

This public account uses the existing screens and flow diagrams to explain the decisions. It does not present secondary reviews as primary interviews.

01 / Route clarity

Confirm the locations

Show pickup, drop-off, and the route together so the rider can inspect the trip before proceeding.

02 / Information grouping

Keep related choices together

Group trip purpose and mobility requirements within trip details. The tradeoff is a denser screen, which needs a clear reading order.

03 / Review before commitment

Make confirmation explicit

Place route, schedule, and fare information before the booking action. Fare presentation must follow the operator’s actual service rules.

06 / Heuristic audit

Interaction risks in the existing screens

My screen review focused on visibility of system status, recognition, and error prevention. These are design observations and priorities, not findings from a participant study.

Critical · Finding 01
Single-purpose screens fragment the booking task

The flow diagram separates several single-purpose stages. Grouping related details can reduce transitions, but fewer groups do not automatically mean faster completion.

Critical · Finding 02
The map does not clearly confirm the selected route

Both addresses entered, map shows only a GPS dot. No pickup pin, no drop-off pin, no route line. This makes visual route verification difficult; effects on re-booking or support calls were not measured.

Critical · Finding 03
The final screen before booking is the most broken screen

Fare buried in a floating badge. Drop-off address truncated. Purpose field cut off above the CTA.

Major · Finding 04
Pickup window language creates anxiety on day of travel

“10:06 AM–10:38 AM” shown with no explanation. For riders attending appointments, an unclear pickup window makes planning difficult.

Positive · Finding 05
Three patterns worth preserving

Heart/clock icon system for saved vs. recent addresses. Return trip prompt after booking. Bottom tab navigation. These were designed well, kept in the redesign.

07 / Screen by screen

Existing screens, annotated

Legacy address selection screen with stored and recently used addresses

Address selection

1
Critical
Pickup and drop-off on separate screens

Forces the user to navigate to a second screen just to enter the second address, doubling the steps for one logical task.

2
Major
Back navigation says “Details”, confusing

The back label “Details” doesn't tell the user where they came from or where they'll go back to.

3
Positive, keep
Heart / clock icons for saved vs. recent addresses

Excellent recognition pattern, users can identify saved destinations without reading labels.

Legacy itinerary screen, map shows only a GPS dot

Itinerary + map screen

1
Critical
“Arrive by” is ambiguous jargon

Users don't know if this is their requested arrival time or a guaranteed window. Creates booking errors for medical appointments.

2
Critical
Drop-off address truncated to “Chawdr…”

User cannot verify their destination is correct. This makes it harder to check the trip against an appointment time.

3
Critical
Map shows only a GPS dot, no route, no pins

Both addresses entered but no visual confirmation. User cannot verify their journey is registered correctly.

4
Major
Date / time split into 3 tiny tap targets

“Arrive by”, “Jul 8”, “7:40 PM”, three adjacent buttons, each under 44pt. Impossible for Older rider with reduced motor precision.

5
Major
X button clears address with no undo

Tapping × instantly clears a typed address with no confirmation and no way to recover it. Catastrophic for low-literacy users.

Legacy New Trip summary with fare in a floating badge

New Trip summary screen

1
Critical
Fare floats outside the reading order

$2.00 sits in the top-right corner outside the natural reading order. Fixed-income users commit to a booking without knowingly seeing the cost.

2
Critical
Section chevrons ambiguous, edit or expand?

“›” next to Itinerary, Specifics, Payment, Price, each chevron could mean expand to see more OR tap to edit. Users can't tell.

3
Major
Purpose field “Shopping” cut off above Book Trip

Critical information truncated directly above the confirmation CTA. User is committing to a booking with incomplete information visible.

Legacy trip destinations screen, ride location not yet available

Trip destinations

1
Critical
Ride location “not available”, no guidance

On the day of a medical appointment, the most critical screen shows “not available” with no ETA, no fallback, no explanation.

2
Critical
Live tracking buried as a small text link

“Map view”, the most valuable feature on travel day is a tiny underlined text link at the bottom. Older rider may never find it.

3
Major
“10:06 AM–10:38 AM” shown with no explanation

A raw time window with no context. Users don't know if they need to be ready at 7:10 or if the driver might be late by 7:17.

08 / Structural design

From separate stages to three task groups

The original flow fragmented one decision, “I want to go from A to B at this time”, into eight separate screens. Each screen became a drop-off point. The redesign organises these screens into three task groups: route, trip details, and confirmation. These groups can still contain multiple interactions.

01
Was: steps 1 + 2
Set pickup + drop-off with map confirmation

Both address fields on one screen. Map updates in real time as addresses are entered, showing route line and both pins immediately. Saved addresses (heart/clock icons) preserved from the original.

02
Was: steps 3 + 4 + 5 + 6
Trip details, date, time, mobility aid, fare

All trip parameters on one screen in reading order. Fare visible before commitment. Mobility aid pre-filled from Rider using a wheelchair's profile. Plain language pickup window replaces jargon.

03
Was: steps 7 + 8
Confirm and book

Full summary, untruncated addresses, plain pickup time range, itemised fare breakdown, wallet balance with “Covered” confirmation. One CTA. No ambiguity.

Existing flow, 8 steps to book
Redesigned flow, 3 steps to book
09 / High-fidelity artifacts

Final design & UI

The polished UI features crisp geometric line work, robust touch targets, and a system font stack designed for rapid contextual reading during transit.

Every finding has a visible solution

Before
Map shows a GPS dot. No route. No pins.

Both addresses entered, the map renders nothing useful. Users cannot verify their journey visually. Direct cause of re-bookings and phone fallback confirmed in App Store reviews.

Before, map renders only a GPS dot
After
Route line + pickup pin + drop-off pin from first entry

As soon as both addresses are entered, the map renders a route with both pins. Older rider can see her journey to the dialysis centre before she confirms anything.

After, Confirm route with route line and both pins
Before
Fare hidden in a floating badge

$2.00 appears in a floating badge outside the reading flow on the last screen. For users on fixed incomes, this is a fundamental trust failure.

Before, fare hidden in a floating badge
After
Itemised fare breakdown. Total before confirmation. Wallet status.

Base fare, distance charge, waiting charge (conditional), taxes, and total, all visible in the reading flow. Wallet balance shown separately with “Covered” confirmation.

After, itemised fare breakdown with wallet balance
Before
“10:06 AM – 10:38 AM”, no explanation

A raw time window with no context. For riders attending appointments, an unclear pickup window makes planning difficult. The redesign distinguishes the scheduled trip time from the pickup window.

Before, raw pickup window with no explanation
After
“Your driver may arrive between 11:05 AM – 11:40 AM”

Plain time range derived from pickup time and negotiation window. Older rider reads an actual clock time, no formula, no guessing, no arithmetic required.

After, pickup time and negotiation window in plain language
Before
Live tracking buried as a small text link

Map view buried at the bottom of the trip card. The most valuable feature on travel day, knowing where your driver is, is the hardest thing to find.

Before, live tracking buried as a small Map view text link
After
Full-screen map. Driver info. Lock screen notification.

Live tracking is the primary day-of experience. Lock screen shows ETA without opening the app. Driver name, photo, vehicle, and arrival time all prominent.

After, full-screen tracking, driver details and lock screen ETA

Final screens

Final redesigned screens, booking, trip details, confirmation and tracking
10 / Design output & validation

Design changes and intended benefits

The screens below demonstrate the design changes. Faster booking, fewer errors, and lower abandonment remain hypotheses; no measured usability or post-launch performance results are presented.

Stage 01
Legacy pain point
8 booking steps
Visible design change

The redesigned flow groups work into route, trip details, and confirmation. These are task groups, not a measured reduction in taps or completion time.

Stage 02
Legacy pain point
Multiple form fields
Visible design change

Larger controls, clearer labels, and a review screen are intended to support a broader range of riders. Accessibility and task completion still need validation with intended users.

Stage 03
Legacy pain point
Separate location entry
Visible design change

Saved locations and visible route feedback support location entry and review. Their effect on errors and effort has not been measured.

Stage 04
Legacy pain point
Complex navigation
Visible design change

Reusable UI patterns and a modular booking flow, built to support future features such as recurring trips, companion riders, and trip modifications without reintroducing the original complexity.

11 / Post-project reflections

Key learnings

01
Respect learned behaviors

Riders develop deep muscle memory. Drastic UI changes should be introduced incrementally to prevent initial drop-offs from sheer layout unfamiliarity.

02
Map real-world stress

A booking flow isn't used in a quiet office. It's used on a rainy platform while juggling bags. Designing for extreme environment states prevents fragile UI breakdowns.

03
Design for the system, not the screen

Changes to a core booking layout create cascades into driver dispatch, customer service, and receipts. Holistic designers manage downstream system side-effects.

12 / Contact

Let's design a product people can use with confidence.

For product design, design systems, prototypes, and AI-powered design workflows.

Email me → Next: Life Sciences case study