All projects

Project

Hertz Vflex

Overview

Hertz and Element partnered to create a pilot that would test the idea of a flexible fleet rental program. Hertz is trying to dive into the market of selling software, and wanted to run a pilot to test the feasibility of their idea. Our team was tasked with developing a responsive web app that would improve and streamline the rental process for both the renter and the management company. After interviewing users and researching the needs and business goals of both companies, we were able to design and develop a fully functioning software equipped with managing fleets, reservations, inspections, and financials.

Role

User Research

User Testing

Product Strategy

UX/UI Design

Product Development

Illustrations

The Problem

The current rental model used in the industry requires DSPs (Delivery Service Provider) to lease vehicles long term. This causes a fixed number of units allocated to each store, where only some units in the system are fully utilized at all times. Renters pay for vehicles even when they are not using them. Although demand may fluctuate, their fleet can not.

New Model

The web app we developed allowed the Fleet Management companies and DSPs to engage in a more flexible model where they only rented the vans when they needed them. It was important that the DSPs trusted that they could secure the vans at the last minute. This model increases utilization of the vans and helps separate Element and other participants from the competition.

The Solution

Our team developed a fully functioning software capable of creating and managing reservations, inspecting vehicles, and providing insight on the fleet overview, vehicle status, and location demand. 

We designed a fully clickable prototype with more robust features for future development which includes financial and rental history sections, in addition to more admin and customer satisfaction functionality for certain users.

Provide visibility into future availability at a virtual HLE

Manage the rental process for vehicles that Hertz does not own

Pre and Post rental inspection of vehicles. Capture and accurately charge for damage.

Invoicing and billing data

Provide visibility into future availability at a virtual HLE

Manage the rental process for vehicles that Hertz does not own

Pre and Post rental inspection of vehicles. Capture and accurately charge for damage.

Invoicing and billing data

Element Agent Features

Element Agent Features

Dashboard

Dashboard

The main dashboard for an element agent focuses on reservations, to give them an overview of their schedule of opening and closing rentals.

The user has the ability to start a rental from the dashboard by clicking the checkin/checkout button, or they can find the specific rental in the list and open the rental that way. Because the agents do not have a set location there is a filtering option at the top of the dashboard for each hub/station. The results can then be filtered further by a specific DSP or date.

Fleet Overview

Fleet Overview

The fleet overview section focuses on helping the Element agent with management of the vehicles themselves. Determining the inventory at each location, details about a specific vehicle, and most importantly it gives the agent insight into the demand at each location in comparison to inventory to help with transferring decisions.

Vehicle Inspections

Vehicle Inspections

One of the main goals of the project was to improve the inspection process when opening or closing a rental. Having a thorough record of inspections allows the company to catch damage more accurately. The users expressed the need to easily be able to compare past inspection photos to the current state of the vehicle to see if there was new damage. So we incorporated the past inspection photo of each prompt within the new inspection so that users could easily compare for new damage without having to click back and forth. The inspections consist of specific photo prompts, an operational checklist, driver acknowledgments and signatures, with the option of a damage report. Agents can add vehicle notes in addition to reservation notes to keep track of the unexpected delay

DSP Admin Features

Reservations

Reservations

The user selects their dates and it will display the closest locations to their set office address. We wanted to give the user the ability to see inventory before selecting their location so that they could make a more informed decision based on how many vans they knew they needed. Once the reservation is submitted, it is broken into separate reservations with unique codes. These codes will be used to help pull the reservation when the driver arrives to check out the rental.

DSP Dashboard

DSP Dashboard

The dashboard allows the DSP (Delivery Service Provider) to manage all current and upcoming reservations. They also have the ability to refer back to closed reservations, and see if any damage was found that occurred during their rentals.

Financials

Financials

Post MVP, both Element and DSP Admin will be able to view all invoices for each rental. There will be monthly reports in addition to the individual invoices per rental. Element admin will have the ability to upload 3rd party invoices for the DSPs.

Rental Management

Rental Management

All users will be able to reflect back on past rentals and access the attached vehicle inspections and invoice. It was important to provide the DSPs with access to both of the inspection reports in order to lower the rate of disputes surrounding damage to the vehicles.

Element Admin

Element Admin

Additional functionality available to Element admin includes the management of all DSP accounts, as well as an overview of recent cancellations for insight into customer satisfaction.

Desktop Interface

Designing the Product

Designing the Product

At the beginning of this project the team was given a very aggressive timeline. With the limited timeframe, the design team was not able to do a significant amount of user research before diving into the UI.

Define the problem

Define the problem

During our discovery we outlined the business and product goals, personas, integrations and technology, as well as open questions and action items.

Understand the User - Journey Mapping

Understand the User - Journey Mapping

The first thing we wanted to do was understand the user. We developed user journeys for of multiple types of users to go through their current process and identify pain points and opportunities. We later went back and mapped out the flow of the proposed solution to identify any non happy paths.

Understand the process - Service Blueprint

Understand the process - Service Blueprint

To further understand not only the user but the entire process as a whole we developed a service blueprint to outline all of the backstage actions and support processes that are involved and affect the users overall experience. This was important in making sure the designs were feasible and captured all necessary operations.

We also workshopped with the client to point out different use cases in their current processes that were not ideal. We were trying to help them visualize how their proposed system would cause problems.


It also exemplifies one of the main learnings from this project. It was challenging to take the input and requirements from Element and apply them to an application that was supposed to be universal to multiple companies. Element wanted the app to be completely customized to their operations, but in the end the team had to remember that we were working for Hertz and designing a product for them. So while Element may have wanted this complex invoicing structure, that was not in the best interest of the product as it made it too niche. We learned to take Elements requirements with a grain of salt and make some decisions about the product that were in the best interest of Hertz end goal.

Visualize the Solution

Visualize the Solution

The app was designed in Figma and broken up into 3 views for the different users; DSP admin, Element Admin, and Element Agents. The main asks for the MVP were to have the ability for DSPs to make reservations, and for Element to be able to check rentals in and out efficiently while keeping a record of inspections to capture damages. We focused on the mobile and desktop breakpoints.

Due to the limited user research before the team started designing, we relied heavily on the Element and Hertz teams as industry experts to answer questions about needs, use cases and typical actions in the user journey. One area the team struggled with due to this was making sure we were designing a universal product that Hertz could sell to multiple clients, and not a product that was so specifically tailored to Element and their operations.

Development

Development

What really helped our team through the prototyping process and transforming it into real software was the efficiency of our story times and the backlog. The team used Pivotal Tracker to organize and prioritize stories. The product manager, lead developer, and myself would collaborate on the direction and priorities of the project. We split screen share so that we could see the designs in Figma, and walk through them as we wrote stories. One of the goals for design was to remove any guessing for developers. Every non happy path or variation was accounted for in the designs in Figma and then linked to the corresponding stories to make it as easy as possible for the team of developers to understand what we were building.

Test and Iterate

Test and Iterate

Once we had a clickable prototype we started creating a plan for user testing. At this point the timeline for the project was extended so we decided to go back and conduct user interviews to gather further information about roles and pain points with the current process from real users. We found that with the current system users were very frustrated with the inconsistency of vehicles and the frustration around service and maintenance requests as well as a fluctuation in pricing.

Then we had them test the MVP of the actual software to get their initial impression. We conducted the usability testing remotely, so in order to be able to watch them click through the software and actually see for ourselves where they struggled with different tasks, we screen shared on zoom and gave them remote control of the screen. To easily refer back to the interview we used Otter.AI which automatically transcribes the interview. From our testing we were able to conclude that some of the terminology used in the app was confusing to users and needed to be changed, and some design changes needed to be made in terms of placement of buttons and interactions. Overall, the users were very happy with the current functionality and features of the app. After synthesizing the interviews and testing we were able to recommend features to the client for further development.


Challenges and Learnings

Challenges and Learnings

One of the major challenges of this project was getting definitive answers from the client that we could work off of. This project originally started out with a very short timeline for development to launch the pilot, and this affected the design process in numerous ways. However the date of the launch of the pilot kept getting pushed back which would then affect the overall product goals. With more time we could develop a more robust product. It was challenging to predict and answer questions about what would be in the final MVP because we never knew when that cutoff for development would be.

The same theme of the clients being a roadblock to the overall product development came up in other areas as well. Element was unable to give us an answer for weeks on how they handled their invoicing and finances. They were undecided on how they wanted vehicles to be attached to locations. All of this caused delays in development as the team could not move forward with certain stories until we had an answer. In both instances the team had to really push them for answers, and make them think through the problem. We found it helpful to try and have them work through the problem with us so that we could explain why some of their proposed solutions would cause use cases that were not ideal.

Previous: PODS Booking Flow

Next: Ball Arena

All projects