Centralised cargo model for supply chain.

Why this mattered.

Customers were complaining because they lacked reliable visibility into shipment progress. The existing experience made it difficult to understand where cargo was, what stage it had reached and whether there was a problem worth investigating.

This was not just frustrating for customers. It also created pressure internally.

• Operational teams were filling information gaps manually
• Support teams were dealing with avoidable queries
• The business risked losing customer trust in a high-stakes area of the product

Leadership initially pushed for smaller improvements, but those would only have improved presentation, not the underlying quality of visibility.

The problem I chose to solve.

Supply chains are messy. Cargo moves through multiple handoffs, documents are often exchanged manually and routes change in ways the system does not always capture cleanly.

At the same time, Zencargo was moving from a monolith toward microservices. That exposed a bigger constraint. The existing data model and information architecture could not accurately represent the complexity of real cargo journeys, especially around transshipments, exceptions and partial confirmations.

The challenge was not just to redesign a page. It was to create a model that was three things.

• Trustworthy enough for customers to act on
• Flexible enough to handle real-world variability
• Structured enough to support future platform capabilities

My role and scope.

I led the design work across discovery, framing, concept development, testing and stakeholder alignment.

I owned four areas.

• UX direction
• Research plan and synthesis
• Decision-making on the customer experience
• Launch readiness from a design perspective

I also influenced product direction, success criteria, the service model and information structure and cross-team alignment as the scope expanded.

This was not limited to interface design. I helped shape how the team understood the problem, what we prioritised and what foundation we needed to build before the experience could genuinely improve.

The constraints and tension.

Early research showed the issue was not simply clutter. The deeper problem was that the product was organised around the wrong unit of understanding.

Shipment and purchase order information was difficult to scan because the information architecture did not reflect how users actually reasoned about cargo movement and exceptions. Through research, journey mapping and collaboration with domain experts, I identified that cargo, not shipments or orders, needed to become the primary organising model.

That changed the direction of the work. Instead of forcing transshipment handling into the existing structure, I helped the team shift toward a cargo-centred model that could better represent route progress, milestones and exceptions.

Key decisions I drove.

3. Protected focus by cutting lower-value ideas

Customers who bought the product often asked for a map. Research showed that day-to-day users found route status, exceptions and scannable text updates more useful than map-based visualisation.

I used that evidence to deprioritise the map and protect the team's focus on information that genuinely helped users make decisions.

Outcome.

We avoided spending time on a visually appealing but lower-value solution.

How I influenced direction.

As the work developed, we realised the impact reached beyond one team. Multiple product teams were working on the same page and adjacent workflows, creating overlap, rework and conflicting changes.

We had to stop and restart several times as new dependencies surfaced. To stabilise progress, I helped introduce a review mechanism so impacted teams could be consulted and sign off on direction as the work evolved.

Outcomes.

Because I left Zencargo before the work was fully rolled out, I am not claiming shipped performance metrics. The outcomes I can credibly stand behind are the decisions, alignment and foundations the work created.

Why this demonstrates principal level capability.

This project demonstrates how I work at a broader level than feature delivery alone. I did not just redesign a page. I identified the deeper problem beneath the interface, influenced the team to invest in a more durable direction, shaped a key product principle around trust and visibility and helped create a reusable foundation that extended beyond one release.

The skills this shows are service design, domain modelling, cross functional facilitation, research strategy and product strategy.

That is the kind of work I want to do more of, connecting user needs, product direction and systems-level thinking to create value that lasts.

Reflection.

The work I want to do more of is the work that connects user needs, product direction and systems level thinking. Zencargo is the clearest case I have of the three meeting on one problem. The user need was a trustworthy answer about where cargo was. The product direction was whether to patch a page or change the model underneath it. The systems level thinking was the cargo centred structure that made a trustworthy answer possible at all.

Value that lasts is the part I would still test for. What I would point to here is not the interface. It is the shared model, which became an early foundation for the digital twin direction rather than a fix for one release.

→ Full story and decisions in an interview