O desafio
Uma plataforma inteira para construir num setor que eu não conhecia.
O cliente precisava de uma plataforma web para o setor de energia e sustentabilidade. Operadores usariam o sistema diariamente para registrar lotes de produção, gerenciar misturas de combustíveis, acompanhar certificações e manter rastreabilidade de toda a cadeia.
Eu não tinha experiência prévia nesse setor. Antes de pensar em qualquer tela, precisei entender o que era um lote de produção, como funcionava a mistura de combustíveis sustentáveis, o que significava uma certificação regulatória e como as transferências entre empresas se conectavam. Essa imersão no domínio do cliente foi o que permitiu tomar decisões de design que realmente faziam sentido pro dia a dia dos operadores.
11
módulos interconectados para construir e manter consistentes
+50
telas projetadas ao longo de 1 ano de projeto
Análise
Entendendo o que precisava mudar
Comecei com uma análise de benchmarking para entender como plataformas concorrentes do setor de energia resolviam problemas semelhantes. Estudei a organização da informação, os padrões de navegação e as formas de apresentar dados complexos em tabelas e formulários.
Essa análise me deu diretrizes claras: plataformas desse tipo precisam priorizar eficiência na leitura de dados, navegação previsível e formulários que guiem o operador sem sobrecarregar. Cada decisão de design que tomei depois foi informada por essa base.
Informação fragmentada.
O operador precisava navegar por várias telas para entender a situação de um único veículo. Não existia uma visão consolidada do que estava acontecendo.
Tudo com o mesmo peso.
Prioridades críticas e itens de rotina apareciam da mesma forma na tabela. Para encontrar o que era urgente, era preciso ler linha por linha.
Formulários que tiram do contexto.
Criar ou editar um registro abria uma página inteira nova. O operador perdia a referência de onde estava e o que estava fazendo.
Perfis de usuário
Pra quem eu estava projetando
A plataforma atende três perfis com acessos e necessidades distintas:
Admin:
visão completa da plataforma. Gerencia contratos, configura permissões e acompanha todos os módulos. Precisa de dashboards e visões consolidadas.
Supplier:
registra lotes de produção, submete certificações e acompanha o status das entregas. Seu fluxo principal é entrada de dados e rastreabilidade.
Buyer:
acompanha transferências, valida certificações recebidas e monitora posições. Precisa de visões de acompanhamento e histórico.
Entender essas diferenças foi essencial pra definir o que cada perfil vê e quais ações tem disponíveis em cada módulo.
Fluxo de navegação
Como a plataforma se organiza
Processo
Construir padrões que escalam
Um sistema de navegação consistente
Defini uma estrutura de navegação que se repete em todos os módulos: menu lateral colapsável, navegação por tabs para alternar entre registros ativos e concluídos, tabelas de dados com ordenação e paginação, e uma área de header com busca e botões de ação. Essa previsibilidade reduz a curva de aprendizado do usuário.
Formulários complexos, organizados por seções
Os módulos exigiam formulários extensos com muitos campos obrigatórios e regras de validação. Organizei esses formulários em uma página única dividida em seções temáticas com cards (por exemplo: dados básicos, partes envolvidas e datas, informações financeiras). Isso permite que o operador veja o formulário completo sem precisar alternar entre abas, com campos relacionados agrupados e validações inline que aparecem antes do envio.
Detail views com cards informativos
Para a visualização de registros, criei um padrão de detail view com cards agrupando informações por categoria. Cada card tem um header claro e pares chave-valor organizados. Esse padrão se repete em todos os módulos, com o conteúdo se adaptando ao contexto.
Modais para ações sem perda de contexto
Ações de criação e edição rápida usam modais, mantendo o operador na tela onde está. Modais de confirmação para ações destrutivas (como exclusão de registros) seguem o mesmo padrão visual em toda a plataforma.
Estados de erro e páginas vazias padronizados
Defini um sistema de tratamento de erros consistente: ilustrações para páginas 404 e acesso não autorizado, mensagens padronizadas para dropdowns vazios, e estados de carregamento uniformes. Isso garante que mesmo nos momentos de falha, a experiência seja coerente.
Consistência em escala
Mesma lógica do primeiro ao último módulo
O maior resultado desse projeto não é uma tela individual, mas sim a consistência entre todas elas. Um operador que aprende a usar um módulo já sabe navegar nos outros dez, porque os padrões de interação, a hierarquia visual e os componentes são os mesmos.
Os módulos que projetei cobrem todo o fluxo operacional: contratos, dados históricos, posições, empresas parceiras, registros de produção, lotes puros e misturados, certificações, tokens de registro, submissões regulatórias e transferências entre empresas.
Cada módulo tem suas particularidades de conteúdo, mas compartilha a mesma base de componentes: tabelas, cards, formulários organizados por seções, modais, badges de status e padrões de filtro.
O que aprendi
Três lições desse projeto
Consistência é mais difícil do que criatividade
Projetar uma tela bonita é uma coisa. Manter o mesmo nível de qualidade e coerência em mais de 50 telas, ao longo de meses, é outro desafio completamente diferente. Um design system bem definido desde o início foi essencial pra isso.
Formulários complexos pedem organização, não simplificação forçada
Em plataformas enterprise, os formulários são extensos por necessidade. Tentar 'simplificar' cortando campos não resolve. O que resolve é organizar: agrupar por contexto, dividir em seções claras, validar inline e dar feedback claro ao operador.
Entender o negócio do cliente não é opcional
Se eu tivesse começado a desenhar sem entender o que é um lote, uma certificação ou uma transferência, as telas até poderiam ficar bonitas, mas não resolveriam o problema de quem usa. O tempo investido em aprender o setor se pagou em cada decisão de design que tomei depois.