←  back to the desk

COLOUR
PALETTE

Making Complex Air-Cargo Operations Visible, Predictable, And Easier To Execute.

Kargo360 is a two-sided operational product: A2A for airside flight and manifest operations, and D2D for pickups, trucking and delivery. The redesign focused on the hidden workflow underneath the UI — and on making that workflow legible to the people operating it.

Brief

Air cargo moves through a chain of custody, and at every handover somebody has to tell a system what just physically happened. A ULD arrives. It gets broken down. Pieces get assigned to a cart, a cart to a flight, a flight to a manifest. On the road, a pickup is assigned, collected, consolidated into a motherbag, trucked, and delivered.

Kargo's two apps cover both halves of that chain — A2A airside and D2D on the road — and the same company's staff move between them.

The brief was not simply to modernise the interface. It was to make the product usable by people wearing gloves, standing up, in a hurry, without relying on training to explain what the system was doing.

So the design question

How might we make the workflow visible, so the app stops teaching by punishment?

The Audit

I worked from two independent inventories: 119 captures taken in the field and the engineering team's own 126-screen build deck. Together they covered both apps end to end — crucially including error and success states, where the real evidence turned out to be.

I ran a heuristic evaluation and grouped findings by severity. The same issues repeated across otherwise different modules, which suggested a systemic problem rather than isolated UI defects.

The Root Cause

The error messages were the specification. Auditing the failure states is where the project turned. The errors were not random. Each one encoded a business rule the software already knew, revealed only after the user broke it.

what those six rules add up to

Read together, the errors describe a complete state machine. The software enforced it perfectly; the interface rendered it nowhere.

Who’s holding the Phone

Nobody is sitting down. Both apps are used in the field, and the field is hostile to the interface patterns the old product relied on: tiny two-column inputs, text-only menus and transient toasts. I designed around three recurring operator contexts.

Environment is the requirement

A two-column input is a desk pattern. On an apron in daylight with gloves on, the usable unit is a card you can read at arm's length and a button you can hit without looking.

What I decided

Four rules, applied to both apps.

Rebuilding A2A

A2A is the harder of the two because the domain genuinely is complex: a cart holds pieces, a ULD holds carts, a flight holds ULDs, and a manifest describes the flight. The old interface flattened those relationships into repeated input rows.

The redesign gives each operational object a clear identity, data hierarchy, state, and set of legal actions.

the object model, drawn once

This is the diagram the old app never showed. Containment runs outside-in, and every level carries its own state — which is exactly what the error messages were policing.

Manifest sits alongside rather than inside: it describes a flight's contents at a point in time, which is why "flight must first be manifested" was a sequencing rule and not a property of any one object.

Patterns that Scale

Break ULD is a useful example because the underlying data did not change. The redesign focused on legibility, grouping and interaction quality on a screen that could be used on an apron.

break uld, before and after

and the dialog that appeared everywhere

Rebuilding D2D

D2D was where restraint mattered more than invention. Its information architecture was already correct: Booking, Firstmile, Trucking, Motherbag and Lastmile. Re-architecting it would have destroyed useful muscle memory.

So I kept the structure and changed what the structure could communicate: priority, state, movement and next action.

The pickup card

assignment and structured reasons

Structured reasons and bulk assignment both already existed — more sound thinking buried under its own presentation. The reason picker was an inline block that appeared mid-card, pre-flagged red, before the driver had done anything.

So the redesign keeps the logic and rebuilds the moment: assignment moves into a sheet with its own two decisions and nothing competing; the reason list becomes a clean radio set where remarks appear only for Other; and the outcome takes the whole screen instead of sliding over the card you were reading.

Recognition over recall

Special Handling Codes are controlled operational vocabulary. The legacy experience gave users a text box and expected recall. The redesign makes them searchable and multi-selectable in a focused sheet.

The system is visible

The whole project reduces to one change in the order of events.

What i’d test next

The redesign is grounded in a 119-screen field audit, the engineering build deck, and domain reasoning. It has not yet been validated on an apron or in a live driving context. I would keep that limitation explicit rather than claiming outcomes the project has not measured.

The next research sprint would watch four ramp agents and two drivers complete real work, then measure the moments where the redesigned state model is expected to matter most.