O projeto aconteceu em uma grande e tradicional siderúrgica nacional, em uma operação que reunia três usinas de produção de aços especiais.

O Relatório de Rendimentos era o principal instrumento utilizado para acompanhar o desempenho das usinas. Embora tivessem o mesmo objetivo, elas possuíam estruturas e equipamentos diferentes, o que tornava a coleta e consolidação dos dados um desafio. As informações estavam espalhadas entre diferentes planilhas e sistemas e, ao mesmo tempo, falhas recorrentes na produção resultavam em sucateamento de material, mantendo os índices acima das metas estabelecidas.

A equipe já havia iniciado uma primeira tentativa de transformar aquelas informações em um dashboard. No entanto, o resultado ainda não respondia às necessidades dos especialistas e deixou claro que o problema precisava ser entendido antes de qualquer solução visual.

Durante uma das entrevistas em profundidade da fase de pesquisa, pedi a um gestor que me mostrasse como construía o principal relatório utilizado pela área para acompanhar a operação e orientar as decisões do dia a dia. Em vez de explicar, ele abriu a própria agenda.

Todas as manhãs, cerca de uma hora e meia do seu dia era dedicada apenas à consolidação manual de informações para essa reunião. O processo envolvia consultar diferentes planilhas, navegar entre sistemas distintos, conferir números e reunir tudo em um único relatório.

Naquele momento, ficou claro que o problema não era produzir relatórios. Era o tempo que especialistas estavam gastando apenas para conseguir entender o que estava acontecendo.

Em outra entrevista, pedi a uma especialista que me mostrasse como analisava a produção. Assim que ela tentou abrir uma das planilhas, o computador travou. Ficamos mais de dez minutos esperando, sem conseguir fazer absolutamente mais nada. Ela apenas sorriu, meio sem graça, como quem já tinha se acostumado com aquilo.

Ela comentou:

“O Excel não está respondendo. É a frase que mais vemos por aqui.”

O Relatório de Rendimentos era o principal instrumento utilizado para acompanhar o desempenho das usinas da companhia. O projeto teve como objetivo transformar esse processo de análise em uma experiência mais eficiente, reduzindo o esforço necessário para acessar e interpretar as informações.

Atuei como Product Designer conduzindo a investigação do contexto, entrevistas com usuários, definição da experiência, prototipação, testes de usabilidade e acompanhamento da implementação junto ao time de desenvolvimento.

A solução foi desenvolvida em Power BI e consolidou em um único ambiente informações que antes eram analisadas por meio de diferentes planilhas e outras fontes de dados.

Product Designer

Investigação do contexto, pesquisa com usuários, arquitetura da informação, prototipação, testes de usabilidade, acompanhamento da implementação.

Miro, Figma, Excel, Word, PowerBI

As entrevistas revelaram que o problema ia muito além da dificuldade de visualizar informações.

Especialistas gastavam boa parte do tempo consolidando dados manualmente, gestores dedicavam horas da rotina à preparação de relatórios e diferentes áreas passaram a criar soluções próprias para suprir limitações do processo existente. Aos poucos, ficou claro que a dificuldade não estava apenas na ferramenta utilizada, mas na forma como a informação era produzida, organizada e utilizada para apoiar decisões.

Também ficou evidente que existiam limitações importantes na infraestrutura de dados. Nem todas as informações estavam disponíveis da mesma forma ou no mesmo momento, obrigando diferentes equipes a criar adaptações para conseguir trabalhar. Como consequência, além do retrabalho operacional, surgia um problema ainda maior: a confiança nos próprios números.

Foi nesse momento que ficou claro que ainda não era hora de discutir interfaces. Antes, era preciso entender quais problemas realmente valia a pena resolver.

Sintetizando o aprendizado

Toda a pesquisa foi consolidada em uma persona que representava o comportamento observado nas entrevistas, reunindo necessidades, dores e objetivos compartilhados pelos diferentes especialistas e gestores envolvidos no processo.

Persona sintetizando todos os aprendizados da pesquisa

Mas a pesquisa não serviu apenas para representar usuários.

Ela passou a orientar todas as decisões do projeto.

Hipóteses que orientaram o projeto

Antes de iniciar qualquer proposta de interface, reunimos Produto, Desenvolvimento e Design para transformar os aprendizados da pesquisa em hipóteses.

Ainda não estávamos discutindo telas, mas definindo quais problemas precisavam ser resolvidos.

Entre os principais estavam:

• reduzir o tempo necessário para construir análises;
• consolidar informações dispersas em um único ambiente;
• facilitar o acesso às informações mais importantes da operação;
• apoiar decisões rápidas sem aumentar a complexidade da navegação;
• considerar desde o início as limitações da infraestrutura de dados e da plataforma escolhida.

Essas hipóteses serviram como referência para todo o restante do projeto. Cada decisão de Design passou a ser tomada tentando responder uma pergunta simples:

Essa solução aproxima ou afasta o usuário do objetivo que identificamos durante a pesquisa?

Com os problemas mais claros e as hipóteses definidas, o próximo passo deixou de ser simplesmente desenhar telas.

Era preciso transformar aqueles direcionamentos em uma solução que equilibrasse necessidades dos usuários, objetivos do negócio e limitações técnicas.

Ao longo do projeto, cada nova descoberta, restrição ou validação refinava a proposta inicial. O resultado não foi uma única grande decisão, mas uma sequência de pequenas escolhas que moldaram a experiência final.

Decisão 1: Organizar a informação antes de desenhar a interface

A primeira proposta buscava concentrar a maior quantidade possível de informações em poucos dashboards, utilizando filtros para navegar entre as diferentes usinas.

À medida que o entendimento do contexto evoluiu, percebemos que essa abordagem aumentava a carga cognitiva e concentrava informação demais em uma única tela.

A arquitetura foi então reorganizada em níveis de aprofundamento. Em vez de iniciar a análise diretamente pelos detalhes, o usuário passava primeiro por um panorama geral da operação e, somente quando necessário, avançava para análises cada vez mais específicas.

Foi essa estrutura que passou a orientar todo o restante do produto.

Da esquerda para à direita, wireframe, primeira versão e versão final.

Decisão 2: Projetar para aprofundar, não para procurar

Depois da visão geral, o próximo passo era entender onde estavam concentradas as maiores perdas da produção.

A página responsável por essa etapa reunia diferentes indicadores e visualizações que ajudavam especialistas a analisar o desempenho da operação. Entre esses componentes, existia também uma grande tabela utilizada para localizar informações específicas por meio de filtros.

Embora concentrasse todos os dados necessários, a dinâmica de uso ainda lembrava o processo realizado nas planilhas: primeiro era preciso configurar filtros para só então começar a investigação.

Durante o refinamento da solução, um dos principais conjuntos de visualizações da página foi reorganizado para assumir um papel central na navegação. Quatro gráficos passaram a representar as dimensões mais relevantes da análise e, aproveitando um comportamento nativo do Power BI, qualquer interação em um deles filtrava automaticamente todos os demais componentes da tela.

Na prática, a análise deixou de depender principalmente da busca por filtros e passou a acontecer diretamente pela exploração dos próprios dados. Cada clique aprofundava a investigação, preservando o contexto e reduzindo o caminho necessário para chegar às informações mais importantes.

A tabela permaneceu disponível para consultas detalhadas, mas deixou de ser o principal ponto de partida da análise.

Decisão 3: Equilibrar profundidade e simplicidade

À medida que novas restrições técnicas surgiam — disponibilidade de dados, limitações do Power BI e necessidades específicas das usinas — algumas ideias inicialmente consideradas precisaram ser abandonadas.

Em vez de buscar a visualização “ideal”, cada decisão passou a procurar o melhor equilíbrio possível entre clareza, desempenho e viabilidade técnica.

Esse processo fez com que algumas páginas incorporassem mais componentes do que o inicialmente previsto. Ainda assim, a organização hierárquica das informações e a navegação progressiva preservaram a facilidade de uso durante as análises.

Diferença entre o entendimento inicial (Wireframe) e a versão final do início do dashboard de rendimentos de uma usina.

Conclusão

Ao final do projeto, percebi que a maior parte das decisões não estava relacionada à aparência da interface.

Elas nasceram da necessidade de equilibrar comportamento dos usuários, limitações técnicas, disponibilidade dos dados e objetivos do negócio.

O dashboard final foi consequência desse processo, e não seu ponto de partida.