Course project · UX case study

Booking a rental car without surprises at the counter

A redesign of the car rental booking flow that shows the real price and the deposit before you pay, not after.

Role

Solo UX/UI designer

Timeline

April to September 2026 (alongside a full-time job)

Tools

Figma, FigJam, Miro, Framer

Methods

/User interviews

/Usability testing

/Affinity mapping

/Journey mapping

/Wireframing

/Prototype testing

Overview

Renting a car should take five minutes. On most rental sites, the real cost only shows up at checkout or at the desk.

I redesigned the full booking flow for a fictional brand, passo.: search, car, protection, add-ons, checkout and confirmation. It started as my UX Design Institute course brief. I took it to a tested prototype and a final UI.

Scope: desktop booking flow, from search to confirmation.

Out of scope: mobile layout, account area, managing an existing booking.

Scope: desktop booking flow, from search to confirmation.

Out of scope: mobile layout, account area, managing an existing booking.

The Problem

People don’t mind paying for a rental car. They mind not knowing what it will really cost.

Across five usability tests on six rental sites, the same friction kept coming back: details split across pages, surprise redirects, preselected options and money questions left open until the end. The deposit was the clearest case.

“Would call the location if deposit details don’t appear.”

“Wants all booking information in one place.”

“Irritated that each change opens a new tab.”

(Paraphrased observation notes from the sessions, not verbatim quotes.)

Problem statement: Key information, above all the total price and the deposit, is scattered or changes along the way. People stop trusting the booking and fall back to the cheapest option.

Research & Discovery

What I did

Five usability tests on six live rental sites, with three participants:

What I did

Five usability tests on six live rental sites, with three participants:

Source

Sites

Notes

Course recording, observed

Budget, Kayak, Hertz (one participant)

Moderated by me

Europcar

Moderated by me

Sixt, Rentalcars.com (one participant, one session)

143 observations, 11 themes. Every note went into a Miro affinity diagram, clustered with AI help and checked by hand.

Affinity diagram of the usability session notes, grouped into clusters

Additional options cluster: deposit information was missing or hard to find.

Insights & Design Principles

01. One site, start to finish.

⌄

Insight: People lose track when details are spread across pages. In the design: date pill in the header, progress stepper, sticky summary with "Change" links.

02. The price you see is the price you pay.

⌄

Insight: Trust breaks when the price changes or is incomplete. In the design: day rate and total together, deposit before payment, pay-now discount as its own line.

03. Nothing chosen for you.

⌄

Insight: Preselected defaults feel like losing control. In the design: explicit choices, "Included" only where it's free, add-ons as optional checkboxes.

UX Process

The chain from research to screen:

Usability session

→

affinity diagram

→

user journey

→

user flow

→

sketches

→

wireframes

→

prototype test

→

iterations

→

final design

Usability session

Affinity diagram

User journey

User flow

Sketches

Wireframes

Prototype test

Iterations

Final design

User journey

Location & dates

Car selection

Add-ons

Protection

Checkout

01 Location & dates

Goal

Find a location and dates quickly.

Pain points

Redirects and new tabs, booking details split across screens.

02 Car selection

Goal

The cheapest suitable automatic.

Pain points

Too many options, unclear differences, no automatic filter.

03 Add-ons

Goal

Skip what isn’t needed, keep costs low.

Pain points

Unclear add-ons, CarPlay fees, deposit info hard to find.

04 Protection

Goal

Enough cover at the lowest price.

Pain points

Too much text, unclear packages, options that can’t be removed.

05 Checkout

Goal

Book quickly, review everything before paying.

Pain points

Surprise payment pop-up, data not saved, no booking overview.

Location & dates. Goal: find a location and dates quickly. Pain points: redirects and new tabs, booking details split across screens.

The low points were add-ons and protection, where unclear extras and packages made people lose track of the price.

User flow

About 20 user actions mapped against screen states across six pages. One change from flow to design: protection now comes before add-ons, the order people know from other rental sites.

The flow already planned what the prototype later missed, so the iterations were a return to the plan, not new ideas.

User flow

About 20 user actions mapped against screen states across six pages. One change from flow to design: protection now comes before add-ons, the order people know from other rental sites.

The flow already planned what the prototype later missed, so the iterations were a return to the plan, not new ideas.

User flow: user actions and screen states in a serpentine layout

Homepage, part 1: choosing the pickup location.

Sketches and wireframes

Car details: price and deposit on the card.

Step 1: search and dates

Testing the prototype

One moderated session plus a screen-by-screen review. The biggest issues broke the exact promises the design was built on.

Testing the prototype

One moderated session plus a screen-by-screen review. The biggest issues broke the exact promises the design was built on.

Iterations

The test surfaced four fixes, each tied to a promise the design made: the deposit moved from checkout onto the car card, totals now match on every screen with the pay-now discount as its own line, only the free protection package says “Included”, and the calendar shows correct dates.

Iterations

Final Solution

Four key screens. Protection and add-ons appear as wireframes above.

The three promises from the research sit right under the search.

Homepage

The three promises from the research sit right under the search.

Car selection

• Specs in one line: transmission, fuel, seats, bags.

• Trip total and deposit on the expanded card.

• A progress bar through the booking.

Checkout

• The summary stays visible, and every item can be changed.

• Pay-now discount on its own line, final amount on the button.

Confirmation

• Reservation number, amount paid, deposit and pick-up location.

Note: car and hero images are AI-generated placeholders.

Validation

One session, one participant. Small, but it showed the first version broke its own promises, mostly around the deposit and prices.

Next: test the final design with 4 to 5 people. Can they state the total and the deposit before paying?

Reflection

A promise on the homepage is a requirement for every screen. One wrong total breaks it. Next time I’d review every screen against a principles checklist before testing.

Small research, used all the way through. Every principle and most iterations trace back to a specific note.

Consistency is a system, not a pass. Copies drifting apart (times, emails, totals) were fixed at the root with shared components and variables.

Socials

Navigation

Socials

Navigation

Closing

Hidden costs looked like a pricing problem. It was an information problem: people didn’t mind the price, they minded not seeing it.

Next step: test the final screens with four or five people and check one thing. Can they say what they’ll pay, deposit included, before they click pay?

Thanks for reading.

Appendix: Design System

• Colors: brand green, accent yellow, neutrals, error and success, all as variables.

• Typography: Instrument Sans for headings, Inter for interface text.

• Components: buttons (primary, secondary, selected, disabled, hover), inputs (default, hover, focus, filled, error), chips, cards.

• Spacing and radius: 8 for inputs and buttons, 12 for cards and panels.

Color variables with names and hex values

Next case study

100 App Store reviews coded to measure the cost of a removed live occupancy feature, then turned into three design principles and new home screen, check-in and onboarding flows.

Read the PureGym case study →