Digital Logistics Platform

Overview and Product Context

Digital Logistics Platform / “Digital Freight Forwarder” is an operational logistics platform for freight transportation. The product connects client requests, logistics managers, carriers, drivers, transport companies, routes, documents, checks, and trip statuses.

The project started under conditions of high uncertainty. At the beginning, there was no mature product logic, ready design system, or complete documentation. There was a basic description, fragmented materials, and several UX sketches in Miro. The task was to turn this context into a clear product structure and prepare interface materials for MVP development.

The main complexity was that the product did not work like an open marketplace exchange where all participants see each other directly. For clients, there was only the “Digital Freight Forwarder,” while the internal operational logic — logistics managers, carriers, drivers, transport companies, document checks, and trip allocation — remained inside the platform.

That is why the interface had to be designed as a closed operational system with roles, permissions, statuses, checks, and different levels of visibility.

Area of Responsibility and Scope of Work

The main task was to take a high-level product idea and assemble a UX structure that could be handed over to development without losing scenario logic.

The work included:

• analysis of the domain, key entities, and relationships between them;
• design of a role model for the director, logistics manager, and security team employee;
• design of the web interface for the freight-forwarding side;
• design of mobile scenarios for drivers, individual entrepreneurs, and transport companies;
• work through the lifecycle of requests, trips, routes, documents, and statuses;
• design of carrier, driver, and vehicle verification by the security team;
• preparation of components, states, and repeatable interface patterns for the MVP;
• handoff for development and support in clarifying interface behavior.

Role Model and Access Rights

The web interface was divided by operational roles.

The director saw the overall picture: analytics for requests, money, managers, carriers, and the security team. They had access to client base management, request redistribution, work with carriers, and a broader set of administrative actions.

The logistics manager worked with the operational flow: created and processed requests, split and merged them, selected carriers, worked with the carrier base, and monitored trip statuses. At the same time, access to global financial analytics and some administrative entities was limited.

The security team employee worked in a separate verification contour: saw a queue of organizations, drivers, and vehicles; checked documents; recorded comments; assigned risk groups; and decided whether transport providers could be admitted to work.

The mobile contour was more complex than a regular driver app. It had to support several scenarios: an independent owner-operator driver, a transport company, a driver inside a company, and the head of a transport company who manages their own resources and can participate in trips.

Request Lifecycle

A request was one of the central entities of the product. It connected the client, route, cargo, transport requirements, documents, deadlines, cost, carrier, and the subsequent trip.

The request card had to quickly show the key operational context: where the cargo is going from and to, what needs to be transported, what requirements exist, what the deadlines are, which documents are already attached, and what action should be taken next.

A separate complexity was the scenario of splitting and merging requests. In logistics, one client request can be divided into several trips because of transport, route, cargo, or cost constraints. For this, an interface mechanism was designed to preserve the connection between the original request and child trips without losing documents, numbers, or conditions.

Contextual Carrier Search

Carrier search started from the request. Instead of forcing the logistics manager to manually rebuild filters from scratch, the system had to prefill parameters from the request itself: direction, weight, volume, vehicle type, temperature requirements, search radius, and risk group restrictions.

As a result, the logistics manager received not just a list of carriers, but a working surface for comparison: organization or individual entrepreneur, driver, vehicle, rating, risk group, security team comments, recent directions, and available actions.

This scenario reduces the risk of error: search is not built from zero, but from the conditions of a specific request.

Carrier Verification and Security Team

A carrier, driver, or vehicle should not enter the operational flow immediately without verification. That is why the product had a separate security team contour.

The security team employee worked with a queue of checks, documents, comments, risk groups, and access statuses. A check could relate to an organization, driver, or vehicle. The result affected whether the transport provider could participate in trips and how they appeared in search.

This layer was important for the entire system. The logistics manager had to understand whom they could send a request to, where there was risk, which documents had already been verified, and which constraints had to be considered.

Mobile Scenarios for Drivers and Transport Providers

The mobile app had to work not as a simple request feed, but as a tool for participating in a trip.

The user could be an independent owner-operator driver, a transport company, a driver inside a company, or the head of a transport company. That is why onboarding, document verification, adding resources, and participation in requests depended on the organizational context.

After admission, the user could view available requests, respond to them, assign resources, participate in a trip, and maintain route statuses.

Route Execution Scenario

The mobile interface had to guide the driver or transport provider through trip execution: accept participation, assign resources, start the trip, mark statuses along the route, report problems, upload documents, and complete the work.

Special attention was required for trip statuses. For a logistics product, they are not decorative labels, but working events that help synchronize the driver's mobile app and the logistics manager’s web panel.

Uploading closing documents was also an important part of the scenario. The interface had to support document photos through a smartphone camera, upload states, errors, and confirmations.

Interface System and Data Density

The product required two different levels of interface density.

In the web part, high information density was needed: tables, lists, filters, request cards, right-side panels, modal windows, and quick actions. A logistics manager or director had to see many requests, statuses, and risks at once without opening a separate screen every time.

The mobile part, by contrast, was built as a more step-by-step scenario: one main action per screen, large interactive elements, bottom navigation, bottom sheets, trip statuses, and clear document upload states.

The system included:

• request, trip, and verification statuses;
• risk group labels for carriers and resources;
• route timelines with route points;
• cards for requests, carriers, organizations, drivers, and vehicles;
• filters and collapsible filters;
• action menus for lists and tables;
• document upload and preview components;
• empty, success, warning, and error states.

Handoff and Result

The outcome of the work was an MVP-ready design delivery: a set of screens, scenarios, states, components, and explanations of interface behavior. These materials gave the development team a clear foundation for building the MVP and helped reduce ambiguity during implementation.

The result was not only a set of mockups, but a product structure: roles, entities, statuses, routes, checks, mobile scenarios, and interface patterns that could be used in development.

Public-safe Presentation

The current portfolio version of the case is presented as a public-safe static case. It does not disclose the commercial context, real company names, source code, or confidential documents.

The public version shows product complexity, UX logic, screen families, interface patterns, and an updated visual layer that helps present the case without revealing confidential materials.

It is important that the modern redesign is not the main result of the project here. The main result is the real UX decomposition of a complex operational product and an MVP-ready handoff. The updated visual layer serves as a public presentation form for this experience.

What This Case Shows

Digital Logistics Platform shows experience with a complex operational product where the interface must account for roles, permissions, routes, documents, checks, statuses, and different working contours.

The case is important as an example of how a raw product context can be turned into UX architecture, screen families, mobile scenarios, and a handoff that enables the team to move toward an MVP.