Impact:
Created value by designing a highly usable fleet management system — a distinct selling point for GM Financial.
Context
General Motors’ lending arm, GM Financial, wanted to tap into more of the vehicle fleet leasing market. The question then was, how do they go about doing this?
Defining The Problem
They needed something to differentiate themselves from competitors. After all, several companies offered this type of large volume lease agreement, and rates were more or less the same from lender to lender.
What the team noticed is that none of these lenders offered a good way to manage all of these vehicles. There wasn’t any software that was built for this purpose. The differentiator had now been identified.
Identifying User Types
Enlisting the help of the Account Management team, we went about identifying the types of customers who manage these large fleets. By providing us this info, they were able to help us recruit the right types of customers for interviews to establish a baseline. These users consisted mostly of Medium to Large sized business and Municipalities.
Gathering Information
We set out to discover what these customers were looking for in this type of software.
What are your pain points? What would make this easier to use? How and when do you typically manage your accounts?
What we found was that the vast majority of these customers just didn’t want to even think much about it. They enjoyed the control of being able to look over and verify what is going to be paid each month, but wanted the process to be fairly automatic otherwise.
Design Phase & Pivot
After a couple of initial iterations, the general design was starting to fall into place. Early versions had overall payment information in the header, calculating your payment total as select vehicles to pay. However, while internally pressure-testing the design, this placement seemed to be problematic since a typical use case would have a customer scrolling down a page of potentially dozens of rows of vehicles.
This hypothesis needed to be tested with real users, and we wanted another version to test against. I designed another version of the payment bar — this time the bar being sticky and scrolling with the user down the page.
Over the course of three days and testing with 25 users, our second version (right side) was the winner. Users found it to be cleaner and easier to scan and they found the payment bar a much more usable tool than the payment information in the header.
I was able to clean up the design by consolidating some of the elements. For example, account nubmer, VIN, and vehicle name were always tied together — why did we need to give each one a separate column? Even when talking to users we learned that they only ever looked up a vehicle by its VIN and then the extra info (name, account number) were just points of verification.
Detailed Views
We also wanted to provide customers with a deeper look into each vehicle if they needed to. Each row was able to be expanded and collapsed via a toggle element. This would display more info like Payment Progress, Vehicle Account Details, Payment History and more.
Other scenarios needed to be accounted for too, like Past Due accounts and accounts with Pending Payments.
Many other scenarios existed and each one had their own specifications and design, such as Charged Off, In Repo, AutoPay and Single Pay Lease.
Designing the Payment Flow
There was more to the software than just the dashboard. Arguably the most important part of this was the payment service. Historically, customers had to go in to their account and pay each vehicle one by one — a potentially painful experience.
What we wanted to provide was a streamlined, one-action payment process. This, however, provided some challenges. At the time, GM Financial was locked into a contract with a payment vendor and this vendor would only allow one payment at a time. The technical constraints existed and there was no getting around them. So, how could we solve this problem with design?
My solution was to make it appear to the user as though they were making one large batch payment, when it reality each account was being paid one by one in the background. Once a customer selects which accounts to pay, they then proceed to the payment confirmation portion of the flow.
In some instances, users could choose to pay more than the minimum amount they owed on their due date. For example, a Past Due account could be paid only what is Past Due, or both Past Due and Current payment in order to be fully caught up.
Once a user selects what accounts and how much they want to pay, the proceed to the next step.
If no Payment Method is saved, users have the option to choose a previously saved method or add a new method. A checkbox option to “Use this payment method for all selected accounts” further smoothed this process by reducing the need to select a method for each individual account.
Once payment was submitted, an interstitial feedback screen communicated to the user that their payment was taking place, while in the backend, each account was being paid individually.
