DP World
Understanding what already existed.
Three platforms, examined before anything was drawn.
Before designing, we audited Compass in the UK, Mawani in the UAE, and Bharat Trade in India, comparing their capabilities and how users completed the same tasks.
Workshops with company administrators, port operators, product teams, and employees awaiting approval revealed why the platforms differed. Together, these findings shaped one set of to-be flows that reduced repetition while preserving genuine regional constraints.
| Capability | Compass | Mawani | Bharat Trade |
|---|---|---|---|
| Register vessel | ≠ | ✓ | ≠ |
| Service schedule | ✕ | ✓ | ≠ |
| Berthing advice | ✕ | ✓ | ✕ |
| Holds and releases | ≠ | ≠ | ✓ |
The same capability rarely behaved the same way twice, which is what made a single master design necessary.
Where the legacy platforms broke down.
Findings from the three platform audits were grouped into seven categories. The scores show the relative severity of issues across the platforms. Navigation and data entry contained the highest concentration of severe problems, which is why guided flows and inline validation became early priorities.
Registering a single vessel required three separate services.
First the vessel, then its service schedule, the list of ports that vessel will call at, and finally each individual port visit. Every step asked users to re-enter information the system already had.
Screens and clicks counted for the same task on each platform. The count is what settled the argument.
Design once, configure per country.
Customs documents, tax identifiers, free zone declarations and privacy rules differ by country but the way a port works does not. Flow, hierarchy and error prevention stay identical everywhere, while terminology, document requirements and rules configure per jurisdiction.
Build the shared foundation first.
Cargoes Core established one design language, shared components, reusable patterns, and full-page templates on a Material foundation. Building these layers first meant every new service inherited a consistent structure instead of solving the interface again.
Ship in phases, carry everything forward.
Voyage & Manifest was divided into three releases: Vessel Visit, Import, and Export. Each phase went live before the next began, so real operators could validate the workflow and proven navigation, status, validation, and data-entry patterns could carry forward. By Export, much of the interaction model had already been tested in production.
By Export, most of the release was parts that had already been proven in production.
Tracking a vessel, and everything inside it.
Voyage & Manifest tracks vessels and their contents worldwide. It gives shipping lines, importers, exporters and customs the controls that matter: change a status, apply a hold, resolve it, and release a container for delivery.
Vessel Visit
A Vessel Visit is the record of a ship calling at a port. The redesign added live tracking of the vessel and the route it is expected to follow, so everyone waiting on it can see where it is.
Inside the manifest
A manifest breaks down until every owner's share of every box can be tracked on its own.
Live tracking, end to end
Each level carries its own state, and the levels have to agree. Connecting all of it together was the point. Tracking is only correct when the vessel, the unit and the cargo tell the same story.
Preventing errors before they blocked cargo
Status visibility was only useful if the underlying records remained consistent.
Quantities entered at the Unit, Cargo, and Consignment levels had to reconcile before a manifest could be released. A generic error message would have forced users to search through several levels of data to find the problem.
- Which level contained the mismatch
- The expected and entered quantities
- The specific record that required correction
Release of the manifest remained blocked until the discrepancy was resolved. This moved error detection earlier in the workflow, before the manifest reached customs or delayed cargo release.
Validation connected errors to the exact record that caused them, rather than leaving operators to search through the manifest.
The first thing every customer did, and the worst thing they experienced.
Three roles sit in one loop: an admin registering the company, a terminal operator approving it, and an employee who cannot work until both are done.
One chassis for 50+ services.
Three navigation levels give every service the same shape, whichever module you are in.
Audit
Multiple companies and roles work the same records, often on the same day. Every change needs a trail, so the audit view records who changed what and when, with the old value beside the new one. A disputed release can be traced rather than argued about.
Editable table
These are data heavy screens. Tables and forms have to carry every field an operator needs while staying readable, so density, alignment and inline editing were solved once as a pattern rather than per screen. Row selection, status and pagination came with it.
2020. Britain left the EU.
Overnight, freight crossing a UK border needed customs formalities that had not existed the week before. Ports had weeks to comply, not quarters.
BEEMS, Border Entry and Exit Movement Services, could not wait for Cargoes Core to be finished. It shipped on a design system that was still under construction.
The deadline turned an unfinished system into a live test. Patterns that survived BEEMS had been proven under the hardest conditions the platform would ever face, and the ones that did not survive were corrected before fifty other services inherited them. Once Core was complete, I pushed to migrate the module onto it properly rather than leave it as a permanent exception.
Then the system got tested, twice.
Invoice & Contracts reused Cargoes Core layouts and Voyage patterns, keeping the design effort focused on commercial logic. Reports & Dashboards reused the same structure for cross-module data, while new charting patterns were added back into design keeping the system reusable and evolving.
What the platform delivered.
Adoption among Shipping Lines in UK using Import Manifest; onboarding across company registration, contracts, and billing.
New services reused established patterns, and new markets became configuration rather than redesign.
Invoice & Contracts reused Cargoes Core layouts, while Reports & Dashboards extended the same system with reusable data-visualisation patterns.
COO, DP World · Sep 2021
Q1 FY’22 · Compass Logistics Platform
I could not have shipped this module without her.
Product Manager · Voyage & Manifest
Four things this platform proved.
Foundations have to exist before the pressure arrives.
BEEMS proved both halves. Shipping without the system was expensive, and the system only absorbed it because it was already underway.
Alignment built together holds. Alignment presented gets reopened.
Journeys co-created with the people doing the job survived review. Journeys shown for approval came back.
One design travels only when the universal is separated from the local.
The same flow in every port, with a different rulebook configured underneath it.
Evidence closes arguments that opinion cannot.
Click counts and adoption data ended debates. The wins that were not measured are the ones that cannot be proven now.