Argo: Designing the Interface Between an AI Planning Engine and Port Operations

Context

Roughly half the containers moving through the Port of Montreal leave by rail. Getting them out depends on coordination between organizations that do not report to each other: the port authority, the terminal operators, the rail carriers, the marine carriers. Each one holds part of the picture. None holds all of it.

Argo was built to close that gap. It is an AI planning platform for the Port of Montreal, developed with Ivado Labs, Thales, Scale AI, CN, CP, and the port’s terminal operators, using machine learning to predict import and export volumes and operations research to optimize the resulting decisions. The goal was to extend the port’s planning horizon from about 72 hours to ten days.

Thales brought us in for the design work: the interaction model and information architecture for the platform through which the port’s coordinators would actually use what the engine produced.

The Challenge

The engine produced predictions and plans. That was not the design problem. The design problem was that three different coordinators, working for different organizations with different responsibilities, had to act on the same output, and none of them acted on it alone.

The railway coordinator, the port worker coordinator, and the port coordinator met twice a day to plan the work ahead. That meeting was where the decisions were made. Individuals could log in and build plans, but the platform’s real job was to give three people with different mandates a shared reference they could reason from together, and then use to commit.

The forecast itself was the same for all three. What differed was what it meant to them: the decisions hanging off it, the goals they were accountable for, and the company whose work they were planning. The design had to let one picture speak to three sets of stakes at once.

The stakes of getting it wrong are concrete. Dock workers in this industry are on call; they find out the day before whether they are working tomorrow. A plan built on the platform on Tuesday determines who gets called for Wednesday. The output of a forecasting model becomes, a step later, a person’s work week.

So the interface had to carry a forecast that was probabilistic into a room where the decisions were not. Coordinators needed to see what was coming in and out by ship and by rail, where every container stood in the chain, and how long it had been waiting at each step measured against the service thresholds that defined whether the port was performing. They needed enough to judge the plan, not just receive it.

The Approach

Research with each role, then all of them together

We interviewed each user type separately to understand their planning work: what they were responsible for, what they already knew, what they were missing, and what they were doing to compensate. We then ran a joint Miro activity with all three roles in the same session. Separate interviews surface what each role needs. Putting them in one room surfaces where their needs collide, which is the part that matters when you are designing a shared artifact for a coordination meeting.

Designing how the engine would speak

My core responsibility was the presentation model: how the platform’s metrics and predictions would be communicated to the people using them. This meant working out which parts of the engine’s output belonged in the interface at all, how far ahead to project, how to represent container dwell time against service thresholds so a coordinator could tell at a glance where the pressure was building, and how to structure all of it so three roles with different mandates could each find their part of the picture without losing the shared one.

The platform also allowed the forecast to be worked against rather than only read. Coordinators could model scenarios by adjusting the conditions the engine had assumed, missing workers being the obvious case, and see what the plan looked like on the other side. This was the part of the design that took the engine’s output out of the category of pronouncement. A coordinator who can ask what happens if four people do not show up is a coordinator who can test the machine’s reasoning against their own before committing to it.

We worked alongside the Ivado Labs team throughout. They shaped how the data needed to be presented, informed by our research and the client’s data; we stayed close through development for questions and QA. Figma had no developer handoff mode at the time, so we presented in Figma and built the design into a prototype to work through the behaviour.

Validating with the people who would use it

We took the wireframes and the design back to the users for validation rather than waiting for a finished build to find out whether the model held.

Accessibility as a design constraint, not a review step

The Port of Montreal is under federal jurisdiction, so WCAG 2.0 Level AA was a client requirement from the start. I handled behavioural accessibility (keyboard navigation, focus management, screen reader semantics, validated with NVDA); Tamara Ammar handled colour and contrast; an accessibility specialist supported the work. Building the requirement into the interaction model from the beginning is a different exercise from auditing a finished interface against it.

What the Work Produced

Argo shipped. It is in production at the Port of Montreal, and the platform has since been publicly credited with improving the accuracy of predicted vessel and train arrivals from 80% to over 95% across a ten-day horizon. That figure belongs to the platform and the years of work that followed ours, not to the design mandate. What we contributed was the layer through which coordinators could act on any of it.

The design principle underneath the work was that the plan was not the engine’s to make. The engine could see ten days out across data no single coordinator had access to. It could not see the dozen things the three of them knew from working the port. The interface had to hand over what the engine knew in a form three people could question, argue with, and turn into a decision they were willing to sign their names to, twice a day, every day.

Deliverables

• Stakeholder interviews with railway, port worker, and port coordinators
• Joint Miro workshop across all three coordinator roles
• Interaction model and information architecture for the planning platform
• Presentation model for the AI planning engine’s predictions and metrics, including container dwell time against service thresholds
• Interaction design for scenario modelling against the engine’s forecast
• Role-adapted interface designs
• Interactive Figma prototype used to work through platform behaviour
• Wireframe and design validation sessions with users
• WCAG 2.0 Level AA behavioural accessibility (keyboard, focus, screen reader semantics, validated with NVDA)

Project period: March 2021 to July 2021
Client: Thales Digital Solutions
Purchaser: Port of Montreal
Language of work: French and English

Contributors and Roles

• Louis-Philippe Bellerose — UX designer. Research, interaction model, information architecture, layout and behaviour, presentation of the planning engine’s output, behavioural accessibility, QA support through development.
• Tamara Ammar (Thales) — UI designer. Visual design, colour and contrast accessibility.

Tools Used

• Figma
• Miro
• MS Teams
• NVDA