Quando iniciei este projeto, imaginava que o desafio seria desenvolver uma forma melhor de visualizar dados. As primeiras entrevistas mostraram que o problema era muito maior.

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 na usina.

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

À medida que eu conhecia melhor a rotina das diferentes áreas, um padrão começou a surgir. Independentemente da função, especialistas e gestores enfrentavam dificuldades muito parecidas. Antes mesmo de conseguirem analisar qualquer indicador, era necessário consolidar informações vindas de diferentes fontes, conferir números e preparar relatórios manualmente.

Mas uma descoberta mudou completamente a forma como eu enxergava aquele contexto.

Algumas áreas haviam desenvolvido seus próprios dashboards para realizar exatamente o mesmo tipo de análise. Minha primeira reação foi entender de onde aqueles dados vinham e por que existiam soluções paralelas para um problema que já possuía uma base oficial consolidada.

A resposta não estava na ferramenta.

Ela estava na confiança dos dados.

Embora existisse uma base oficial consolidada, divergências ocasionais faziam algumas áreas recorrerem a processos próprios para realizar suas análises. Quando os números não coincidiam, grande parte do esforço passava a ser descobrir qual informação estava correta, e não analisar os resultados.

Além disso, limitações na infraestrutura de dados faziam com que diferentes áreas criassem adaptações para conseguir trabalhar.

Ficou claro que o desafio nunca foi apenas substituir uma planilha por um dashboard.

Era reduzir o trabalho necessário para que especialistas e gestores chegassem à informação em que realmente podiam confiar.

Síntese da pesquisa

Como essas dificuldades se repetiam entre diferentes pessoas e áreas da empresa, organizei as principais descobertas em uma persona. Ela sintetizou o contexto de trabalho, o fluxo de análise e os principais obstáculos identificados durante a pesquisa, servindo como referência para as decisões de design apresentadas a seguir.

Persona sintetizando todos os aprendizados da pesquisa

Com o problema mais claro, o próximo passo não foi desenhar telas, mas definir como organizar a informação.

As entrevistas mostraram que o desafio não era apenas reunir indicadores em um único lugar. Os especialistas precisavam começar por uma visão geral da operação e, conforme identificavam um problema, aprofundar a análise até encontrar sua origem. Ao mesmo tempo, cada nova decisão precisava considerar limitações técnicas da plataforma, disponibilidade dos dados e novas descobertas sobre o contexto do negócio.

Por isso, a solução evoluiu continuamente ao longo do projeto. O que começou como uma proposta de concentrar todas as informações em poucos dashboards foi sendo refinado em conjunto com o Product Owner, restrições técnicas e testes com usuários.

Cada mudança apresentada a seguir representa uma decisão tomada durante esse processo.

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

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

À medida que o projeto evoluía, ficou claro que essa abordagem aumentava a complexidade da navegação e concentrava informação demais em uma única tela.

A arquitetura foi então reorganizada em níveis de aprofundamento. O usuário começava por um panorama geral da operação e, conforme necessário, avançava para análises cada vez mais específicas.

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

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

Decisão 2: Projetar para aprofundar, não para mostrar tudo

Na proposta inicial, o detalhamento das perdas era realizado por meio de uma grande tabela acompanhada de diferentes opções de filtragem. Embora reunisse todas as informações necessárias, a interação ainda reproduzia a lógica das planilhas: primeiro era preciso configurar filtros para só então encontrar os dados relevantes.

Durante o refinamento da solução, esse componente foi completamente redesenhado. A tabela deu lugar a quatro gráficos interligados que sintetizavam as informações mais importantes para os especialistas. Aproveitando um comportamento nativo do Power BI, qualquer interação com um desses gráficos atualizava automaticamente os demais componentes relacionados da página.

Com isso, a análise deixou de depender da busca manual por informações. Os usuários passaram a explorar os dados diretamente pelos gráficos, aprofundando a investigação em poucos cliques e mantendo todo o restante do dashboard sincronizado com a seleção realizada.

Decisão 3: Adaptar a solução às limitações do contexto

Nem todas as decisões vieram da pesquisa com usuários.

Durante o desenvolvimento surgiram limitações da própria infraestrutura de dados e da plataforma utilizada. Algumas visualizações planejadas precisaram ser abandonadas e outras foram reorganizadas para preservar o entendimento sem comprometer desempenho ou viabilidade técnica.

Ao longo desse processo também ficou evidente que reunir todas as usinas em um único dashboard aumentava a complexidade da navegação e trazia questões organizacionais sensíveis. A solução evoluiu para painéis dedicados por usina, mantendo uma visão consolidada apenas como ponto de partida.

O resultado foi uma navegação mais simples, escalável e alinhada à realidade operacional da empresa.

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.