01 / DRIVER EXPERIENCE
Designing for people working beyond the desk.
Redesigning the delivery experience around how drivers actually work—from loading the truck to completing the delivery.
ROLE
Lead Product Designer
TIMELINE
2022-2026
SCOPE
Research · UX/UI · Prototyping · Testing · Design System
USERS
Drivers
Delivery Helpers Operations Teams
About this case study
This work involved proprietary enterprise products. Visuals have been recreated and simplified using fictionalized data to protect confidential company information while accurately representing my role and design approach.
02 / THE CHALLENGE
The app worked.
The experience didn’t.
The existing Driver App supported critical delivery tasks, but years of growth had created an experience that was difficult to navigate and increasingly difficult to scale.
Drivers described endless scrolling, unclear task requirements, slow performance, frequent logouts, and an experience that didn’t always feel intuitive in the field.
Different deliveries also required different actions like photos, signatures, notes, checklists, haul-away documentation, installations and more. Drivers often had to scroll through the experience just to determine what they needed to do next.
The challenge wasn’t adding more. It was creating an experience that could grow without making the driver’s job harder.
03 / GETTING INTO THE FIELD
I couldn’t redesign the job from a desk.
I spent time at XDTs during morning truck loads, talked with drivers and operational leadership, observed check-in and check-out, visited stores and completed ride-alongs to watch deliveries happen in real conditions.
I even ordered deliveries myself to understand the customer side of the experience and documented the full end-to-end journey for leadership.
That fieldwork continued throughout the design process through concept testing, pilots, interviews, analytics, support feedback and usability testing.
FCFBF8
05 / DESIGNING THE WHOLE DAY
The experience had to work from first load to final delivery.
06 /SCAN TO LOAD
The simple idea that wasn’t simple at all.
Scan an item. Confirm it belongs on the truck. Move on.
That was the idea.
In reality, Scan to Load had to account for damaged or missing barcodes, duplicate scans, incorrect quantities, manual loading, accessories, exceptions, photo documentation, and incomplete orders, all while drivers were moving quickly through a warehouse.
Working closely with my Product Manager, I mapped the workflow and its edge cases through repeated iterations, prototypes, testing, and driver feedback.
What began as a seemingly simple interaction became a system drivers could rely on to verify products, understand what was still missing, recover when something went wrong, and confidently complete the load. The concepts included item-level scan status, manual-load paths, exceptions, accessories, and a final review before manager sign-off.
Instead of asking routers to work around the system, we began teaching the system how their operation actually worked.
07 /DESIGNING FOR THE REAL WORLD
Small interactions mattered when drivers were moving fast.
Drivers repeatedly told me they were accidentally tapping Arrived because of its placement near their thumb. It sounded like a small usability issue, but an accidental tap could affect arrival data and operational metrics, even if the driver was still a minute away.
The initial business preference was to rely more heavily on geolocation. But field feedback showed that drivers still needed control over when they officially arrived.
I proposed replacing the single-tap action with Slide to Arrive—adding just enough friction to prevent accidental activation without slowing drivers down.
Sometimes better UX isn’t removing friction. It’s adding the right amount of it.
08 /TESTING IN THE REAL WORLD
Driver feedback changed the product.
I validated concepts throughout the design process using prototypes, usability testing, driver interviews, pilots, analytics, support feedback, and continued visits to delivery locations.
The most useful feedback often challenged what seemed logical on paper.
One example was photo documentation. The business initially wanted separate areas for different photo types like delivery, installation, haul-away and more. But drivers consistently told us that categorizing photos would slow them down during an already fast-moving delivery.
That feedback helped us prioritize the reality of the workflow over adding unnecessary structure.
The best solution wasn’t always the most organized one. It was the one that worked when someone was standing in a customer’s driveway.
09 /DESIGNING FOR MORE DRIVERS
The experience needed to work for everyone using it.
The Driver App supported a diverse workforce across Lowe’s employees, third-party delivery teams, and helpers working in different locations and conditions.
As the product evolved, that meant thinking beyond individual workflows and designing an experience that could scale across languages, roles, delivery types, and new capabilities.
One important step was introducing a Spanish-language experience so drivers could use the app in the language that worked best for them.
But localization wasn’t simply replacing English words with Spanish ones. The interface had to accommodate differences in text length while preserving hierarchy, clarity, familiar interaction patterns, and the speed drivers depended on in the field.
Scaling a product meant designing a system flexible enough to serve more people without making the experience more complicated.
Shortly before my departure, a location operated by a partner with its own internal routing solution began onboarding to our platform which was a meaningful signal of how far the product had come.
LORI BRODERSEN
UX PRODUCT DESIGN + PRODUCT MANAGEMENT