NEXTWAVE / SELECTED WORKCASE STUDY / FROM IDEA TO EXPERIENCE

FJORD — Shipment stages and arrival tracking interfaces

A changed arrival time does not explain what happened to a shipment. FJORD brings stages, blockers, recorded events and original/current ETAs into one Arabic record, preserving the reason behind each change.

Explore the project

FJORD shipment overview and mobile record on a navy, ice-blue and apricot background

1 / 1

Project information

Client: An original Nextwave project
Sector: Transport & logistics
Platforms: Web
Project type: Business systems

Services delivered

Web application developmentUser interface & experience design

THE BIG PICTURE

Project overview

When coordination asks where a shipment stands, the answer may concern its stage, last recorded event or reason for delay. FJORD separates those questions and connects their answers through the shipment reference, keeping status, time and context together.

Stage, blocker and ETA answer different questions

A shipment can be in transit and blocked at the same time. Its ETA may change without a stage transition. Reducing the whole record to a late label loses the distinction needed to decide the next action.

The design gives stage an ordered progression, blocker an independent reason and event time, and ETA an original value with traceable revisions. The shipment record brings them together with its events.

An overview that leads into shipment context

The overview presents stage distribution, open shipments, parcels in transit, late records and blockers. A selectable spotlight compares an open shipment’s ETA with its last event. The watchlist combines blockers and late records without duplicating a shipment that meets both conditions.

The register adds search, stage/risk filters, exact visible-weight totals and exports. Each record connects parties, route points, parcels, weight, reviews, tracking events, ETAs and save-audit history. The starting workspace contains nine shipments across four stages.

Chronological events and a preserved original ETA

A shipment moves from preparation to loading, transit and delivery. Each form targets only the next stage, so duplicate submission cannot skip a stage. Event time cannot precede the last event; automatic save-audit time remains separate from manually entered tracking time.

An open blocker prevents progress and keeps the previous/updated ETA with its reason. Independent reasoned ETA edits retain the baseline. Lateness compares the current ETA of undelivered shipments with the selected reading time. Weights use integer thousandths of a kilogram for exact totals.

INSIDE THE EXPERIENCE

Project images

Explore the interface and experience through the project gallery.

FJORD shipment register and record showing stage, parcels, weight and review requirements

1 / 3

Use case: preparing a shipment with an unambiguous reference

The coordinator enters a reference, parties, origin/destination, parcels and weight, followed by the record’s opening time and ETA. Reference case and full-width characters are normalised before uniqueness checking, preventing a second record based only on different letter forms.

Arabic or Latin digits are accepted for whole parcel quantities and positive weights with up to three decimals. ETA cannot precede the opening event. Saving opens a preparation record whose basic data can still be corrected. After loading, follow-up events and ETA revisions use their own actions and history.

Use case: resolving a blocker without losing the delay context

A shipment in transit needs its recipient details reviewed. The coordinator records a reason, event time and updated ETA at or after that time. The stage stays in transit, the event keeps previous/new ETAs and the original baseline remains visible.

The next stage is blocked until the issue is resolved. Resolution records a nondecreasing time and an explanation, clears the blocker and leaves stage/ETA unchanged. A later transition or ETA edit is a separate decision. Lateness then follows the current ETA and reading time; removing a blocker does not establish arrival.

Three FJORD mobile screens showing shipment indicators, stages, the register and shipment details

Use case: closing delivery after the required reviews

The coordinator reviews the shipment manifest, packing list and recipient details while the shipment is in transit. These are user-entered review states, not uploaded files. An internal item is optional; delivery requires all three mandatory items and no open blocker.

Delivery records the receiver, event note and time. Missing requirements keep the form open without changing the record. Successful saving locks data, reviews and events while preserving readable/exportable history. The event CSV includes receiver and blocker ETA history; register export follows current search and filters.

FJORD shipment record with enlarged required and optional review items before delivery

Maritime colour and a connected screen language

Navy anchors coordination, ice blue gives the record quiet reading areas and apricot distinguishes blockers and selected stages. Port imagery, stage distribution and the shipment spotlight connect logistics context with the saved details.

Mobile layouts accommodate long route-point names and large quantities. Four mockups use original screens with container-panel-inspired backgrounds: overview/phone, register/record, mobile views and review details. No text appears outside the screens.

Implemented interface scope

Three HTML, CSS and JavaScript interfaces implement browser storage, reference/quantity checks, sequential stages, blockers, ETAs, reviews, delivery and exports. Tracking events and times are user-entered; there is no live-location feed, carrier connection or document upload. Parties, shipments, figures and imagery do not establish customer operations. Carrier, document, customs, pricing, notification and shared-user services require separate work. Other sidebar labels outline broader modules.