Depot Stock View

Published by

on

Uncovering a Shared Source of Truth for Container Inventory Across Multiple Business Functions

Summary

Maersk manages millions of container movements across depots worldwide. Despite the importance of container availability in operational decision-making, there was no centralized digital visibility into actual depot stock levels. Different business functions relied on fragmented data sources, emails, local knowledge, and assumptions to make critical decisions.

This initiative set out to understand the impact of this visibility gap, identify stakeholder needs, and explore how a Depot Stock View could support multiple user groups operating from the same inventory dataset but with very different business objectives.

Through stakeholder interviews, requirement synthesis, and AI-assisted analysis, the project uncovered a common need for inventory visibility while revealing fundamentally different definitions of “depot health” across teams.

The outcome was an evidence-based foundation for exploring future Depot Stock View concepts capable of serving diverse operational needs through flexible, configurable experiences.


Context

Container inventory sitting inside depots plays a critical role in several operational workflows:

  • Equipment allocation
  • Booking fulfillment
  • Container sales
  • Container redelivery
  • Equipment maintenance
  • Repair approvals

However, depot inventory information was not available through a centralized digital interface.

Teams therefore relied on multiple sources.This created a situation where stakeholders were often making business decisions without visibility into the actual inventory available at a depot.

The hypothesis behind the project was:

If stakeholders had visibility into depot inventory and container status, decisions could become more informed, proactive, and efficient.

Rather than immediately designing a solution, the project focused first on validating whether the problem existed, identifying who was affected, and understanding what information different users required.


Stakeholders

Research uncovered four primary stakeholder groups.

My Role

Senior UX Designer
  • Research planning
  • Stakeholder interviews
  • Interview moderation
  • Research synthesis
  • Requirement consolidation
  • Concept exploration strategy
  • Alignment across business functions
Timeline

2 months and ongoing

Tools Used
  • MS Copliot agent
  • Confluence whiteboard
  • Figma Ai
  • Design system specific skills

As the sole moderator, I conducted stakeholder interviews and synthesized findings into a structured requirement repository.

Existing ecosystem

Research Approach

The project followed a discovery-first approach.

Phase 1: Secondary Research

Initial understanding came from existing documentation and stakeholder conversations.

This helped form preliminary hypotheses around:

  • Equipment allocation challenges
  • Sales inventory visibility
  • Redelivery execution
  • Repair prioritization

However, these assumptions required validation through direct stakeholder engagement.


Phase 2: Stakeholder Interviews

Semi-structured interviews were conducted across all four stakeholder groups.

Objectives:

Understand
  • How decisions are made today
  • What information is currently available
  • Existing workarounds
Validate
  • Whether depot stock visibility is genuinely needed
  • Which workflows would benefit
Discover
  • Required data elements
  • Role-specific mental models
  • Potential solution constraints

Phase 3: Solution Concept Reviews

A preliminary concept was introduced to stakeholders.

Feedback focused on:

  • Data relevance
  • Information hierarchy
  • Aggregation versus detail
  • Role-specific needs

The goal was not validation of a design but validation of problem-solution fit.


Use of AI

AI played a significant role in accelerating research operations while keeping stakeholder conversations human-led.

AI was used for:

Interview Preparation
  • Drafting interview guides
  • Exploring hypotheses
  • Identifying potential knowledge gaps
Research Synthesis
  • Structuring findings from interview transcripts
  • Building evidence repositories
  • Grouping requirements
Requirement Mapping
  • Identifying common themes
  • Detecting overlaps across stakeholder groups
Concept Exploration
  • Generating exploratory design prompts
  • Identifying opportunities for configurable experiences

Importantly:

AI was used to assist synthesis and exploration, not to replace stakeholder input.

All findings remained grounded in stakeholder interviews.


Key Insights

Insight 1

The Problem Was Not Inventory Visibility Alone

Initially, the assumption was that stakeholders simply needed stock counts.

Research revealed a deeper issue.

Each team required inventory visibility to support different decisions.

Examples:

  • Equipment Flow needed availability forecasting.
  • Sales needed visibility of sale-designated inventory.
  • Redelivery teams needed leased container tracking.
  • Repair teams needed inventory context for approval decisions.

The inventory dataset was shared.

The decision-making context was not.


Insight 2

Users Think in Terms of Depot Health

Stakeholders rarely asked for raw inventory numbers.

Instead they wanted answers to questions such as:

  • Can this depot support demand?
  • Is inventory usable?
  • Are sales assets actually out-fleeted?
  • Are redelivery opportunities being missed?

The opportunity evolved from:

“Show depot stock”

to

“Help stakeholders assess depot health.”


Insight 3

Aggregate and Detailed Views Are Equally Important

Stakeholders frequently discussed two types of behaviour:

Assessment

Understanding overall depot conditions.

Examples:

  • Inventory levels
  • Status breakdowns
Investigation

Drilling into individual containers.

Examples:

  • Repair candidates
  • Sale inventory
  • Redelivery opportunities
  • Available for export

A successful solution would need to support both.


Insight 4

The Same Inventory Requires Different Lenses

Different teams prioritized entirely different attributes.

Examples:

GroupCritical Information
Equipment FlowAvailability, status, incoming inventory
SalesSale eligibility, sold status
RedeliveryRedelivery eligibility, contractual context
RepairGrade, damage, PTI, repair status

This suggested that a one-size-fits-all dashboard would likely fail.


Problem Statements

Equipment Flow

How might we help Equipment Flow teams understand actual depot availability so container allocation decisions can be based on current conditions rather than static rules?


Container Sales

How might we help Sales teams identify and manage sale-designated inventory so containers can be sold in a timely manner?


Container Redelivery

How might we help Redelivery teams identify and act on redelivery opportunities before eligible containers are reused in operational workflows?


Equipment Maintenance & Repair

How might we help Repair teams make inventory-aware repair decisions that improve equipment availability while avoiding unnecessary costs?

Solution Direction

Rather than designing a fixed inventory dashboard, the project moved toward exploring a flexible Depot Stock View capable of supporting multiple mental models.

Exploratory concepts focused on:

Configurable inventory dashboards

Users choose which dimensions and statuses matter most.

Role-based perspectives

Different stakeholder groups see tailored inventory views built on the same dataset.

Depot health model

Users begin with overall depot health indicators and drill into specific operational issues.



Outcome

The project transformed what initially appeared to be an inventory visibility problem into a broader understanding of how different business functions interpret and act on depot information.

Research established:

  • Clear evidence of a visibility gap
  • Stakeholder-specific information needs
  • Shared versus unique requirements
  • Common dataset opportunities
  • Future design directions

Most importantly, it provided a defensible foundation for designing a Depot Stock View that balances consistency, flexibility, and role-specific relevance across multiple business functions.