Fleet Management

Fleet Management

Web & Mobile

Web & Mobile

Confidential Client Project

Confidential Client Project

i11Fleet

i11Fleet

One platform, four roles, and a driver who can't stop to read

One platform, four roles, and a driver who can't stop to read

Designing across a construction fleet management platform — from role-scoped web dashboards to a mobile app built for one-handed field use.

Role

UI&UX Designer

Platform

Web + Mobile

Status

Live

Year

2026

Role

UI&UX Designer

Platform

Mobile & Web Application

Status

Live

Year

2026

No screens shown

This project is confidential — visuals withheld, process and reasoning shared throughout.

No screens shown

This project is confidential — visuals withheld, process and reasoning shared throughout.

Context

Why one system had to work for four different people

Why one system had to work for four different people

i11Fleet runs construction trucking operations — the kind of work where a contractor needs a truck moving material from a quarry to a job site, today.

The platform needed to serve an admin dispatching jobs, a driver hauling them, a carrier managing a fleet, and a client just waiting to see it done — four very different needs on one shared system.

4

Roles designed for — Admin, Driver, Carrier, Client

2

Platforms — Web (all roles) + Mobile (Driver only)

6

Work order states, each a real gate

1

Verification gate before any report unlocks

Filling a job meant calling drivers one by one

Filling a job meant calling drivers one by one

Slow, and it doesn't scale past a handful of trucks — jobs sat unfilled while someone dialed.

Slow, and it doesn't scale past a handful of trucks — jobs sat unfilled while someone dialed.

No shared record of what was actually hauled

No shared record of what was actually hauled

Haul counts came down to whoever argued harder, with no timestamped proof.

Haul counts came down to whoever argued harder, with no timestamped proof.

Status was a label, not a gate

Status was a label, not a gate

Nothing stopped an incomplete job from being billed or reported early.oject progress is rarely shown next to the day's tasks, so people end up tracking it separately.

Nothing stopped an incomplete job from being billed or reported early.oject progress is rarely shown next to the day's tasks, so people end up tracking it separately.

One interface couldn't serve four different jobs

One interface couldn't serve four different jobs

An admin's full control and a driver's one-handed field use have almost nothing in common.

An admin's full control and a driver's one-handed field use have almost nothing in common.

what came up again and again

what came up again and again

Adapted from admin and driver feedback.

"By the time I've called five drivers, the job's already gone to whoever picked up their phone first."

"By the time I've called five drivers, the job's already gone to whoever picked up their phone first."

Pin icon image

GOALS

What we set out to do

What we set out to do

Three goals shaped the direction from the start. Not all of them were equally visible to users. All of them mattered to the product.

Why does filling a job take fifteen minutes of calls?"

Why does filling a job take fifteen minutes of calls?"

"How can we speed up the
truck and load creation
work ?"

"How do you design one interface for four different jobs?"

Replace the call list with a broadcast

Push a job to every available driver at once — first to accept gets it.

Lets create AI based Voice to

Text

Lets create AI based Voice to Text

A workorder, ticket, truck anything that needs a full length form to fill can filled easily through voice to text feature.

Give each role its own scoped experience

Admin gets full control; carrier and client get narrower views; driver gets a separate mobile-only app.

APPROACH

Key product decisions

Key product decisions

Before designing screens, I worked through the decisions that would shape the whole system. Each came with a tradeoff.


Pin icon image

01

Broadcast instead of a queue

Push to all active drivers at once, auto-close when slots fill or time runs out.

Pin icon image

02

Status as a gate, not a display

A work order literally cannot close with incomplete tickets, protecting billing accuracy.

Pin icon image

03

Scope each role's view instead of hiding fields

Each role gets its own interface shaped around what it actually needs.

Pin icon image

04

Design the driver app backwards from the worst moment

Built for a driver mid-shift who won't read a tooltip — one glance, one tap.

The New i11Fleet

The complete dispatch and field system

The complete dispatch and field system

No screens shown here due to confidentiality — the walkthrough below describes what each part of the system does.

Admin Dashboard

Admin Dashboard

Work orders, tickets, live tracking, users, assets, finance modules.

Work Orders & Tickets

Status-gated lifecycle from Open through

Closed.

Broadcast Dispatch

Configurable slots, duration, and driver percentage — pushes to all active drivers at once.

Driver Mobile App

Home/ticket queue, broadcast alerts, active trip flow, document upload, profile.

Live GPS Tracking

Activates automatically when a driver starts a

trip.

Activates automatically when a driver starts a trip.

Finance Modules

Receivable, driver payable, carrier payable — auto-populated from verified closed work orders.

Broadcast Dispatch

One push, every driver, first to accept

One push, every driver, first to accept

A job goes out to every available driver simultaneously; the broadcast closes the moment all slots fill or the time window expires.

Why this matters. Replaces fifteen minutes of phone calls with a decision that takes as long as it takes someone to tap Accept.

Status as a Gate

Closing a work order has to mean something

Closing a work order has to mean something

A work order can't move to Closed until every ticket inside it is verified complete, and reports can't generate until it's closed.

Why this matters. Making sure the system physically couldn't skip a step that mattered, instead of just displaying where things stood.

Designing for One Hand

Built for a driver who can't stop and read

Built for a driver who can't stop and read

Starting a trip turns on GPS with no separate step; the camera is already open for the delivery photo; tonnage entry uses the fewest taps possible.

The decision. A driver pulled over to use an app is a driver losing time and money — every unnecessary tap had to earn its place.

Outcome

what this system changed structurally

what this system changed structurally

Specific usage metrics are confidential and withheld here — this reflects what the design changed structurally.

From one-by-one calls to a broadcast that fills in seconds.

From a status label to a status gate — no incomplete job reaches billing.

From one shared interface to four role-scoped experiences.

Reflections & Learnings

What I took away from this

What I took away from this

01
The hardest part wasn't any single screen — it was keeping four different roles reliable on the same underlying data.

Pin icon image

02

Status and permissions are part of the actual design, not backend rules layered in afterward.

Pin icon image

03

Designing backwards from the worst-case moment produces a simpler screen than designing from the best case.

Pin icon image

04

The smallest interaction detail — GPS turning on automatically — can remove more friction than an entire extra screen would.

Pin icon image

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