Logistics

Enterprise Product

Under NDA

Simplifying workplace package tracking and coordination

A workplace logistics service that brings delivery information and the actions users need into one consistent experience.

Role

Senior Product Designer

Disciplines

Product Design, UX and UI

Client

Global workplace technology

Platform

Web & Mobile

Overview

This app was designed to improve how customers access and manage information related to workplace deliveries.

The project was part of a broader initiative to bring several complementary enterprise services into a more unified digital experience.

I led the product design for the service and set the workflow structure, information hierarchy and interaction patterns it shipped with.

Due to confidentiality obligations, certain product details, workflows and interface examples have been simplified or omitted.

Challenge

Customers needed a clearer and more consistent way to understand the status of workplace deliveries and identify when further action was required.

Existing processes depended on information being distributed across different touchpoints, which could make delivery status, responsibilities and next steps difficult to follow.

The wider product also needed to bring together several related services without making the overall experience feel fragmented or inconsistent.

The design challenge was therefore to simplify a multi-step operational workflow while preserving the information users needed to decide.

Process

I built persona boards for the two people in this workflow: the customer waiting on a package and the operator moving it. Both came back with the same two frustrations written on them: tracking was not unified, and neither could check a status or change a drop point.

Persona boards for a customer user and an operator: goals, tasks and frustrations

Their tasks overlapped more than I expected. Reject a delivery, postpone it, update the address, insert a tracking number: the same actions sat on both boards. I had mapped the delivery stages first, and stages told me what the system tracked, not whose move it was.

So I redrew the flows around responsibility rather than stage. The operator's board ran half again as long as the customer's, and both people had to live in one service.

Decisions

Answer "does this need me", not "where is the package"

The Tension

The underlying system knows where a delivery is in the process. What users needed to know was whether they had to do something about it. Those are different questions, and the second one is not stored anywhere, so the interface has to work it out.

What I chose

Status patterns communicate whether attention is required and which actions are available, not only the stage a delivery has reached.

What it cost

The interface took on logic the source system does not hold. Deciding who is responsible at each stage meant encoding rules about the operation itself, so when those rules are wrong the product is wrong in a way a plain status display never could be.

Progressive disclosure over the complete view

The Tension

Operational users ask for everything on screen, and they mean it. But a delivery involves several stages, people and dependencies, and showing all of it makes the one thing that matters invisible. Cutting information from the default view meant arguing with the people who had asked for it.

What I chose

Status and required action lead. Operational detail is available progressively.

What it cost

Pushback, and a real one. Some users now take an extra step to reach detail they previously saw immediately, and being right about the default does not make that free.

Reuse the platform's patterns instead of designing a standalone service

The Tension

A standalone service could have been shaped exactly to the delivery workflow and built faster. Using the wider platform's components meant inheriting constraints that did not always fit this workflow.

What I chose

The service was built from shared components and interaction patterns so it reads as part of the platform.

What it cost

Some delivery-specific interactions had to be expressed through general-purpose components. Deliver and cancel are the clearest example: they carry consequences that a generic action pattern was never designed to communicate.

Solution

Customers now have a more centralised view of workplace delivery information.

Item delivery status for a customer, with the tracking history across each stage

Item detail for a customer, with the map, tracking history and the delivery decision

The operator inbound queue next to the customer view grouped by what needs attention

Action panels for reroute, delivery failed and delivered

Item detail with tracking history first and details below, on desktop and phone

Pending decisions for operators on desktop and for customers on a phone

The operator phone app: today at this location, inbound items and tracking on the map

Validation

HOW IT WAS REVIEWED

Daily contact was with the client, and the operational picture came from a manager describing how the rounds work. Several parcels a day, a fixed route, hand it to the person or leave it at a service point, a signature on paper that the app replaced with a QR scan. I checked it against a courier and an operations coordinator where I could. I asked for more direct access and didn't get it: the position was that the research had already been done, and some of the assumptions that reached me that way produced rework later.

WHAT SHIPPED

Design system and mockups handed to the implementation team. Live and in active development.

Outcome

All 14 services on the platform adopted the status and disclosure patterns. They are live and in use by the client's own teams and by their customers.

The work set the product direction for workplace logistics and gave delivery information a single structure: status, responsibility and available actions in one place rather than spread across separate touchpoints. The patterns were built for reuse across services, and that's what happened.

I have no usage figures beyond that. Any the client holds are covered by the agreement.

14/14

services adopted the status patterns

place for status, responsibility and actions

Reflection

This project reinforced how important system states and responsibilities are in operational products.

A delivery workflow often involves several stages, people and dependencies. I had to give users enough visibility without exposing the full complexity of the underlying process.

Next Project

Multinational insurer

Clarifying insurance management for advisors

Logistics

Enterprise Product

Under NDA

Simplifying workplace package tracking and coordination

A workplace logistics service that brings delivery information and the actions users need into one consistent experience.

Role

Senior Product Designer

Disciplines

Product Design, UX and UI

Client

Global workplace technology

Platform

Web & Mobile

Overview

This app was designed to improve how customers access and manage information related to workplace deliveries.

The project was part of a broader initiative to bring several complementary enterprise services into a more unified digital experience.

I led the product design for the service and set the workflow structure, information hierarchy and interaction patterns it shipped with.

Due to confidentiality obligations, certain product details, workflows and interface examples have been simplified or omitted.

Challenge

Customers needed a clearer and more consistent way to understand the status of workplace deliveries and identify when further action was required.

Existing processes depended on information being distributed across different touchpoints, which could make delivery status, responsibilities and next steps difficult to follow.

The wider product also needed to bring together several related services without making the overall experience feel fragmented or inconsistent.

The design challenge was therefore to simplify a multi-step operational workflow while preserving the information users needed to decide.

Process

So I redrew the flows around responsibility rather than stage. The operator's board ran half again as long as the customer's, and both people had to live in one service.

Decisions

Answer "does this need me", not "where is the package"

The Tension

What I chose

Status patterns communicate whether attention is required and which actions are available, not only the stage a delivery has reached.

What it cost

Progressive disclosure over the complete view

The Tension

What I chose

Status and required action lead. Operational detail is available progressively.

What it cost

Pushback, and a real one. Some users now take an extra step to reach detail they previously saw immediately, and being right about the default does not make that free.

Reuse the platform's patterns instead of designing a standalone service

The Tension

What I chose

The service was built from shared components and interaction patterns so it reads as part of the platform.

What it cost

Solution

Customers now have a more centralised view of workplace delivery information.

Validation

HOW IT WAS REVIEWED

WHAT SHIPPED

Design system and mockups handed to the implementation team. Live and in active development.

Outcome

All 14 services on the platform adopted the status and disclosure patterns. They are live and in use by the client's own teams and by their customers.

I have no usage figures beyond that. Any the client holds are covered by the agreement.

14/14

services adopted the status patterns

place for status, responsibility and actions

Reflection

This project reinforced how important system states and responsibilities are in operational products.

A delivery workflow often involves several stages, people and dependencies. I had to give users enough visibility without exposing the full complexity of the underlying process.

Next Project

Multinational insurer

Clarifying insurance management for advisors