I was initially brought in to explore an early concept called Orbit; the goal was to help users identify issues across the supply chain at a network level, and then understand how stock could be redistributed across sites to resolve them.
From the outset, it was clear this was a complex space with multiple constraints. While inbound logistics would play a key role in managing incoming stock and coordinating dispatch to fulfilment centres, the platform also needed to support a wider set of supply chain teams responsible for stock movement and distribution.
Before any discovery or workflow mapping had taken place, the working assumption with Product Managers was that this would be a brand new, standalone interface.
Before moving into design, I focused on understanding how supply chain teams, specifically demand planners and network distribution centre (NDC) managers actually work day to day.
I reviewed existing documentation, explored internal tools, and began mapping the end-to-end workflows of how network issues are identified, all the way through to their resolution, as well as how stock transfer orders (STOs) are managed.
During this process, I noticed a significant overlap:
Parallel work in progress
The Analytics & Insights team within Supply Chain was already building a performance analytics tool used by demand planners and NDC managers to investigate issues.
Key realisation
When comparing their work with Orbit’s goals, it became clear that building a separate, standalone interface would risk fragmenting the user experience, duplicating functionality and create unnecessary engineering effort.
This shifted the problem from “what should we design?” to “where should this actually live?”
To explore this properly, I created a set of early concept mockups based on my findings so far, these weren’t intended to be the final UI but to map workflows, test assumptions, and give the team something concrete to react to.
The concepts walked through the full lifecycle of an issue:
Surfacing network health - a macro view to highlight issues and bottlenecks across sites
Investigating root causes - drilling into specific sites or SKUs to identify and troubleshoot issues
Managing inbound and redistribution - exploring how stock could be moved across the network
Cross-team coordination - testing how tasks and actions might be handed between teams
This helped reveal not just what the interface could look like, but the underlying complexity behind it - how information flows, where decisions are made, and where dependencies between teams break down.
I brought these concepts into a workshop with product managers, engineers, and supply chain domain experts; walking through the workflows together quickly exposed where the approach wouldn’t hold up in practice.
One of the biggest issues raised was scale and alert fatigue. In reality, the number of issues surfacing across the network each day would be far too high for users to review individually, track manually and approve one by one. The task-based approach we had been exploring quickly broke down under real-world conditions.
The shift in thinking
This sparked a discussion around how the system should actually work.
Instead of handling issues individually, we began exploring:
Grouping related issues together
Aggregating data at a higher level
Prioritising what actually needs attention
Aligning on a new direction
At the same time, seeing the workflows mapped out made the overlap with the Analytics and Insights team much more obvious to everyone.
What initially felt like two separate initiatives now clearly sat within the same problem space, shifting alignment away from building a standalone tool and instead towards integrating these workflows into existing tools.
Following the workshop, I iterated on the concepts to reflect this shift.
To address the issue of alert volume, I moved away from task-based workflows and focused on more scalable patterns:
High-density data tables
Performance scorecards
Grouping and filtering mechanisms
Clearer ways to surface patterns across the network
These designs demonstrated how the workflows could sit within the Analytics & Insights apps, rather than requiring a completely separate UI.
Based on the workshop discussions and iterated concepts, the team moved away from the idea of building a standalone product.
Instead, we began to explore how these workflows could sit within the existing Analytics and Insights apps. The approach shifted from managing individual issues to helping users interpret patterns across large volumes of data.
Although I later moved to another team, this early work helped:
Avoid duplicating functionality
Reduce fragmentation across tools
Focus effort on extending existing capabilities rather than building a separate product
Steer the team toward a more scalable, integrated approach
While this project didn’t result in a shipped product during the time I was involved, it influenced how the problem was approached and helped align stakeholders around a more integrated direction.
Early concept designs are tools for thinking, not just design
Their value is in making complex workflows visible so teams can challenge assumptions early.
Designing for scale requires different thinking
What works in theory can break down quickly at scale. Solutions need to support patterns and priorities, not just individual issues.
Good design includes knowing when not to build
Understanding the wider system can lead to more integrated, effective solutions.