Relatório de Rendimentos
Escopo
O relatório de rendimentos era um compilado de informações no formato de uma extensa (e confusa) planilha com informações sobre o desempenho das usinas da companhia, atualizada manualmente entre o final do mês corrente e início do seguinte.
Os usuários a consumiam apenas como fonte de dados para suas outras planilhas, estas eram compostas juntamente com outras fontes de dados para então permitirem ter um panorama do desempenho da produção.
O objetivo do projeto foi consolidar todas as informações em um só lugar que fosse mais amigável e de fácil entendimento. O formato definido foi de um PowerBI.
Função
Product Designer
Pesquisa com usuários, Arquitetura da informação, Prototipação, Testes de usabilidade, Homologação
Ferramentas
Miro, Figma, Excel, Word, PowerBI
Contexto
Atuei como consultor numa empresa do ramo de siderurgia entre Maio de 2022 e Agosto de 2023.
Minha equipe era responsável por dar suporte aos especialistas que cuidavam das análises do desempenho das usinas de aços especiais através de soluções de tecnologia.
Durante meu período lá meu papel envolvia desde criação e concepção de novos produtos, quanto a implementação de processos de design centrado no usuário, condução de workshops e difusão de conhecimentos de design em geral
O processo
Entendendo o problema
Para mitigar perdas decorrentes de erros de produção da usina, analistas, especialistas e traineers tem como responsabilidade analisar a produção e identificar erros e problemas que tenham gerado sucata.
Essas análises são feitas diariamente e o responsável por ela constrói planilhas e outros BIs que servem como seu relatório pessoal, que por sua vez são alimentadas por outras N planilhas ou dados exportados de outros sistemas.
É muito comum haver haver divergências entre os índices oficiais e os relatórios particulares utilizados nas análises diárias devido as metodologias diferentes empregadas para os cálculos, além disso, a falta de padronização gera desconfianças sobre questões apontadas por algum analista, levando a questionamentos e atritos entre as áreas envolvidas. Mesmo quando não há divergências entre os analistas, criar correlações entre diferentes problemas e soluções tornou-se impossível.
Leva-se um tempo considerável construindo a análise de um problema, que seria melhor aproveitado resolvendo o problema em si e o usuário não quer perder tempo nessas construções, ele quer entender o que está ocorrendo.
Persona do analista
Para facilitar a construção de possíveis soluções com o time, foi criada a persona do analista
Porém haviam questões que deveriam ser contornadas: as usinas possuem equipamentos, rotinas e produção diferentes, o que leva a jornadas diferentes dos usuários. Além disso também havia as alçadas, um gerente não iria olhar para os mesmos dados que um analista júnior ou trainee.
Portanto, a persona seria composta com os pontos em comuns de dores e necessidades acerca do uso do relatório.
As imagens que a ilustram foram retiradas do site Pexels e no geral ela foi útil ao time durante nossas sessões de brainstorm de ideias.
Pensando em soluções
O relatório será unificado e sua página inicial servirá como um hub com informações consolidadas da produção total, a navegação irá segmentar os dados de acordo com cada usina.
Os relatórios de cada unidade levarão em conta os processos e equipamentos que não são os mesmos para cada planta, a filtragem dos dados também será adequada ao contexto de onde estão inseridos.
Substituir as planilhas por gráficos onde for possível. A filtragem dos dados do relatório deverá ser feita preferencialmente selecionando as partes dos gráficos, por ser um método que os usuários estão habituados a utilizar.
O design system da companhia será aplicado utilizando como referência os componentes adaptados de outro projeto desenvolvido para a mesma plataforma.
O relatório será alimentado automaticamente com os dados vindos das usinas, sem necessidade de ações manuais.
Ações precisarão ser tomadas em relação a confiabilidade das informações na sua origem.
Primeira versão
Decidimos criar um conceito MVP para viabilizar os testes de usabilidade e colher feedbacks o mais rapidamente possível, por isso iríamos focar em construir o relatório em torno das necessidades de uma área (Aciaria), e depois iríamos adaptá-lo para as outras (Laminações).
Após diversas conversas com a área de TI para mapear as limitações técnicas, a primeira versão do protótipo do relatório foi criada e então submetida a um teste com usuários.
Resultados do primeiro teste
06 participantes do teste
84 tarefas realizadas:
- 45 sem dificuldades (verde)
- 17 com alguma dificuldade (amarelo)
- 22 com muita dificuldade ou não concluídas (vermelho)
Principais dificuldades encontradas foram:
- Arquitetura da informação
- Falta de interação com gráficos – impossibilidade de utilizá-los como filtros
- Falta de conteúdos específicos
- Escrita do relatório
Aprendendo com os resultados
Depois de compilar o resultado dos testes, foi a hora de confrontá-lo com as nossas hipóteses iniciais.
Versão Final
Com os aprendizados obtidos durante os testes de usabilidade, fizemos uma revisão completa do conceito.
Em relação a arquitetura do relatório, a landing page continuaria sendo um panorama global do desempenho de todas as usinas que formavam a vertical onde a squad atuava, com navegação para o panorama global de cada usina de forma individual.
A navegação entre perdas na produção (que utiliza a métrica de quilos por tonelada ou toneladas) e de rendimento da produção (porcentagem) foi repensada como se o usuário alternasse entre abas. Também foi incluso um filtro onde é possível definir o período a qual os dados se referem.
A estrutura de consolidar dados em um panorama também foi aplicada na página de perdas e rendimentos, onde é possível ter um consolidado de toda a usina além dos setores individuais.
Por fim, ao interagir com os gráficos ou suas opções de filtragem, todos os dados da página são alterados de acordo com o que foi selecionado, como por exemplo, o usuário selecionar no gráfico de Perdas no período a opção Qualidade todo o relatório de perdas se adequa a seleção.
Resultados do segundo teste
04 participantes do teste
48 tarefas realizadas:
- 25 sem dificuldades (verde)
- 10 com alguma dificuldade (amarelo)
- 10 com muita dificuldade ou não concluídas (vermelho)
Insights:
- Comparado com primeiro teste houve menos dificuldade dos usuários ao realizar as tarefas dentro do protótipo
- Aproximadamente 1/3 das dificuldades eram provenientes de um gráfico específico, o restante relacionado a rótulos e textos
Conclusão e status atual
Depois dos devidos ajustes na versão final dos protótipos, e a validação destes com TI e stakeholders, encaminhei o relatório para a equipe de desenvolvimento. A estrutura estava pronta e foi homologada por mim quando saí da empresa, e hoje provavelmente o projeto se encontra disponível para uso.
Alguns dados
Participantes das fases de testes e pesquisa
Usinas que irão utilizar o novo formato
Minutos o tempo para analisar as informações no novo formato proposto*
Protótipos criados ao longo do projeto
Alterações realizadas entre a primeira e a última versão dos protótipos
Sprints de 15 dias entre o kickoff e o handover
*De acordo com os usuários que participaram do teste