Desktop borderò The starting point: a dense operational desktop view used to print driver instructions.
MotoHelp case study
Digitising motorcycle logistics for real couriers, not "just" users.
MotoHelp is an internal mobile app designed for a company that manages motorcycle pickup and delivery across Italy. The goal was to replace paper-based workflows with a simple, reliable tool that drivers could actually use on the road.
Context
From printed sheets to a mobile workflow.
Before the app, drivers worked with paper instructions generated from a desktop management system. That worked, but only until reality happened: new addresses, calls, delays, route changes, payments, photos, damaged vehicles and operational updates.
Timesheet / cartellino Operational admin screens helped define what drivers needed to update from mobile.
The real problem
The challenge was not making it fancy. It was making it obvious.
The average courier using the app was not expected to be a tech expert. The interface had to survive real working conditions: pressure, time constraints, phone calls, traffic, weather and a van full of motorcycles.
Paper was doing too much
Drivers were relying on printed borderò sheets, phone calls, WhatsApp messages and manual updates while working on the road.
Information changed often
Addresses, contacts, fees, appointments and pickup details could change after the paper sheets had already been printed.
Drivers were not power users
The app had to work for people who were not necessarily confident with technology, under pressure, inside a van, during real deliveries.
Design principle
No fancy design circus. Just a tool that had to work at 7:00 AM, inside a van, with a driver who has no time to decode the interface.
Driver questionnaire
Real answers from the people who had to use the app.
Since the budget did not allow for a full research phase, I created a focused questionnaire to capture the drivers’ daily workflow, pain points and expectations. The goal was simple: understand what had to be obvious, fast and impossible to misunderstand.
The driver loads the motorcycles onto the van at the depot, following the loading sheet, then leaves usually between 5:00 AM and 8:00 AM depending on the daily schedule.
Before leaving, they study the stops, distances, loading and unloading sequence.
Printed borderò sheets with addresses, customer names and phone numbers.
GPS navigation.
Mobile phone for Google Maps, customer calls and office communication.
No previous experience with similar work apps.
It could optimise working time, reduce paper as much as possible and improve communication with the operations office.
Drivers could send additional information, report completed pickups and deliveries, and avoid having to call every time.
Fast updates between office and driver for all the information usually printed on paper.
Frequent changes include addresses, names, phone numbers, extra packages, license plates, fees to collect, new pickup or delivery appointments and appointment order changes.
Drivers also need to take photos during loading or unloading and report the motorcycle condition or undeclared issues.
Electronic transport documents, digital signatures, digital completion of vehicle condition forms and email delivery of documents to the customer.
A map to mark overnight stops, lunch breaks, traffic, accidents and closed roads would also be useful.
Mostly through phone calls and WhatsApp.
Process
A pragmatic Product Design process.
I would have loved to run the full textbook UX process, but there was no time and no budget to follow the entire UX process, so I compressed the process around the steps that could create the most value.
01
Business input
The CEO explained the operational pain points, the current desktop workflow and the need to move from printed sheets to a digital driver tool.
02
Requirements mapping
I studied the application requirements, desktop screenshots and borderò documents to understand what information drivers needed on the road.
03
Lean research
Because of budget constraints, the research process had to be reduced, but I still created a questionnaire to collect real driver insights.
04
Prototype iterations
I created and tested multiple prototype versions with the team until we reached a balance between business needs and driver usability.
05
Functional UI delivery
Motion and visual polish were intentionally reduced where they did not help the user. The priority was clarity, speed and operational reliability.
Information architecture
Reducing complexity into a driver-first structure.
The architecture focused on the essential operational areas: login, home, trip, van, route details and profile. The goal was to keep the mental model close to the drivers’ existing work routine.
Large diagram preview
Open full image
↗
Lo-fi wireframes
Early screens helped validate the main flows before
moving into higher fidelity prototypes.
Final solution
The improvements that turned paper work into a usable mobile workflow.
The final interface was not designed to impress with visual effects. It was designed to reduce operational friction: fewer calls, less paper, clearer statuses, faster confirmations and better visibility while drivers were actually working.
Design focus Clarity over decoration
Every feature had to support a real action on the road: understand the trip, manage the stop, document the vehicle and complete the task without decoding the UI.
Digital borderò
The printed operational sheet became a digital trip hub with the information drivers needed during the day.
Route and stops
Current and upcoming stops were organised into a clearer sequence, reducing the need to interpret dense paper instructions.
Pickup / delivery status
Drivers could understand what had to be done, what was in progress and what had already been completed.
Van loading workflow
Motorcycle loading was translated into a guided workflow, helping drivers manage space and loading order inside the van.
Cash awareness
Fees and payments became visible inside the flow, reducing the risk of missing important collection details.
Photo attachments
Drivers could document damages, vehicle conditions and operational evidence directly from the mobile interface.
Biometric confirmation
Fingerprint confirmation added a fast and familiar layer for sensitive confirmations without slowing the workflow.
Light / dark variants
The interface was adapted for different visibility conditions, from early morning starts to low-light use inside the van.
Selected screens
Interface moments that supported the workflow.
A few representative screens from the final app: loading, route details, biometric confirmation and dark mode usage.
Outcome
The best interface was not the most beautiful one.
It was the one drivers could trust while working. MotoHelp became a real internal tool designed around operational clarity, digitalisation and the daily needs of people moving motorcycles across Italy.
View real app ↗