In this project, we built CloudTrucks Fuel Card to help drivers get money for fuel purchase to start the trips. We overcame challenges including revamping the Cash page for a scalable and clear framework, designing Fuel card payment details to ensure clarity and trust, and reducing frictions in Fuel card sign-up flow. As a result, we saw over $1.5 million fuel purchase transaction in just 2 months after launch.
Drivers need to pay hundreds of dollars for fuel as an on trip expense before they get paid at the end of the job. Many drivers do not have the cash to pay for fuel expenses to start the trip.
Our current solutions—CT Credit Card and Pickup Pay—have several limitations. To fix this problem, we decided to introduce CT Fuel Card and sunset CT Credit Card.
By launching CT Fuel card, we hope to:
Increase fleet fuel spend on CT-issued cards from 57% to 80%.
Reduce usage of Pickup pay by 50%
Increase auto-generated fuel receipts on CT-card transactions from 9% to 70%.
In order to hit our goals, we wanted to make sure we provide the product that meets our users needs. So I conducted user interviews to better understand drivers’ needs when using a fuel card. The key insights are:
• Drivers frequently use fuel cards daily when they’re on the road.
• Drivers are often confused by autopay rules, available credit or pending balances.
• Drivers don’t want to spend time tracking payment deadlines, and they strongly dislike late fees.
Since we are basically replacing CT credit card with CT Fuel card, I wanted to know if there's exiting design that we could leverage. So I did a UX audit on current Cash page. But I found the IA is unscalable and hard to navigate.
After gaining deeper insights into the problem, understanding user needs, and considering the business objectives, I framed the problem statements as 2 parts:
• How might we make Cash home page easy for users to navigate and more scalable for product growth?
• How might we help users understand their payment timelines and credit usage without confusion or mental math?
At the same time, I collaborated with the product team to establish OKRs aligned with our design and business goals.
We followed a Information access at scale strategy. The goal is to focus on intuitive access to high-priority information, balanced with a scalable framework to support product growth.
In order to ensure users can easily access high-priority information, I looked at the data and I found that most visit pages here are cash account, Maintenance fund, and Request Pickup pay.
On the business side, Fuel card is supposed to hugely reduce the usage of Pickup Pay and replace CT Credit.
Number of unique visitor of all pages under Cash tab
Based on user's needs and business needs, we cleaned up the information architecture, making it easier to navigate through different accounts and increasing scalability by providing users with high-priority information with scalable framework.
Based on the new information architecture, we went through many design explorations for CT Cash page. And after rounds of design critique, we had a winner for it has a more clear visual hierarchy and more consistent design pattern which help reduce distractions.
Many rounds of iteration
Before
Information architecture is messy and not scalable to accommodate new changes. Hard to navigate because information is hidden and interaction is not clear.
After
Holistic view of driver’s financial performance across different accounts. Reusable financial tiles framework makes the page scalable for future growth.
I led a discussion session with the product, engineering, and risk teams, using design to facilitate alignment on a strategy that minimizes financial risks without significantly compromising user experience. Ultimately, we decided to implement a waterfall payment collection approach, prioritizing risk reduction and proactively preventing late fees. This decision was informed by lessons learned from our previous unsuccessful credit product.
Simulate payment scenarios to help the team make a decision
However, with waterfall payment collection, users might feel unpleasantly surprised when payments occur unexpectedly. To prevent this, the design should clearly communicate exactly when and how payments are collected. In this example, we use straightforward language and clear visual design to convey card payment status. Since approximately 95% of payments will occur automatically each week, it’s crucial to keep users consistently informed about their account status rather than prompting them repeatedly to make payments.
We tested standard credit card pending transaction handling-only update available credit but not current balance until transaction goes from pending to completed. And found this industry standard way of handling pending transactions couldn't meet our users unique needs. Drivers purchase fuel everyday and they need more flexibility to pay back the card to be confident to make another fuel fill-up purchase while the previous purchase is still pending.
To bring awareness of pending transactions, we separated pending transactions from the other card transactions. We also went outs of the industry standard way of pending transaction design, and added a sum of total pending amount in card payment detail. At the same time, allow users to pay back the pending balance to free up the credit for another purchase.
When designing the sign up experience, we faced a lot of uncertainties. In order to do that we reused the legacy design for the CT Credit onboarding. And during the beta test, we found out that users missed important information. One big change is that user's Pickup Pay limit will drop from 30% of load price to 15%. Drivers was surprised and unhappy about it after they got approved for CT Fuel card because they didn't read terms and conditions.
Also most users failed in the Stripe KYC step, because they entered a different business name than the one CloudTrucks has. And Stripe doesn’t return error reasons to drivers, so they don’t know how to fix it.
So I worked closely with the content designer and marketing team to break down the key information into different modules, and we added a video, making it easier and faster to consume the key information. We also added a confirmation modal to reinforce the major changes that will happen to users once they get their fuel card.
To help users who failed Stripe verification, we are working with Stripe on pre-populating more info that CloudTrucks already saved for users to reduce the frictions. Meanwhile, we specified error messages and instructions on how to fix errors to help users overcome onboarding frictions.
Here are some highlight of the final design.
We revamped the Cash homepage by bringing the Fuel Card and Maintenance Fund directly to the main screen. This allows drivers to easily view and manage available balances across different accounts. Additionally, we separated pending and completed transactions to enhance transaction transparency.
Unlike a traditional credit product, CT Fuel card mostly collects funds from job payment automatically, so we brought highlight on the available amount over current balance. Status pill changes based on the status of last statement balance. Despite autopay from job payments, users can also easily make a payment from their CT Cash balance or linked bank account.
User can manage their fuel cards, adding cardholders, and lock card on the web app.
Just 2 months after the V1 launch, we saw most of the key metrics surpassed our initial goals.
My learnings from this project is standard ways are not always for every case, like we got out of the industry standard ways of handling pending transaction to better serve truck drivers’ unique fuel purchase behavior and mental models. The key is to always keep your users needs and behaviors in mind. Also clear financial communication builds trust. By using factual, transparent language—especially for autopay and pending transactions—we reduced confusion and led to fewer support issues.
