Introduction
MarSol is a water bottling company with a daily delivery operation based on routes, frequent customers, and operational knowledge accumulated by its drivers.
The problem was that much of that knowledge was not documented in any system. The routes existed, the customers existed, and the operation worked, but many of the important details lived in people’s memory, in phone calls, in personal notes, or in the specific way each driver organized their work.
As long as everything went well, the model could seem good enough. The generous detail, as usual in real operations, appeared when a route changed, when a new driver joined, when someone had to cover a route due to illness or vacation, or when administration needed to know what was happening in real time.
The project consisted of creating a digital ecosystem from scratch, composed of a mobile app for drivers and a web platform for administration. The app had to support fieldwork without interrupting it. The web dashboard had to turn a low-visibility operation into something that could be managed, monitored, and maintained.
The problem: the routes were clear, but only to the people who already knew them
Before the project, MarSol did not have a formal system to manage delivery routes. Administration knew the general base of some routes, but the daily details depended on each driver.
Some drivers carried the information in their heads. Others used personal notes. Others simply worked from accumulated experience. Very practical, of course, until someone else needed to understand the route.
This created several operational problems:
- If a route was updated, administration did not always have clear visibility into the change
- Frequent customers on each route were managed individually by each driver
- If a driver could not cover their route, the person replacing them usually did not know the customers, references, or particular agreements
- Training depended on accompanying a route for a few days and memorizing it
- There was no reliable census of customers, special prices, references, or specific delivery dynamics
- Operational communication happened through phone calls or messages, without a single channel or consistent traceability
The operation was not stopped. That was not the point. The problem was that it depended too much on informal knowledge.
Project impact
This case does not yet have publishable quantitative metrics on efficiency or savings, since the product is still evolving. Even so, the structural impact of the project is clear.
- Product created from scratch, from research to production
- Mobile app for drivers
- Web dashboard for administration
- Real-time monitoring of routes and drivers
- Operational history of approximately three months
- Centralization of routes, customers, drivers, and prices
- Automatic customer visit registration through geolocation
- Shared UI Kit between mobile app and web
- Tokens exported to design and development with Tokens Studio
- Training for administrators and drivers
The most important result was not simply having an app or a dashboard. It was turning dispersed operational knowledge into a shared platform.
Objectives
The project had to solve a complete operation, not just design screens. The main objectives were:
- Create a mobile app that helped drivers execute their routes without unnecessary friction
- Create a web platform so administration could manage drivers, routes, customers, and prices
- Enable real-time monitoring of the operation
- Register relevant route activity without depending on manual reports
- Reduce dependence on each driver’s individual memory
- Support the training of new drivers
- Create a centralized source of information about customers, routes, and special agreements
- Build a product that could be used by people with low technological familiarity
The solution had to work for the people in the office and for the people in the field. And those two worlds do not always have the same patience for one more screen.
My role: defining the experience and building part of the product
My participation was divided between design and development.
On the design side, I collaborated in user research, mainly through interviews with drivers, administrators, and business owners. I also participated in experience architecture, flow definition, prototyping, and UX supervision of the product.
The visual UI was handled by another person on the team, so my contribution focused on how the system should work, how the mobile app and web platform should connect, and how to translate the real operation into digital flows.
On the development side, I participated in the frontend implementation of the web dashboard with React, building screens and components for the administrative platform.
Research: understanding how the route actually worked
The project began with research to better define the product idea. Since there was no previous platform, there was also no existing system to redesign. There was an operation to understand.
We conducted interviews with:
- 6 drivers
- Administrators
- Business owners
The research confirmed that the problem was not only the lack of digitalization. It was the way operational knowledge was transmitted, updated, and lost.
What we discovered
Memorized routes created operational dependency
Experienced drivers knew their routes, but all of them mentioned that memorizing them was difficult when they first started.
This was especially critical for new drivers or for people who had to temporarily cover a route. Training could last around a week, and during that period the person had to learn the route, customers, references, and ways of working.
In practice, the route was not learned from a system. It was learned by accompanying someone else and hoping memory would do its job. A bold methodology, considering the person would later have to operate without room for error.
Information was not shared consistently
Information about customers, prices, and special agreements could vary depending on the driver.
A customer could have a particular price or receive specific treatment for a certain reason. If another driver arrived, that knowledge was not always available.
Because of that, each customer needed to concentrate information such as:
- Address
- References
- Name
- Contact information
- Special price, if applicable
- Particular delivery considerations
There was no single channel for operational information
Communication happened through phone calls or messages, depending on the situation. This made it difficult to maintain clear traceability of changes, departures, route closures, or important information for the operation.
Drivers also had to report by phone when they started or finished a route. Some forgot. Others simply did not do it. The platform had to account for that real behavior, not an idealized version of the operation.
Technological familiarity was low
One of the most important findings was that drivers were not used to operational apps.
Among the interviewees, only one had previously used a mobile app related to their work. The rest used their phones mainly for social media, and some did not even use apps like Google Maps.
This changed the way we designed the mobile app. It could not depend on complex interactions, advanced maps, or long flows. It had to be clear, minimal, and, whenever possible, passive.
The solution
Two types of drivers, two ways of operating
During definition, we identified two main types of drivers.
Gallon delivery drivers
These drivers had to visit specific customers.
For them, the app needed to allow access to customers, addresses, references, contact information, and special prices. The system also needed to register whether they had actually passed by a customer and at what time.
Route drivers
These drivers followed a general route. They did not necessarily have to arrive at specific customers.
For them, the app had to focus more on starting the route, visualizing the route, and allowing administration to have visibility into the journey.
This difference was important because the system could not assume that all routes worked the same way. We had to design a flexible structure for two operational models within the same ecosystem.
Designing a mobile app that asked for as little as possible
The biggest design challenge was the mobile app.
Not because of its visual complexity, but because it had to generate operational information without becoming a burden for drivers.
The main decision was to make the experience as passive as possible. The app had to capture relevant information without requiring the driver to constantly interact with it.
The main flow was deliberately simple:
- Start route
- Check necessary information during the operation
- End route
The best interaction was the one the driver did not have to perform.
This was especially reflected in visit registration. For gallon delivery drivers, the app used geolocation to detect whether the driver crossed the perimeter established for a customer. When there was a match, the system automatically registered that the driver had passed by that location.
There was no need to open a screen, search for a customer, press a button, and confirm an action. The app registered it in the background.
Designing for real mistakes, not perfect users
The app also considered situations that could happen during daily operations.
If a driver did not start their route within a certain time window, the system could communicate it to administration. If someone forgot to end the route, the system could automatically close it at a time when there was no longer active operation.
This was important because the product could not depend on every user doing everything correctly every day.
The design had to assume forgetfulness, interruptions, low technological familiarity, and work in motion. In other words, it had to resemble the real operation more than a perfect presentation flow.
An internal help center for information that was previously unavailable
In addition to routes and customers, the app included an internal help center.
During research, we identified that drivers needed operational information that was not always given to them clearly, such as vehicle insurance information, internal documentation, or guides on how to handle certain situations with customers.
The help center aimed to centralize that information so drivers could consult it when they needed it.
It was not a decorative section. It was a way to reduce dependence on phone calls, messages, or informally transmitted knowledge.
The web platform: making the operation visible
While the mobile app supported drivers, the web dashboard was designed for administration.
The platform made it possible to manage:
- Drivers
- Routes
- Customers
- Standard prices
- Special prices
- Assignments
- Real-time monitoring
- Route history
The main view was the real-time monitor. From there, administration could see the current location of drivers, the journey completed, the full route, and each person’s status.
They could also focus on a specific driver to review their activity in greater detail.
Real-time monitoring
The dashboard showed a timeline with the driver’s activity, including:
- Route start
- Journey completed
- Stops or pauses
- Route continuation
- Customer arrival
- Route closure
Each event could be visualized on the map to understand where it had occurred.
For gallon delivery drivers, administration could review how many customers had been visited and at what time. For general routes, they could review the route progress and status.
The system also stored operational history, which made it possible to review past activity instead of depending only on live monitoring.
Creating routes, customers, and prices from a centralized source
A key part of the web platform was the administration of base data.
Before, many operational details were distributed across people. With the dashboard, MarSol could register and manage information from a single place.
The platform made it possible to:
- Create drivers
- Create customers
- Register addresses and references
- Manage contact information
- Define standard prices
- Assign special prices
- Create routes
- Assign customers or journeys depending on the type of driver
This made the operation more maintainable. If a route changed or a customer had a special condition, that information could be updated in the system instead of remaining trapped in one person’s memory.
A shared UI Kit between app and web
Since the project started from scratch, there was no previous UI Kit or established visual base for the product.
A UI Kit was created to give consistency to the mobile app and the web dashboard. Both environments shared styles, components, and visual criteria.
Tokens Studio was also used to connect design and development. Tokens did not only live in Figma, they were also exported to development to maintain greater consistency between what was designed and what was built.
This helped the ecosystem feel less like two separate products and more like two interfaces of the same operational system.
Results
The product reached production and is currently being used by MarSol.
Although there are still no publishable quantitative metrics, the project generated a structural change in the operation:
- Routes no longer depended only on each driver’s memory
- Administration gained real-time visibility into drivers and routes
- Customer, pricing, and reference information was centralized
- New or substitute drivers could rely on documented information
- The operation began generating consultable history
- The company gained its own platform to manage delivery operations
The result was not simply digitizing a route. It was creating an operational foundation so MarSol could manage what previously depended on individual experience, informal communication, and memory.
Conclusion
The biggest learning from the project was that not every digital transformation starts with a clear product idea. Sometimes it starts with an operation that works because people have learned how to sustain it manually.
At MarSol, the routes already existed. Drivers were already working. Customers were already being served. But the system did not exist.
Creating the mobile app and web dashboard made it possible to turn that operational knowledge into a shared platform between fieldwork and administration. The app helped drivers without demanding unnecessary interactions. The dashboard gave administration visibility, control, and history. And frontend development made it possible to bring part of that definition into a real product.
The route was there. What was missing was the system.