O problema
A rede ferroviária espanhola tem aproximadamente 15 000 km de via e gera milhões de comboios-quilómetro de dados de vibração e acústicos todos os anos. Os comboios de auscultação — os veículos que medem o estado dos carris — estão entre os instrumentos mais sofisticados do conjunto de ferramentas de manutenção. Os dados que recolhem são detalhados, estruturados e, em teoria, acionáveis.
Na prática, chegam em PDF.
Do sensor ao engenheiro de manutenção, a cadeia é esta: os dados são recolhidos, processados centralmente, formatados num relatório, distribuídos por e-mail e interpretados pelo engenheiro que tem de decidir — muitas vezes na mesma reunião em que se priorizam uma dúzia de outras coisas — para onde enviar uma equipa esta semana. Quando um defeito de corrugação chega a alguém com autoridade para agir, passaram dias ou semanas desde que era detetável no sinal pela primeira vez.
O acidente de Adamuz de janeiro de 2026 colocou a infraestrutura de segurança ferroviária de Espanha sob escrutínio nacional. Entre as lacunas que tornou visíveis: a distância entre o que o sistema sabe e o que chega às pessoas que podem fazer algo a respeito. O BaseLine foi construído para responder a uma parte específica dessa lacuna — o problema da auscultação.
Investigação e validação
Antes de construir o que quer que fosse, realizei uma validação estruturada da oportunidade no espaço do problema, abordando-o como investigador UX, com um ceticismo deliberado perante enquadramentos “resolúveis com tecnologia”.
Os problemas estruturais são reais: intervalos de periodicidade entre passagens de auscultação, baixa relação sinal-ruído nos dados brutos, visibilidade fragmentada entre equipas de campo e salas de controlo, e latência na escalada manual que obriga a trabalho reativo em vez de preventivo. Não são anedóticos — são estruturais no modo como o fluxo de inspeção atual funciona.
O utilizador principal do MVP é uma pessoa: o engenheiro de triagem de manutenção. Não maquinistas, não reguladores, não controladores de operações, não executivos. O engenheiro de triagem já toma decisões de priorização, já sente a dor da deteção tardia e pode agir sem alterar a operação dos comboios. Todos os outros grupos de utilizadores ficaram explicitamente fora do âmbito da primeira versão.
Problema forte, complexidade alta, risco de adoção significativo. A recomendação: não construir primeiro uma plataforma completa. Começar com uma classe de defeito, um corredor, um grupo de utilizadores. Provar que a deteção mais precoce muda o comportamento antes de expandir o que quer que seja.
Taxas elevadas de falsos positivos causam abandono rápido. Previsões em caixa negra são ignoradas ou alvo de desconfiança. As preocupações sindicais com vigilância e atribuição de culpa são bloqueios reais. Qualquer sistema que sugira “defeitos não detetados” cria tensão de responsabilidade com os reguladores. Não são problemas de UX — são restrições políticas e organizacionais que tiveram de moldar o design desde o início.
A cunha do MVP
A definição do âmbito foi tão importante como qualquer decisão de design no projeto. A cunha foi escolhida para ser estreita o suficiente para sobreviver à política organizacional, útil o suficiente para mudar o comportamento e legível o suficiente para ganhar a confiança de reguladores e engenheiros.
A corrugação dos carris produz assinaturas acústicas e de vibração distintas, desenvolve-se gradualmente (dando tempo para deteção e resposta) e já é bem compreendida pelos engenheiros de manutenção — o que facilita a calibração da confiança. As linhas de alta velocidade AVE foram explicitamente excluídas do MVP: o risco político e de segurança é demasiado alto para começar por aí.
Um único corredor suburbano de tráfego intenso, com material circulante misto e problemas históricos de manutenção conhecidos. A tarefa principal: “ajudá-lo a decidir onde olhar primeiro esta semana”. Não previsão. Não substituição de inspeções. Não alertas em tempo real. Apoio à triagem para a decisão semanal de priorização que os engenheiros já tomam.
O que o MVP explicitamente não faz: Não alerta maquinistas em tempo real. Não aciona ordens automáticas de redução de velocidade. Não substitui inspeções. Não classifica o desempenho de equipas ou maquinistas. Não fornece cronologias preditivas de falha (“falha em X dias”). Cada um destes não-objetivos foi uma escolha deliberada para reduzir a fricção de adoção e o risco de responsabilidade.
O que desenhei
O protótipo é uma interface de triagem web-first construída em Figma Make — uma aplicação React funcional, não uma maquete. Tem duas vistas principais.
Lista de anomalias — a vista de triagem
O ecrã principal é uma tabela ordenável e filtrável das anomalias detetadas no corredor. Quatro cartões de KPI no topo dão ao engenheiro uma leitura imediata da situação atual: total de deteções, pendentes de revisão, severidade alta e tendência de agravamento. Cada linha mostra os cinco sinais necessários para tomar uma decisão de triagem sem abrir o detalhe: localização (marcador PK), banda de severidade, nível de confiança, direção da tendência e estado de corroboração. Os filtros reduzem-se a severidade, confiança, tendência e estado — nem mais, nem menos.
Detalhe da anomalia — a vista de decisão
Configuração — limiares controlados pelo engenheiro
Os engenheiros podem ajustar os limiares de deteção por classe de defeito diretamente na interface. Cada alteração fica registada. Não é uma definição enterrada num painel de administração — é um fluxo de primeira classe, porque a calibração faz parte da relação de confiança entre o engenheiro e o sistema.
Ao abrir o detalhe, surgem as evidências por trás da deteção: um gráfico de sinal de 52 passagens com o histórico bruto de vibração e o limiar, um cartão de explicação em linguagem simples, o estado de corroboração a partir de fontes de sensores identificadas e todo o contexto técnico (localização PK, secção, variação de amplitude em %, passagens confirmatórias consecutivas). O painel de ações à direita é o único lugar onde o engenheiro interage com o sistema: revisto, inspecionar no próximo ciclo, agendar manutenção, falso positivo. Cada decisão fica registada com a identidade do utilizador e um carimbo temporal.
Decisões de design principais
Cada cartão de anomalia começa com uma explicação em linguagem simples do que foi detetado e de por que razão o sistema o assinalou: “Aumento sustentado da amplitude de vibração lateral no carril direito. Os valores excederam o limiar estabelecido em 7 das últimas 10 passagens de medição. O padrão de evolução sugere um possível defeito de corrugação de passo longo. Confirmado de forma independente por sensor de via e comboio de auscultação.” O engenheiro lê as evidências antes de ver a etiqueta de severidade — não o contrário. É uma inversão deliberada do modo como a maioria dos sistemas de alerta é desenhada.
Cada anomalia mostra se foi confirmada por mais do que uma fonte independente. As deteções corroboradas estão assinaladas; as de fonte única não. Este único sinal visual faz um trabalho significativo: calibra a confiança do engenheiro antes de ler qualquer outra coisa, reduz o custo cognitivo da priorização e torna legível, em vez de escondida, a incerteza do próprio sistema. Uma deteção de severidade alta não corroborada deve ser investigada — mas de forma diferente de uma corroborada.
A vista de detalhe inclui uma nota persistente: “As decisões registadas aqui ficam associadas ao seu utilizador e à data. O sistema não executa ações automáticas sobre a infraestrutura.” Não é um aviso legal. É o compromisso de segurança central do design. Uma ferramenta de triagem num domínio crítico para a segurança que execute ações automáticas — ou sugira que o possa fazer — será alvo de desconfiança, contornada ou bloqueada pelos reguladores. O ser humano é sempre quem decide. O trabalho do sistema é dar-lhe melhor informação, mais depressa.
O MVP é deliberadamente estreito: uma classe de defeito, um corredor, limiares afináveis pelos engenheiros. O princípio de design por trás disto é que taxas elevadas de falsos positivos são o caminho mais rápido para o abandono num fluxo crítico para a segurança. Um engenheiro que descarta três alertas sem agir não vai verificar o quarto. Nesta fase, a precisão importa mais do que o recall. A expansão para mais tipos de defeito, mais corredores e fluxos de dados mais ricos só vem depois de o sistema ter ganho confiança operacional.
Em sistemas críticos para a segurança, o valor não vem de algoritmos sofisticados. Vem da coordenação entre pessoas e dados, da explicabilidade, da redução da fricção operacional e de um design orientado para a adoção real.
Protótipo ativo
Construído em Figma Make — uma aplicação React funcional, não uma maquete. Abra a versão em ecrã inteiro para interagir com a lista de anomalias, abrir uma vista de detalhe e usar o painel de ações.
Proposta de piloto
O BaseLine foi desenhado para ser validado num piloto operacional de 90 dias antes de qualquer compromisso com uma implementação mais ampla. O piloto está estruturado para produzir evidência binária: os engenheiros agem de forma diferente por causa dele, ou não?
Acesso aos dados existentes dos comboios de auscultação para um corredor — sem hardware novo além da escala do piloto. Quatro a seis engenheiros de triagem de manutenção a participar em sessões de revisão quinzenais. Um compromisso de que as recomendações do piloto não geram responsabilidade, a menos que o engenheiro opte por agir com base nelas.
Sinal de sucesso principal: 30% ou mais das anomalias revistas resultam numa alteração da prioridade de inspeção ou manutenção. Sinais secundários: os engenheiros reportam ter tomado consciência mais cedo de defeitos que não teriam detetado tão depressa; a taxa de falsos positivos mantém-se dentro da tolerância autodeclarada; zero incidentes operacionais causados por recomendações do piloto. Sinal de falha: a ferramenta é consultada uma vez e ignorada; os alertas são descartados sem revisão; os engenheiros pedem PDFs em vez disso.
Segunda classe de defeito (queimaduras de roda). Corroboração submetida pelos maquinistas (apenas após paragem, sem interação em andamento). Cobertura alargada de corredores. Companheiro móvel só de leitura. Camada de planeamento de manutenção preditiva. Cada passo depende de o anterior ter provado impacto no comportamento — não da capacidade técnica de o construir.
O protótipo está completo e documentado. A especificação de integração, a facilitação de investigação UX e o desenho do piloto estão disponíveis. Os interessados podem contactar-me em josue@perex.design ou marcar uma chamada de 30 minutos.
Resultado
Um protótipo funcional validado com um quadro de investigação estruturado, com uma definição de MVP rigorosamente delimitada e uma proposta de piloto concreta. O BaseLine não é um conceito — é uma ferramenta de apoio à decisão que pode ser colocada à frente de engenheiros de manutenção e avaliada com base em resultados comportamentais mensuráveis em 90 dias.
A investigação, o protótipo e o quadro do piloto estão disponíveis. O próximo passo é um operador parceiro.
Como foi feito
O BaseLine foi investigado, especificado e prototipado com assistência de IA do princípio ao fim, trabalhando com o Claude na investigação do domínio e com o Figma Make na construção interativa. As decisões de âmbito — o utilizador único, o engenheiro de triagem, e a exclusão das linhas de alta velocidade AVE — foram as partes que nenhuma ferramenta fez por mim.
A direção de produto, as restrições e cada decisão de julgamento são minhas. Refiro o método explicitamente porque é assim que trabalho agora — e porque ser vago quanto à proveniência iria contra o próprio argumento.