Esta plataforma não é voltada ao torcedor. Seus usuários são as pessoas que colocam as partidas na televisão: a equipe que planeja câmeras, sinais, posições de comentário e janelas de entrega para a temporada de uma liga nacional. Esse público muda toda decisão de design — densidade em vez de decoração, tudo escaneável de relance, e nenhuma interação que custe um clique a mais em dia de jogo.

A arquitetura de informação se acomodou em dois níveis. Um dashboard dá a visão da temporada inteira: o que está agendado, o que está em risco, o que precisa de decisão hoje. Uma view de detalhe da partida reúne seis abas, cada uma alinhada a uma seção da especificação de produção do cliente, então a equipe navega pela ferramenta com o mesmo vocabulário que já usa nos próprios documentos. As abas compartilham um mesmo esqueleto de layout, o que mantém a densidade consistente e o código pequeno.

O backend ainda não existia, e esperar por ele teria custado o cronograma inteiro. Então a primeira entrega não foi uma tela — foi um contrato de dados JSON acordado, negociado com o time de backend e congelado antes de qualquer lado começar. Construí todas as views contra mocks que seguiam exatamente esse formato; quando os endpoints reais chegaram, entraram sem retrabalhar uma única view. Três meses do kickoff a um frontend que a equipe podia usar.

Ao lado do novo frontend em Angular havia uma interface administrativa em ASP.NET já existente — funcional, e visualmente uma década atrás do produto ao qual agora pertencia. Refinei no lugar em vez de propor uma reescrita que ninguém tinha orçamento para pagar: apertei espaçamento e hierarquia, alinhei os controles à nova linguagem de design e corrigi as interações que deixavam o trabalho administrativo de rotina mais lento do que precisava ser. Trabalho sem glamour, e a melhoria mais rápida disponível para o dia real da equipe.