The planning window is an update that has been worked out and a flight to release after intensive long work. As part of the task, the Advantum team updated the tool in the system

The ATMS system is a service for routing and delivering cargo across the Russian Federation and the CIS. The planning tool is one of the options in the interface, where the user, based on requests from stores, a purchase schedule or a schedule of deliveries to warehouses, or simply a daily/monthly/annual plan, forms trips (trips are trips that trucks make. First, the vehicles load products from the supplier, and then take them to the addresses of retail stores), and then provides support throughout the execution of this trip, which can last from a day to several weeks.

It is necessary to update the version of the planning window, providing maximum functionality for working with orders, planning and routes.

It is necessary to provide the user with the ability to perform most of the routine actions within one window.

The main functionality of the planning window:
1) Working with orders
2) Working with the vehicle fleet
3) Working with routes
4) Working with planning
5) Geofences

Step 1. Start of the sprint

ATMS is a single integrated system with a default set of functions that varies depending on the consumer's goals. As soon as a new retailer connects to the system, the admin grants the user access to a personal account, where "OOO Technologies of the 21st Century" is added to the ATMS name (for example), so this user can freely change the product to suit their own needs.

Each of these versions already has the functionality that we want to collect in one workspace implemented in one form or another. We just need to take ready-made modules, take into account inconvenient points in work and design a single window in the style of the ready-made design system.

Step 2: Research

We tested how each of the individual functions works, wrote down the flow and asked employees about the problems that arise during the work process. Analytics showed that even experienced specialists do not know the software perfectly

For example, not everyone could tell what the icons depict. This is understandable: the lion's share of requests concerns loans and other popular products, and operators know all the interfaces associated with them perfectly. And the rest of the software is needed in rare cases or generally refers to no longer relevant services

Step 3. Design

I put together warframes to roughly decide on the layout of the content.
There were a few things that were extremely important and were the focus

1. In the left bar, you need to select a car
2. In the center, timeline, to see the flight
3. On the right, applications (for flights)

Why such a hierarchy? It's simple, the task was to connect the car and the flight and see the planned route displayed on the timeline, and if there are several routes, then see everything that is there
By clicking on the request, the operator is taken directly to a page divided into three parts. In the upper left part is the answer to the client's request, in the upper right - answers that may also relate to the request

Step 4. Working out the layouts

We regularly made syncs, discussing what would be better to remove, what to add, each sync we went through the flow anew, figuring out how we could shorten the click or shorten the information so as not to burden the user with unnecessary actions

Step 5. Detailing

We have drawn all the sections and assembled a prototype.
We have assembled a framework for an important system planning window, and it is flexible enough to accommodate other services.

The main thing is that the MVP convincingly shows how much simpler and more convenient the new is than the prospect of jumping into sections and tabs. And this is precisely the powerful argument that will speed up flight planning and the number of processed requests per day per person. We asked the head of the dispatch center to test the prototype on employees

Live version