Tirando orçamentos comerciais do Excel
DURAÇÃO
4 meses (2021)
POSIÇÃO
UI Designer
TIME
1 UI Designer • 1 Gerente de Projetos • 1 Front-end developer • 3 Back-end developers • 1 Arquiteto de Software
Sobre o cliente
Empresa que atua na área de compra e venda de seminovos, bem como locação de equipamentos para os segmentos de construção, mineração, energia, petróleo, marítimo, gás, florestal e agronegócio.
Para manter a confidencialidade do cliente, o seu logo e informações sensíveis aparecerão borrados ao longo do case.
Contexto
Para fazer estudos comerciais e gerar orçamentos para a venda de motores, o cliente usava uma ferramenta que foi desenvolvida no Excel, estruturado para prever todos os custos de manutenção com peças e mão de obra a longo prazo. Essa ferramenta se baseava em dados fornecidos em planilhas pelo fabricante e tinha informações sobre impostos, custos com importação, despesas entre outras.
O projeto consistia em criar uma aplicação web que substituísse o uso dessa ferramenta.
Processo
Entendendo o problema
Junto com o Gerente de Projetos, eu participei de reuniões semanais para entender exatamente quais eram as dores das pessoas usuárias que levaram o cliente a contratar a consultoria para desenvolver esse projeto.
Além do cliente em si, conversamos com funcionários do setor comercial que eram as pessoas que utilizavam as planilhas diariamente. Eles nos apresentaram a ferramenta e cada um demonstrou como a utilizava.
Dependendo do cargo e nível hierárquico da pessoa, ela preenchia dados diferentes e tinha suas dores específicas. Mas no geral, chegamos a dois principais problemas:
Grande esforço operacional
Sempre que havia um novo orçamento, a pessoa usuária tinha que preencher cada valor manualmente, sendo que eram muitas informações. Isso tomava boa parte do tempo dos funcionários, além de causar um prazo maior para envio dos estudos comerciais.
Risco para o negócio
As planilhas necessitavam uma atualização manual dos dados, então se a pessoa usuária não a fizesse, corria o risco de usar valores desatualizados nos cálculos dos orçamentos. O cliente relatou ter sofrido prejuízos financeiros por isso.
Por tratar volumes financeiros em grande escala, a solução que estava sendo usada precisava receber uma atualização para um sistema mais robusto, eficaz e seguro.
Especificação
Junto com o gerente do projeto e o arquiteto, desenhamos todo o fluxo do sistema. Identificamos quais processos de preenchimento manual poderiam ser automatizados (valores que já poderiam vir pré-preenchidos por exemplo), quais informações eram mais relevantes e quais poderiam ser removidas.
Ajudei também a construir os casos de uso com a perspectiva do usuário. Nós fizemos algumas rodadas de feedback com o cliente para que tivéssemos casos bem arrumados antes de partir para os wireframes.
Wireframes
Essa foi a etapa mais complexa que eu passei no projeto. Como haviam muitos campos e tabelas, preferi usar o Axure RP porque ele tem elementos nativos de preenchimento que funcionariam melhor nos testes. Além disso, também pude exportar o protótipo em HTML e enviar para o cliente, para que os testes pudessem ser feitos no seu ambiente local de uma forma segura.
Várias melhorias aconteceram nessa etapa. Foi fundamental testar com as pessoas usuárias nessa fase, porque daí vieram mudanças simples, como melhorias de interface, mas também ajustes significativos que impactaram o escopo e os requisitos.
Style Guide
Enquanto melhorias eram feitas nos wireframes e o time tinha que renegociar o escopo com o cliente, aproveitei para iniciar a análise da marca para montar o style guide do projeto.
O brand book me mostrou que a empresa explorava muitos elementos gráficos quadrados e retos, com informações dentro de “caixas”, inspirado pelo seu logo. Isso me deu a ideia de buscar o Carbon Design System, da IBM, como referência para os componentes da interface.
A cor principal da marca é amarela, então eu tive que fazer alguns ajustes de matiz e luminosidade para que os tons de amarelo usados na interface tivessem um contraste adequado, e preferi usá-los mais como cor de destaque, deixando os tons neutros como predominantes.
Eu tinha iniciado o Style Guide no Adobe XD, mas foi nessa época que comecei a experimentar o Figma e vi que ele seria uma alternativa melhor para lidar com os estilos e componentes que eu estava desenhando.
Protótipo em alta fidelidade
Com o Style Guide definido, desenhei o protótipo usando o Figma. Boa parte da estrutura do layout e das informações já tinha sido definida nos wireframes e validada pelos usuários, então essa etapa foi mais focada em aplicar os estilos e desenhar todas as interações entre elementos e telas em um protótipo navegável, para que eu conseguisse apresentar minhas ideias ao desenvolvedor com mais clareza.
HTML & CSS
O front-end do projeto foi desenvolvido em Angular. Meu trabalho nessa etapa foi preparar todo o estilo (usando Sass, um pré-processador de CSS) e montar as páginas em HTML estático dentro da configuração do projeto que já tinha sido preparada pelo desenvolvedor front-end, para que depois ele fizesse a mágica acontecer. Essa etapa foi bem colaborativa, o desenvolvedor também trazia suas ideias e tivemos conversas diárias ao longo do desenvolvimento.
Desafios e aprendizados
Entender todo o processo de precificação dos motores, incluindo os cálculos que envolvem taxas de operação, impostos, variação cambial… De fato o processo mais complexo desse projeto foi de back office, de garantir a precisão dos cálculos e que os valores das taxas seriam atualizados automaticamente, para que os preços finais fossem exibidos corretamente pelo sistema.
Participar de um projeto tão complexo, com tantas regras de negócio, foi muito enriquecedor para a minha carreira e um dos fatores que me fizeram querer expandir meu escopo de trabalho de UI para Product Design.