As telas mais usadas do produto

A Tradeverifyd ajuda empresas a ver de quem elas compram, nível por nível, e que risco existe nessa cadeia. A peça central é um mapa de fornecedores: ele parte da empresa do cliente e se abre pros fornecedores, nível por nível, com score de risco, resultado de checagens e anotações em cada card.

As pessoas levam o que veem nessas telas pro chefe. Se a tela passa segurança quando o dado não é seguro, ou não destaca onde o problema realmente está na cadeia, o produto falha no único trabalho que tem.

Duas correções no backend tinham acabado de impedir o produto de inventar fornecedores quando não havia dado de comércio. A decisão certa, com um efeito colateral: uma empresa sem registros mostrava o próprio nome e mais nada. A primeira tela de um cliente novo era uma caixinha sozinha, sem nenhum status dizendo o que tinha acontecido: ainda carregando, algo falhou ou não achamos nada.

Aquela tela em branco fazia o papel de quatro situações diferentes, e o cliente não conseguia diferenciar. As quatro eram lidas como "eles não têm nada sobre a gente". Uma falha de carregamento chegava a dizer "nada aqui ainda", igualzinho a um mapa vazio de verdade.

Escrevi a análise e a spec, e depois um sisteminha em volta: carregando, vazio de verdade, erro, e a regra de nunca mostrar mensagem de erro crua. Desenhado uma vez, reaproveitado na busca, no mapa de fornecedores e no monitoramento. Entreguei um empty state compartilhado com tom, e os quatro estados do mapa em cima dele. Depois apliquei o mesmo kit no feed de eventos, que parecia uma tela de debug.

• O tom faz parte da mensagem. Não encontrar atividade de comércio não diz nada de ruim sobre os fornecedores do cliente, então esse estado fica neutro, nunca com cor de alerta.
• Não preencher uma tela vazia com a coisa errada. Uma ideia era mostrar, no lugar, uma empresa relacionada que tinha mais dados. Eu disse não. Essa empresa tinha sido vendida anos antes, e só parecia relacionada por causa de um erro nos dados. Mostrar a empresa errada é pior do que mostrar uma tela vazia clara.
• Texto sem promessa. Sem pedido de desculpas, e sem "já sinalizamos" quando ninguém tinha combinado que isso abre um chamado.
• Não adivinhar o estado pela contagem. Um mapa pode estar cheio de fornecedores sem que a empresa se conecte a nenhum deles. Isso virou um requisito de backend: o dado tem que dizer por que o mapa está vazio, não só que está.
• Só entregar o que é verdade hoje. Só o estado de falha no carregamento foi pro ar com comportamento. Os outros esperaram o dado conseguir dizer o porquê.

Os clientes não achavam o fornecedor que importava. Percorri o produto no ar e anotei nove problemas: um banner insistente, uma barra de ferramentas tão cheia que cortava a própria navegação, linhas entre fornecedores impossíveis de seguir, um painel lateral que abria com um ID interno.

Depois contei o que os cards carregavam num mapa grande. Um rótulo, sobre a origem do dado, estava em todos os cards, então não dizia nada a ninguém. O único fornecedor numa lista de sanções parecia igual aos outros, e o elemento mais chamativo dele era esse mesmo rótulo.

Levei a crítica e os números pra uma call de UX com produto e engenharia. A gente decidiu junto: tirar o rótulo de origem do dado e só manter um rótulo quando ele comunica algo importante pro cliente, ordenar os fornecedores pelo quanto são críticos, suavizar as linhas e colocar o score primeiro no painel lateral.

Depois transformei o resumo automático da reunião numa lista acompanhada, corrigi dois erros nela e marquei três itens que pareciam decididos mas não estavam, pra ninguém construir.

• Navegação onde as pessoas procuram. A lista de mapas foi pra esquerda, o título do mapa vem primeiro e as abas ficam logo embaixo dele.
• A lista mostra o status de cada mapa. Uma bolinha de risco por mapa, um pulso quando tem algo crítico, um alerta, um sinal de carregando. Você sabe onde olhar antes de abrir qualquer coisa.
• Conexões mais calmas. Linhas mais suaves, que mostram o caminho sem brigar com os cards.
• O de maior risco primeiro. Fornecedores ordenados pela nota de risco, depois por ter ou não um alerta, depois pela gravidade, depois pela proximidade. Um fornecedor com alerta puxa o caminho inteiro dele pra cima.
• O crítico não passa despercebido. Um alerta grave, como sanções ou trabalho forçado, deixa o card vermelho independente do score, desenha o caminho dele em vermelho e comanda as contagens, pra página não se contradizer.
• Sem informação repetida, e bandeiras de verdade. O rótulo que estava em todos os cards e o ID interno saíram. Só o que o cliente declarou e alertas reais de checagem ganham etiqueta. Os códigos de país ganharam bandeiras de verdade, não emoji, que quebra no Windows.

Construí isso como protótipo com os componentes reais do produto, não com mockup, e com uma nota pra engenharia sobre tudo que ainda faltava no produto pro protótipo ficar completo.

Registrei a camada seguinte em oito issues de design: a visão geral, o cabeçalho, uma lista do pior primeiro, a passagem pro assistente de IA, cards enxutos, um painel lateral confiável. Prototipando, também achei um bug real, um score que nunca atualizava depois da descoberta, e medi antes de levantar: latente, ainda invisível pros clientes.

Falha de carregamento deixou de parecer mapa vazio. O dado agora diz por que um mapa está vazio, que é o que as telas novas precisam. As decisões do mapa de fornecedores foram acompanhadas da crítica até o ar num lugar só, e a camada seguinte está definida em oito issues de design.

Pra deixar claro: o protótipo nunca foi feito pra entrar no produto. Ele foi a spec de onde a engenharia construiu.