How to Build a Thoughtful Rental Car Booking Form

A digital rental car booking form is an online interface, typically found on a website or mobile app, that allows users to begin the vehicle rental process. It is designed to provide a seamless and user-friendly experience while collecting all the necessary details to start a reservation.

I recently received an exciting brief from a client looking to enhance their rental car booking experience. They wanted a sleek, user-friendly form that simplifies the process for their customers while incorporating some essential details to ensure seamless reservations. It’s an interesting balancing act, so let’s build one together!

In this article, I’ll take you through the design process, key considerations, and how I approached creating a solution tailored to their needs.

The Brief

The form:

• For desktop application

• Cars for hire are distributed across a city

• Users can choose the nearest available car OR enter specific search parameters

• Essential data includes the pick-up date and time and the return date and time so the user can search for options

The objective:

• The form needs to be clear

• The form needs to facilitate quick and easy input of search parameters

• Emphasis on user flow and organisation of information

The scenarios:

1. Urgent Short-Term Renter: The user needs the nearest available car in the next 2 hours. Inputs “Pick-up date and time” (E.g. Today at 14:00) and “Return date and time” (E.g. Today at 15:00). Clicks a button to start the search

2. Casual Mid-Term Renter: The user plans to rent a car today at 20:00 and return it tomorrow at 18:00. Inputs “Pick-up date and time” (E.g. Today at 13:00) and “Return date and time” (E.g. Tomorrow at 11:00). Clicks a button to start the search

3. Frequent Mid-Term Renter: The user regularly rents a car on weekends for trips to the mountains. Inputs “Pick-up date and time” (E.g. Friday at 18:00) and “Return date and time” (E.g. Sunday at 20:00). Clicks a button to start the search

Our Notes

Before starting on the design, we’ll need to break down how we approach the structure of the form.

As a user, when hiring a vehicle, what are the main questions we have?

1. From when until when?

2. Where can I pick up / return? Same location / different

3. Purpose of the hire – this can dictate vehicle requirements (cars vs. vans)

4. What’s the price?

What is some additional rental information that could affect the hire price?

1. Age of driver (experience)

2. License location/type (local, EU, 3rd country)

3. Insurance coverage type

4. Expected distance to cover (wear and tear of vehicle)

5. Credit/debit card

6. Pay on booking or pay on arrival

7. Additional drivers

These items we need to consider after the user clicks “Search”, but are not important for this stage of the form design.

What type of booking could the user make?

• Time (Hourly, daily, monthly)

• Distance

At what stage of the booking process will the user require an account?

• No need for an account

• Before making payment

• Returning customers could have benefits

Now, I think we’re ready to start building.

Form Foundation

Users need to submit 4 pieces of information to start their vehicle search:

• Pick-up date

• Pick-up time

• Return date

• Return time

So let’s build some form inputs to make sure we capture that. Each form input requires a label for clarity, an input container, and a prompt/placeholder to direct the user. We can add an icon along with the prompt in each form field to clarify the format of input required.

The form feels quite busy with the combination of multiple labels and prompts, so we can group labels to make it clearer.

Each row now represents a different part of the reservation, whilst each input field is separated. We could take this one step further and integrate each row’s form fields to further indicate the connection between the two values (date and time).

Although this is a standard form orientation (vertical), the form is short and sweet, and the pick-up and return values are related. So I will want to change the orientation of the form to horizontal so that when a user interacts with a field, the dropdown will not be covering vital information. Placing an arrow icon between the two groups of fields will give another suggestion for the connection and separation of the two.

I’ve tried both the separated and integrated field options here to see how they look. Depending on how they interact with the dropdowns will depend on which direction we choose here.

Date Picker

When a user clicks on a date field, they will need to choose a date by either typing directly in the field in the format or selecting from a date picker.

For giving the option to type, we will need to consider input formats:

• YMD (Year, Month, Day)

• DMY (Day, month, year)

• MDY (Month, day, year)

• ISO (YYYY-MM-DD)

• EUR (DD.MM.YYYY)

• USA (MM/DD/YYYY)

Although the brief is set in Europe, we might have non-European users. So it would make the most sense to opt for a tweaked EUR format.

To clarify between day and month, we can require day to be written in numbers and month in letters. As an additional function, we can also accept numbers for months but have the form auto-update to letters.
E.g. The user enters “10 01” and the form updates to “10 Jan”.

We’ll use a forward slash instead of a period for higher visual clarity, so let’s go for the format of DD/MMM/YYYY.

Users would type values in the field whilst being automatically navigated through the different value types (like when entering credit card information during a checkout process). Setting this up could be wildly technical, so let’s look at a “back to basics” option with a standard calendar date picker.

Users can use the arrows at the top of the drop down either side of the Month and Year to navigate across months, and select the date to update their selection. This option is very mouse-orientated, so it could be very useful to give the user the option in the dropdown to choose between typing in a field and/or selecting from a date picker, with their companion input updating to match.

This version I’m very happy with – it has the best of both worlds and appeals to a wide range of users without confusing the user.

Time Selector

Much like the date selector, we can have users type directly in the field or select from a picker.

For value format, we only need hours and minutes, but the question is whether we implement 12-hour or 24-hour formats. Input type options are:

• HH:MM

• HH:MM AM/PM

Let’s look at both options. The 12-hour format is easier to read, but adding AM/PM might create confusion at a glance. The 24-hour format is harder to read for those who are used to a 12-hour format, but there is a clear distinction between morning and afternoon as a higher number means later in the day.

First, let’s try a simple scroller with options for every 30 minutes through the whole 24 hours.

This is very simple and easy to navigate, but if the time picker opens in the morning and the user wants to select a time late at night, they will need to scroll a lot. We can instead try a double scroller that shows morning and afternoon to speed this up.

There might be some confusion created with this option – without reading the individual scroller titles, a user might mistake each column instead for pick-up and return respectively. We could replace the second column for some popular times (based on customer data) so the user can quickly choose a time.

The two-column format is confusing, so we’ll flip it around to show that we have two obvious sections in a two-row format.

This format feels very intuitive and easy to navigate. However, I think it would be useful to give users the option to type here as well, just as we did with the date picker.

Having three ways to input one value feels confusing due to the amount of choice, so I think it would be useful to try and condense this back. We could prioritise typing with the option to select popular times to make things quick and accessible.

If a user doesn’t want to select one of the suggested times, they can begin typing and be presented with options related to that search with the consideration of both 12 and 24-hour formats. E.g. Searching “9” will return results for both 9 AM (9:00) and 9 PM (21:00) displayed in the 24-hour format.

Applying the Dropdowns to the Form

When a user clicks on each form field, the dropdown will display underneath, allowing the user to input the desired value.

When selecting the individual fields, it feels like a lot of work. The user has to click on a field, choose their value, and then click on the next field. Which brings us back to our previous consideration of integrating the pick-up and return fields (back in the Form Foundation section).

For an integrated group of fields, we should definitely try out an integrated dropdown for both date and time. We’ll stick to a combination of our solutions from the previous sections and have them sit side-by-side in two columns.

Because of the multiple inputs, it will be considerate to include the Cancel and Apply buttons to act as a user confirmation of input, so we’ll add those at the bottom of the dropdown as well.

I think this works really well – you can enter more information with less clicks (two required values with one dropdown).

A question that now crops up, is if we have the correct combination in one dropdown? We should explore one dropdown for pick-up and return date and another for pick-up and return time to see how that works for our users.

Date Selector Revisit

To begin with, we’ll apply our previous solution and add an additional field to indicate that the user can input two values.

This works well, but if the user needs a reservation that spans over more than one month, then we’ll need to expand the dropdown to include two calendar months.

Time Selector Revisit

Here we can also apply our previous solution from the Time Selector section, but including two time values (for pick-up and return).

I can safely say that this solution doesn’t work. The reservation start and end time is clear enough, but without a clear connection or indicator in the field input with the date values, they are open to interpretation for users.

• “Is this for one day?”

• “Am I only allowed to use the car between these times during my booking?”

We should revert to our previous solution of a combined pick-up date and time and return date and time selector dropdown for the form.

Final Solution

Here I’ve created the full user flow for the form, which incorporates the following features:

• 4 form fields to request all essential data values

• 2 dropdown menus for simply inputting values

• Horizontal orientation for desktop application

• The shortest path for the user to fill the form before clicking search requires 8 total clicks

• Ability to navigate the form using the keyboard, giving additional accessibility for users

Let’s revisit the user scenarios to refresh our memories:

1. Urgent Short-Term Renter: The user needs the nearest available car in the next 2 hours. Inputs “Pick-up date and time” (E.g. Today at 14:00) and “Return date and time” (E.g. Today at 15:00). Clicks a button to start the search

2. Casual Mid-Term Renter: The user plans to rent a car today at 20:00 and return it tomorrow at 18:00. Inputs “Pick-up date and time” (E.g. Today at 13:00) and “Return date and time” (E.g. Tomorrow at 11:00). Clicks a button to start the search

3. Frequent Mid-Term Renter: The user regularly rents a car on weekends for trips to the mountains. Inputs “Pick-up date and time” (E.g. Friday at 18:00) and “Return date and time” (E.g. Sunday at 20:00). Clicks a button to start the search

To make the user journey flow even quicker, we can always pre-populate the form using user-informed data:

• If the user is a Guest (not logged in), we can base this data on a user’s geo-location, the date, day of the week, and the time of day when booking

• If the user is an account holder, we can base this data on the above items along with the user’s history

As user would then potentially be able to perform a 1-click search for an available car to hire or click on parts of the form to make adjustments to the pre-populated fields.

Extending the Functionality

If our client is looking to extend the functionality of this form, we will need to look again at the user questions. Next on the priority list is the pick-up/return location.

This particular brief was limited to a single city. Adding additional functionality here would depend on the size of the city serviced, the radius and/or potential expansion of the service area. So, high-priority items would include pick-up and return locations, and in extension, the ability to choose between the same or different return locations. Even in a single-city service area, adding the ability to search for pick-up and return locations will help a user choose from locations within a city for a more informed search.

A user might be reserving an urgent/last-minute vehicle, but if they need to navigate to the other side of a large city to reach the pick-up point, they might become frustrated by navigating through the search flow only to find availability from an inaccessible location.