Designing a booking platform where one character changes the price

01 — From Typed Dimensions to a Defensible Price

Making the pricing consequence visible while it is still editable

A shipment is not priced on what it weighs. It is priced on chargeable weight — the greater of actual and volumetric weight — and volumetric weight is derived entirely from the dimensions the operator types in.

Chargeable weight is the greater of the two. Which means the unit those dimensions are entered in is not a formatting preference — it is a multiplier.

The cm/in control was given real visual weight so the unit gets read rather than assumed, and chargeable weight recalculates in place as the operator types. The pricing consequence arrives before the commitment, not after it.

Designed for

• Density
• Irreversibility
• One-shot accuracy

02 — From One Box to Grouped Pieces

Keeping a dense form survivable

A real shipment is rarely one size. It is several groups of boxes, each with its own count and dimensions, plus handling rules that decide which aircraft can take the freight.

Inputs were grouped into logical sections, and piece variations put into expandable blocks — flexibility without a longer page, and less to hold in mind in a form nobody reads twice.

Designed for

• Desktop
• Operator workstation

03 — From a List of Rates to a Comparable Grid

Making pricing scannable in two directions

A list of routes is not enough to price a shipment. Operators compare across weight tiers and across carriers at the same time, and the table has to hold both readings at once.

Alignment holds across every carrier, or the vertical reading stops being trustworthy.

Surcharges are itemised rather than buried in a total, so an operator can defend a quote to a client without leaving the screen.

Users can

• Compare carriers
• Compare weight tiers
• Explain a total to a client

04 — From Confirmation to Coordination

Closing a loop that cannot be undone

Confirming a booking is a financial commitment. Reversing it means support tickets, delays and cost — so the confirmation screen answers every question the operator would otherwise raise, and keeps answering it afterwards.

The AWB reference stays visible, routing and shipment summary sit above the fold, and the status timeline is already on the page — so what happens next is answered before it is asked.

An operator checking a shipment is not idly wondering where it is. They are deciding whether to move a truck, warn a client, or rebook. A schedule change belongs where they are already looking, not in an email thread.

Users can

• Read a row at a glance
• Coordinate downstream logistics
• Find out about a change in place

05 — Building inside a design system I did not author

Extending a system in production without adding to its maintenance cost

I designed inside a system that was already shipped, used by other designers and built by a team of developers. That carries a specific discipline: before adding anything, understand why what is already there was built that way.

• Reused

  → form controls, tables, status indicators, buttons

• Extended

  → the unit toggle, the expandable piece group, the status timeline

• Documented

  → named layers, ordered structure, states and edge cases specified

Each new thing was built as a variant of something that already existed, so it inherits the system's behaviour instead of sitting beside it. A new pattern is a maintenance cost somebody else pays.

Contributed to

• Component variants
• Form patterns
• Status vocabulary
• Developer handoff

Status

• Shipped
• Design system extended, not replaced
• Outcomes described as intent, not measured