Where is my package, and who has it right now?

The real question

"Where is my package?" reads like a tracking question. Underneath it sat a harder one: who has the package right now, who scanned it last, and if it has stopped moving, why. Quincus is a logistics-orchestration platform, and QShip is the surface its customers actually look through to follow a shipment. The customer I worked with could only see a shipment once it reached their own hub. Everything before that, the supplier dispatch, the airport handling, the airline transfer, the inter-island leg, ran on someone else's system and was effectively invisible.

I led the research and the design: the discovery interviews, the information architecture, and the interface across the people who depend on it.

The shipments list, at-risk shipments surfaced up top

What the research found

I ran discovery with the people who live inside tracking all day: operations coordinators, support agents, dispatch planners, and regional managers. Ten problems came back, and they pointed at one root cause. Visibility stopped at the hub, so the system could confirm a shipment existed without saying where it was.

A few that shaped everything after:

• Operators were blind upstream. "Customers expect us to know where every package is. The reality is we often don't have visibility until it reaches our hub."
• One shipment lived in five systems. Answering a single status question meant airline portals, warehouse tools, spreadsheets, and carrier sites. "I keep five browser tabs open just to answer one tracking request."
• The ETA could not be trusted. Airports, customs, ferries, and regional hubs each moved the arrival time, and the systems disagreed about which was current. "When the airline updates the arrival time, our dashboard doesn't always reflect it immediately."
• Exceptions were found by the customer, not the operator. Most delays surfaced only when someone called in. Teams spent the day reacting to problems instead of getting ahead of them.
• Support had become the visibility layer. A large share of calls were not about damaged or lost parcels. They were status questions, and agents had to ping operations before they could answer one.
• A status meant nothing on its own. "In Transit" did not say whether a shipment was waiting on customs, loading onto an aircraft, or transferring between hubs.

The finding that set the structure: everyone looked at the same shipment and needed it told a different way. Operations wanted something to act on. Support wanted an answer. Managers wanted the risks. Customers wanted reassurance. The existing tools handed all four the same generic page, which served none of them.

The reframe

So I stopped treating this as a tracking feature and started treating it as an accountability problem. A shipment passes through many hands across many modes: trucks, domestic flights, ferries, motorcycles. Every handoff is a place the chain can break, and a break needs an owner and a reason, not a silent gap. The job was to make each leg legible: who touched it, where, when, and what carried it next.

Designing for accountability

I pulled the whole multimodal journey into one consolidated view instead of scattering it across screens and support calls. One shipment, read top to bottom: who and where, the live ETA and the SLA against it, the movement, then the static record.

One shipment, read top to bottom, the in-transit detail view Map mode, the inbound flight arc mid-flight

The chain of custody is where the accountability lives. Every scan names its handler, its facility, its time, and the flight or vehicle that carried it. "Who scanned it last" stops being a phone call to operations and becomes a line on the page.

One activity timeline, each scan with its handler, facility, and carrier

Under the movement sits the record: schedule, parties, parcel, charges, documents. I gave each fact a single place so the same number could not contradict itself between the timeline, the map, and the summary. The "In Transit" status that meant nothing now resolves into a specific milestone with a specific owner.

The static record, one place per fact

The last handoff closes the loop. Proof of delivery, the signer, the COD collected, all sit in the same place as "where is it," so "was it actually delivered" has an answer on the same screen.

Proof of delivery lives beside the live tracking, not in a separate report

What I explored and killed

Getting to one timeline meant killing the obvious version first.

The systems hand you two timelines, not one. Shipment milestones come from the warehouse and operations side. Transportation events, the flight legs and carrier scans, come from a different set of systems, and engineering found that separation easier to build. So the first design kept them apart: a shipment timeline and a transportation timeline, side by side.

It failed in testing. Operators kept asking the screen the same question, "did this flight cause this delay?", and answering it meant reading both timelines and stitching them together in their head. The split that was clean for the backend was work for the user. I merged the two into a single chronological activity stream, where a flight event and a custody scan sit in the same line of the story. That merge is the decision the whole accountability idea rests on.

I dropped a second direction for the same reason. Early on, flight tracking had its own page, linked from the shipment detail, because flight data is dense and a dedicated page gave it room for maps and airline schedules. But operators bounced between the two pages to answer one question, and the context switch broke the link between a milestone and the flight that caused it. I embedded the live flight information into the detail page instead, so the shipment and its transport read as one thing.

The exceptions, designed first

The states that matter in logistics are the ones that go wrong, so I designed those before the happy path.

An address that can't be resolved used to mean a parcel sat silently at a hub until a customer chased it. I made it a hold with a cause and a fix: the consignee address is incomplete, here is the suggested correction, confirm in one action.

An address-ambiguity hold, with the cause and a one-action recovery

An inbound flight slips six hours. The banner carries the new ETA, the SLA risk it creates, and a notify-consignee action, so the operator gets ahead of it instead of hearing about it from the customer. This is the exact case the research kept surfacing: the delay the customer found first.

A six-hour flight delay, with the SLA risk and the recovery action on the banner

One shipment, four reads

The same record had to serve four goals, so the emphasis changed by who was looking. Operators got the next action. Support got the answer without leaving the page. Managers got the at-risk shipments surfaced to the top of the list instead of buried among hundreds of normal ones. Customers got a plain, mobile milestone view that answered the status question before they reached for the phone.

The hardest part

The hardest problem was not showing more data. It was deciding what deserved immediate attention. A shipment carries hundreds of attributes: flight numbers, scans, manifests, handlers, addresses, invoices, proof of delivery, customs records, SLA calculations. When everything looks equally important, nothing is.

So I did not organize the page by database table or backend service. I organized it around the questions an operator asks, in the order they ask them:

• What shipment am I looking at?
• Is it healthy?
• Where is it now?
• What happened?
• What do I need to do?

That sequence became the skeleton of every screen.

Outcome

This shipped as part of a client engagement, so the product team never got quantitative business metrics. What stakeholder reviews and customer feedback kept returning to was qualitative:

• Operations could read a full shipment journey without switching between systems.
• Support answered status questions with more confidence, and fewer of them went back to operations first.
• The enterprise customer got end-to-end visibility that reached past the final mile.

The honest version: better visibility reduced operational uncertainty even where delivery performance itself did not change. The work made the same shipments legible, not faster.

Reflection

I started this thinking shipment tracking was a data-visualization problem. The research turned it into an information-architecture problem. The challenge was never collecting more logistics data. It was deciding where each piece of information belonged, how four different users read the same shipment, and how to show complex operational data without burying them. That changed how I approach enterprise products. I spend less time asking "what information should we show?" and more asking "what decision is the user trying to make right now?"