Case Study

TruckPay

TruckPay

Fleet Expense Management

Fleet Expense Management

Redesigning a B2B payments app for India's transport industry — from scratch, solo, with a client approving every screen.

B2B · Logistics & Transport

Mobile App · iOS & Android

Overview

What is TruckPay,

What is TruckPay,

and who is it for?

and who is it for?

TruckPay is a B2B payments and expense management platform built specifically for India's road transport and logistics industry. A startup hired me as a freelance designer to take their existing product — which had grown organically without a design system — and redesign it from the ground up.

The primary user is the transport business owner himself: someone managing 5 to 50 trucks, paying drivers, fuel vendors, toll operators, and maintenance contractors daily. If the business is large enough to have office staff, they use the app too — but the owner is the person who signs off on every payment and needs to trust what he sees on screen.

The Problem

What was broken

What was broken

in the old product?

in the old product?

Accessibility & readability

Font sizes were too small for the primary use case: a fleet owner checking payments while standing near a truck, often in outdoor lighting conditions.

No design system

Components were one-off. The same button appeared in three different styles. Spacing, colour usage, and typography were inconsistent across screens.

Missing core flows

Bulk Transfer: paying multiple drivers at once, didn't exist. Scan & Pay wasn't there. These weren't edge cases; they were daily workflows for the target user.

No quick-pay shortcut

Owners with small fleets (3–5 trucks) pay the same 4–5 people repeatedly. There was no "Send Again" or quick-access beneficiary row.

My Role

What I owned,

What I owned,

and what I didn't.

and what I didn't.

I was the only designer on this project from day one to launch. Every design decision from the colour token system to the micro-interaction on the PIN entry screen was mine to make. The client approved every screen before it moved to development, which meant I had to present and defend every decision clearly.

🎨

UI Design — all screens
UI Design — all screens

50+ screens across 10 pages. Every state: empty, filled, loading, error, success.

Solo

⚙️

Design system — built from zero
Design system — built from zero

Colour tokens, typography scale, component library, elevation system, motion principles.

Solo

🗺️

UX architecture & flows
UX architecture & flows

Navigation structure, payment flows, onboarding sequences, all screen states and edge cases.

Solo

📐

Developer handoff specs
Developer handoff specs

Pixel-level documentation for every component, spacing, animation, and interaction.

Solo

🔬

User research & interviews
User research & interviews

Product requirements and user feedback came directly from the client — who is embedded in the logistics industry.

Client

💻

Development & engineering
Development & engineering

Handled by the startup's internal development team.

Dev team

The Problem

What was broken

What was broken

in the old product?

in the old product?

1

Foundation

Design system before any screen.

The old product had no system — every component was one-off. Before touching a single screen, I built the full token set: colours, typography, spacing, elevation, and base components. It cost time upfront. It saved far more across 50+ screens — screen 40 was consistent with screen 1 without going back to fix anything.

❌ Screens first, system later

✔ System first, always

2

Visual consistency

One icon library. No exceptions.

The client wanted icons from different libraries — each looked fine in isolation. Together, they would have created visual noise that signals "unpolished" without users knowing why. I held a single library throughout, even when pushed back on specific icons. Consistency users notice by its absence, not its presence.

❌ Mixed libraries

✔ Single library, enforced

3

Interaction pattern

Modals for confirmation. Bottom sheets for everything else.

Set one clear rule early and applied it across every screen: modals for irreversible actions (delete, logout), bottom sheets for input and selection (expense type, fleet picker, filters). No new pages for secondary actions. The result is an app that feels intuitive — users always know where they are.

❌ New page/modal for every action

✔ Modal vs sheet — one global rule

4

Most impactful UX decision

Add Beneficiary is a flow — not a form.

The old screen stacked every field — personal, bank, UPI, type-specific — into one endless scroll. I broke it into a stepped flow: choose method → verify account → add details. Each screen has one job. The bank verification result — "KARAN RAMESHBHAI MEHTA — Verified" — becomes a distinct moment of trust rather than a buried field. That confidence is the product.

❌ Single long-scroll form

✔ Stepped flow with verification moment

Contact

I work with founders building SaaS products, fintech platforms, and complex internal tools.
If you're looking for strategic product design, not just screens, let's talk.

Contact

I work with founders building SaaS products, fintech platforms, and complex internal tools.
If you're looking for strategic product design, not just screens, let's talk.

Contact

I work with founders building SaaS products, fintech platforms, and complex internal tools.
If you're looking for strategic product design, not just screens, let's talk.
Truckpay - Fleet Expense Management

Case study · Freelance UI/UX Design · March 2026 – May 2026

Solo Designer · 50+ Screens · Design System from zero

Solo Designer · 50+ Screens · Design System from zero

Create a free website with Framer, the website builder loved by startups, designers and agencies.