Argo: projetando a interface entre um motor de planejamento com IA e as operações portuárias

Contexto

Cerca de metade dos contêineres que passam pelo Porto de Montreal saem de trem. Fazê-los sair depende da coordenação entre organizações que não respondem umas às outras: a autoridade portuária, os operadores de terminais, as ferrovias, as transportadoras marítimas. Cada uma tem uma parte do quadro. Nenhuma tem o quadro inteiro.

O Argo foi construído para fechar essa lacuna. É uma plataforma de planejamento com IA para o Porto de Montreal, desenvolvida com a Ivado Labs, a Thales, a Scale AI, a CN, a CP e os operadores de terminais do porto, usando aprendizado de máquina para prever volumes de importação e exportação e pesquisa operacional para otimizar as decisões daí decorrentes. O objetivo era estender o horizonte de planejamento do porto de cerca de 72 horas para dez dias.

A Thales nos trouxe para o trabalho de design: o modelo de interação e a arquitetura de informação da plataforma pela qual os coordenadores do porto de fato usariam aquilo que o motor produzia.

O desafio

O motor produzia previsões e planos. Esse não era o problema de design. O problema de design era que três coordenadores diferentes, trabalhando para organizações diferentes com responsabilidades diferentes, precisavam agir a partir do mesmo resultado, e nenhum deles agia sozinho.

O coordenador ferroviário, o coordenador dos trabalhadores portuários e o coordenador do porto se reuniam duas vezes por dia para planejar o trabalho seguinte. Era nessa reunião que as decisões eram tomadas. As pessoas podiam acessar a plataforma e montar planos, mas a verdadeira função dela era dar a três pessoas com mandatos diferentes uma referência comum a partir da qual raciocinar juntas e, então, se comprometer.

A previsão em si era a mesma para os três. O que mudava era o que ela significava para cada um: as decisões que dependiam dela, as metas pelas quais respondiam e a empresa cujo trabalho estavam planejando. O design precisava fazer com que um único quadro falasse a três conjuntos de interesses ao mesmo tempo.

O custo de errar é concreto. Os trabalhadores portuários desse setor ficam de sobreaviso; eles descobrem na véspera se vão trabalhar no dia seguinte. Um plano montado na plataforma na terça-feira determina quem será chamado na quarta. O resultado de um modelo de previsão se torna, um passo adiante, a semana de trabalho de uma pessoa.

Então a interface tinha que levar uma previsão probabilística para dentro de uma sala onde as decisões não eram. Os coordenadores precisavam ver o que entrava e saía por navio e por trem, onde cada contêiner estava na cadeia e há quanto tempo esperava em cada etapa, medido em relação aos limiares de serviço que definiam se o porto estava entregando. Precisavam do suficiente para julgar o plano, não apenas para recebê-lo.

A abordagem

Pesquisa com cada função, depois com todas juntas

Entrevistamos cada tipo de usuário separadamente para entender seu trabalho de planejamento: pelo que eram responsáveis, o que já sabiam, o que lhes faltava e o que faziam para compensar. Depois conduzimos uma atividade conjunta no Miro com as três funções na mesma sessão. Entrevistas separadas revelam o que cada função precisa. Colocá-las na mesma sala revela onde essas necessidades colidem, e é essa a parte que importa quando se projeta um artefato compartilhado para uma reunião de coordenação.

Projetar como o motor iria falar

Minha responsabilidade central era o modelo de apresentação: como as métricas e as previsões da plataforma seriam comunicadas às pessoas que a usavam. Isso significava definir quais partes do resultado do motor tinham lugar na interface, até onde projetar no tempo, como representar o tempo de espera dos contêineres em relação aos limiares de serviço para que um coordenador visse num relance onde a pressão estava se acumulando, e como estruturar tudo isso para que três funções com mandatos diferentes encontrassem cada uma a sua parte do quadro sem perder o quadro comum.

A plataforma também permitia trabalhar contra a previsão, não apenas lê-la. Os coordenadores podiam modelar cenários ajustando as condições que o motor havia assumido, a falta de trabalhadores sendo o caso óbvio, e ver como ficava o plano do outro lado. Essa foi a parte do design que tirou o resultado do motor da categoria de veredicto. Um coordenador capaz de perguntar o que acontece se quatro pessoas não aparecerem é um coordenador capaz de confrontar o raciocínio da máquina com o seu próprio antes de se comprometer com ele.

Trabalhamos ao lado da equipe da Ivado Labs durante todo o mandato. Eles moldaram a forma como os dados precisavam ser apresentados, informados pela nossa pesquisa e pelos dados do cliente; ficamos próximos ao longo do desenvolvimento para dúvidas e QA. O Figma não tinha modo de handoff para desenvolvedores na época, então apresentávamos no Figma e transformávamos o design em protótipo para trabalhar o comportamento.

Validar com as pessoas que iriam usar

Levamos os wireframes e o design de volta aos usuários para validação, em vez de esperar por uma versão construída para descobrir se o modelo se sustentava.

Acessibilidade como restrição de design, não como etapa de revisão

O Porto de Montreal está sob jurisdição federal, então o nível AA do WCAG 2.0 era uma exigência do cliente desde o início. Cuidei da acessibilidade comportamental (navegação por teclado, gestão de foco, semântica para leitores de tela, validada com NVDA); Tamara Ammar cuidou de cor e contraste; uma especialista em acessibilidade apoiou o trabalho. Incorporar a exigência ao modelo de interação desde o começo é um exercício diferente de auditar uma interface pronta em relação a ela.

O que o trabalho produziu

O Argo foi lançado. Está em produção no Porto de Montreal, e à plataforma se credita publicamente uma melhora na precisão das chegadas previstas de navios e trens, de 80% para mais de 95% num horizonte de dez dias. Esse número pertence à plataforma e aos anos de trabalho que vieram depois do nosso, não ao mandato de design. O que contribuímos foi a camada pela qual os coordenadores podiam agir a partir de tudo isso.

O princípio de design por trás do trabalho era que o plano não cabia ao motor. O motor conseguia enxergar dez dias à frente, através de dados aos quais nenhum coordenador sozinho tinha acesso. Não conseguia enxergar as dezenas de coisas que aqueles três sabiam de tanto trabalhar no porto. A interface tinha que entregar o que o motor sabia numa forma que três pessoas pudessem questionar, contestar e transformar numa decisão que estivessem dispostas a assinar, duas vezes por dia, todos os dias.

Entregas

• Entrevistas com os coordenadores ferroviário, dos trabalhadores portuários e do porto
• Workshop conjunto no Miro com as três funções de coordenação
• Modelo de interação e arquitetura de informação da plataforma de planejamento
• Modelo de apresentação das previsões e métricas do motor de planejamento com IA, incluindo o tempo de espera dos contêineres em relação aos limiares de serviço
• Design de interação para modelagem de cenários a partir da previsão do motor
• Designs de interface adaptados a cada função
• Protótipo interativo no Figma usado para trabalhar o comportamento da plataforma
• Sessões de validação de wireframes e design com os usuários
• Acessibilidade comportamental WCAG 2.0 nível AA (teclado, foco, semântica para leitores de tela, validada com NVDA)

Período do projeto: março de 2021 a julho de 2021 Cliente: Thales Digital Solutions Comprador: Porto de Montreal Idioma de trabalho: francês e inglês

Contribuidores e funções

• Louis-Philippe Bellerose - Designer de UX. Pesquisa, modelo de interação, arquitetura de informação, layout e comportamento, apresentação do resultado do motor de planejamento, acessibilidade comportamental, apoio de QA durante o desenvolvimento.
• Tamara Ammar (Thales) - Designer de UI. Design visual, acessibilidade de cor e contraste.

Ferramentas utilizadas

• Figma
• Miro
• MS Teams
• NVDA