Closer
Context
Agency managers need to havo control over their delivery areas, but they lack visual support and spend a lot of time making estimates based on multiple documents that are not always up-to-date.
Objective
Centralize and facilitate the management of delivery distribution, with information on workload and the ability to organize reinforcements quickly, without having to resort to multiple tools.
My role
I led the UX/UI design from start to finish for this project.
I worked closely with the product team, development, and operations leads to understand the key friction points and needs of the end users.
I redesigned the information architecture and key flows, logically grouping content to improve usability and considering exceptions, error states, and edge cases.
I defined and documented reusable patterns to lay the groundwork for a design system adaptable to other internal tools.
Results and metrics
Used in +80 delivery agencies
Reduced working time from 40-90 minutes to 10-15 minutes
Increases confidence in data by reducing the use of multiple sources of information.
Successfully deployed in Spain and Portugal
Working process
Research
Before starting to design, it was important to fully understand the context and the real needs of those who would be using the tool, and above all, to clearly define the problem we needed to solve.
To achieve this, I conducted interviews with key users: agency managers. I focused the interview on understanding their day-to-day tasks to better understand their way of working, and then I focused the rest of the questions on the delivery planning process. Some users had access to an older tool that was falling into disuse, so for the interviews, I decided to include sample screenshots so they could explain the tool's flaws as well as its strengths.
The interviews helped me understand not only what frustrated them, but also what improvised solutions they were coming up with to compensate for those shortcomings. For example, many obtained information from a combination of several tools, had little trust in the information, and relied on WhatsApp groups to communicate information, which made the process very unscalable.
This research process allowed me to clarify several key points:
Managers didn't have a clear, centralized view of their delivery zones.
They didn't have an easy way to identify custom zones on a map, which severely limited them from using CPs as zones.
Planning relied heavily on personal experience and making a rough guess. A less experienced user couldn't extract the same amount of information, or wouldn't know where to get it from.
There was no easy way to estimate workload or redistribute resources in real time.
With this, I was able to define a key problem to focus on:
"Delivery agency managers need a visual and efficient way to plan delivery zones, as they currently lack tools to view the territory, correctly estimate workload, and assign reinforcements in advance. This lack of visibility hinders decision-making and directly impacts operational efficiency."
The next step was to begin translating the learnings into design ideas.
Wireframes
Based on the functional requirements, I developed low-fidelity wireframes that helped me align expectations with the various stakeholders and validate the initial interface and flow ideas.
During this phase, I explored different ways to represent geographic information, visualize estimated volumes, and allow actions on specific areas, always seeking a balance between clarity and ease of use.
The main action was to create zones directly on a map, so I conducted a small benchmarking exercise. I paid particular attention to how established products such as Google Maps handled this task regarding data visualization, and Idealista to create editable zones on the map.
By sharing the wireframes with both development and business professionals, it was easier to align expectations about the product's performance and understand the technical impact of each alternative in terms of complexity and timescale.
Although the wireframes fulfilled their primary purpose, I noticed some difficulty when presenting them to non-technical people: some interpreted them as the final version of the product, despite having previously clarified that it was an initial proposal for its structure and flow. This led me to further reinforce the context and explanations in future validation sessions.
Prototyping
I designed high-fidelity screens and developed an interactive prototype to test the main flows: zone visualization, creation, and assigning reinforcement. I focused on visual clarity and data hierarchy.
To facilitate understanding, I presented the prototypes alongside short videos using Loom. This way, I was able to obtain clear and effective feedback.
With the flows validated in wireframes, I moved on to building an interactive prototype that would allow us to test the tool in a more realistic environment and facilitate conversations between technical, business, and user profiles.
The main objective was to validate the process for performing key tasks, such as creating zones, reviewing estimated load, or reassigning zones between agencies. I was also interested in seeing if the interface facilitated decision-making without the need for information from external applications.
During this phase, I adjusted microinteractions, visual hierarchies, and the way data was displayed on the map, based on feedback from internal sessions. The prototype was key to identifying small but significant improvements, such as the need to highlight unassigned areas or display charging information on hover, as well as more advanced improvements such as the ability to create zones based on specific locations or determine operating days.
Challenges and learnings
One of the main challenges was making the entire functionality understandable without overloading the interface with data.
In a first iteration, we encountered a serious performance issue: each delivery agency could have an order of 10,000 or 14,000 packages scheduled for a single day. Displaying this on the map from the start made the application very slow, even blocking some computers.
The solution to this problem came from two fronts: first, we decided not to load all the information on the map from the start, but rather to select an "arrival date at the agency" and then click a button to load the packages on the map. Second, we managed to reduce data loading times by simply changing the point markers on the map. Instead of displaying a "pin" icon at each coordinate, we decided to display only one point. This greatly reduced the number of layers rendered in the browser, optimizing data loading times.
