Product Designer
Dashboard de Rendimentos
Transformando um processo manual de análise em ferramenta de decisão
Papel
Ferramentas
Miro • Figma • Excel • Word • PowerBI
Escopo
Discovery • Prototipação • Testes • Homologação.
01
o problema
De onde veio esse dashboard?
Antes de pensar na solução, era preciso entender o problema que aquela primeira versão tentava resolver.
Visão geral
O Relatório de Rendimentos era o principal instrumento utilizado para acompanhar o desempenho das usinas de aços especiais da companhia.
Antes de eu entrar no projeto, um painel já estava sendo desenvolvido pelo time, a expectativa era de que eu desse um banho de loja na interface dele mas antes de mais nada eu precisava entender qual era o problema que se tentava resolver.
Sugeri e o time aceitou que nós déssemos um passo atrás para investigar todo o contexto antes de pensar em redesenhar qualquer coisa.
Análise inicial que fiz no Miro do painel que a equipe estava criando
Objetivos
Pilares do projeto
01
Unificar todos os dados relevantes para os analistas e gestores
02
O dashboard irá incorporar dados de outros sistemas e do data lake
03
Garantir a confiabilidade dos dados
04
Informações de boletins em papel serão incorporadas após a digitalização.
02
o discovery
Como a análise era feita?
Sem um dashboard dedicado para análise de dados, as coisas funcionavam da seguinte forma:
Exportação de dados
Informações vinham de diferentes planilhas e sistemas, entre elas a versão em planilha do Relatório de Rendimentos. Ocasionalmente boletins em papel.
Consolidação das informações
Os dados eram reunidos e tratados manualmente e então colocados em uma outra planilha. Retrabalho e inconsistências faziam parte da rotina.
Relatório do dia
Por fim, era preciso preparar o relatório usado para acompanhar a produção. Um gestor relatou gastar cerca de 1h30 todas as manhãs nessa preparação.
O que colocamos à prova
A partir da pesquisa, transformamos os principais problemas observados em hipóteses
01
Trocar tabelas por gráficos iria acelerar e facilitar o entendimento das informações
02
Segmentar o dashboard pelas áreas da produção facilitaria a navegação
03
Adaptação de componentes do design system para o PowerBI ajudaria a manter a consistência
04
Análises começam num panorama geral e depois se aprofundam conforme necessário
O que os testes mudaram
Acreditávamos → Observamos → Aprendemos → Ajustamos
O layout
Eu queria testar o dashboard o mais rápido possível, afinal se toda a estrutura desenhada a partir das hipóteses falhasse, uma reestruturação teria de ocorrer bem rápido. Por esse motivo eu optei por utilizar protótipos em baixa fidelidade para por o conceito á prova.
Slides interativos no Figma.Alguns elementos da interface foram alterados para anonimizar as informações.
Hipótese
1. Gráficos irão substituir tabelas
2. Navegação por segmento da produção
3. Filtros em dropdowns
4. Panorama das usinas como ponto de partida
Aprendizado
1. Usuários precisavam de uma leitura rápida e em alguns contextos, mais detalhadas dos dados
2. Usuários pensam primeiro na usina
3. No PowerBI os próprios gráficos servem de filtros, esse comportamento é o esperado pelos usuários
4. O conceito funcionou mas o conteúdo deveria ser revisto
Resposta
1. Rever o que é gráfico, tabela e cards com big numbers destacados
2. Dashboard será divido por usina
3. Interação com os gráficos será método primário de filtragem
4. Reformulação do conteúdo do panorama inicial
03
o resultado
Decisões de design
Das descobertas à solução
Organização da arquitetura
Padronizar a navegação por área parecia o caminho, mas não funcionava na prática. A saída foi estruturar a arquitetura por usina, combinando um panorama geral com as suas áreas específicas.
Exploração através de gráficos
Em vez de entulhar o painel com dropdowns, reorganizei e reagrupei os gráficos para que a própria interação com as barras e segmentos funcionasse como um filtro fluido, rápido e contextual.
Projetar dentro das possibilidades
A disponibilidade dos dados, as limitações do Power BI e as necessidades de cada usina acabavam entrando na conta. A solução foi encontrar, em cada caso, um ponto de equilíbrio.
Protótipo navegável no Figma. Alguns elementos da interface foram alterados para anonimizar as informações.
Do ganho de tempo a novos dashboards
Além de reduzir o tempo de análise nos testes, o projeto serviu de base para a criação de outros dashboards.
-83%
De tempo para analisar os dados comparado ao processo manual
*Média observada durante os testes com o protótipo final.
Deixei a empresa antes da implementação total do dashboard.
04
Outros dashboards criados utilizando essa estrutura
Projetados enquanto o time construía esse.
Focado em dados específicos de duas usinas.
Conclusão
Considerações finais
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.