Estudo de caso UX: Design atende a metalurgia

Todo mundo tem que começar em algum lugar, certo? Aqui está o meu ponto de partida como designer de UX.

Zsolt Kalman Blocked Desbloquear Seguir Seguindo 6 de janeiro

Quando vi pela primeira vez “design” e “metalworking” na mesma frase, eu sabia que estava prestes a trabalhar em algo que significava compartilhamento.

Deixe-me dar-lhe um pouco de fundo. A Steiger é uma empresa familiar romena envolvida na indústria metalúrgica. Eles têm uma história bastante impressionante que remonta aos anos 40, quando eles eram um dos mais importantes fabricantes de caldeiras da época. Hoje, o portfólio da empresa inclui algumas das construções civis e industriais mais significativas da região, ao mesmo tempo em que observa um aumento notável em suas vendas de exportação.

Devido à contínua expansão durante a última década, a necessidade de otimizar seu processo tornou-se uma prioridade. Steiger estava contando com vários softwares e planilhas para acompanhar seu trabalho, o que eles logo perceberam ser ineficaz e propenso a erros. Foi quando o C4Studio entrou em cena para ajudar.

Avancemos para os meses seguintes e o brief foi preparado com os processos e funcionalidades que precisavam ser considerados. Mas ainda havia algumas perguntas sobre os usuários e suas rotinas atuais:

  • Quem são os usuários? Os funcionários da fábrica também usarão o aplicativo ou serão dedicados apenas a funcionários de escritório?
  • Os futuros usuários do aplicativo possuem habilidades computacionais suficientes para executar suas tarefas usando o aplicativo?
  • Quando e como cada um deles interage com a informação?
  • Quem são as partes interessadas?
  • Há alguma restrição que precisamos abordar (a solução sendo uma destinada à indústria metalúrgica)?
  • Como podemos garantir que a transição para o novo sistema seja "indolor"?

… Para apontar apenas algumas das questões que surgiram quando tivemos nossa primeira discussão “orientada ao usuário”.

Processo de design

A primeira coisa que fizemos foi elaborar um plano viável para integrar o UX no plano de projeto já orçado. Não foi fácil, mas no final, o C4Studio convenceu as partes interessadas de que valeu a pena investir desde o início, a fim de evitar os custos muito mais altos do design ruim que podem aparecer mais tarde.

Meu plano era usar elementos e técnicas do Design Thinking para obter mais insights sobre os usuários e, assim, fornecer uma abordagem baseada em soluções para o projeto.

Os cinco estágios do Design Thinking

Comecei com os cinco estágios do Design Thinking e descobri maneiras de integrar cada estágio do processo que já estava em andamento.

Enfatizar

Dei uma olhada mais de perto no brief para saber mais sobre a empresa e seu processo interno. Era a minha hora de me atualizar com tudo que a equipe já sabia sobre esse projeto. Bem, quase tudo …

Depois de nivelarmos o campo de jogo, estabelecemos com a equipe de desenvolvimento e começamos a compartilhar as “histórias” que observamos durante nossa pesquisa. A equipe era composta de pessoas com diferentes origens, pontos fortes e pontos de vista em relação ao projeto, por isso pudemos obter alguns insights realmente interessantes e diversificados. Nós agrupamos essas idéias em três categorias: Coisas que sabemos, Coisas que não sabemos e Coisas que assumimos.

O resultado de nossa pesquisa cooperativa

Era hora de esclarecer nossas dúvidas e desafiar nossas suposições … Então agendamos uma reunião com o gerente técnico da Steiger. Nesta reunião, descobrimos muito mais sobre o processo da Steiger e a maneira como os funcionários contribuem para o resultado final.

O principal insight foi que todo o ERP deveria ser considerado como uma solução construída em torno do processo principal. Um processo que se parece com algo assim:

Processo de Steiger

Era hora de definir o problema.

Definir

Ao longo da minha carreira como designer, aprendi que é muito fácil sair dos trilhos e investir em melhorias aparentemente atraentes e ver o produto usado “no caminho errado” depois. Para evitar isso, precisávamos definir um problema claro que esse projeto estava configurado para resolver.

Ao chegar a uma declaração de problema, usamos o método “Point of View” . O resultado foi a seguinte declaração:

Os funcionários da Steiger precisam de ajuda para melhorar seu fluxo de trabalho porque querem evitar erros demorados e frustrantes e querem ser mais eficientes em seu trabalho.

Nos meses seguintes, usamos essa declaração de problema como nosso guia durante todo o projeto. Isso nos ajudou nos momentos em que decisões difíceis e compromissos precisavam ser tomados.

Idealizar

Não se pode argumentar que existem muitas soluções por aí que são muito eficientes na solução das necessidades de negócios que elas devem resolver. O ERP do Steiger foi criado para resolver muitas dessas necessidades de negócios, então pareceu natural usar o método de ideação Cheatstorm . O que fiz foi procurar por conjuntos existentes de ideias de outras soluções e aproveitá-las como insumo para os materiais de que precisávamos.

Partes dos resultados do estágio de ideação: navegação principal, tela inicial, folha de dados do projeto, cálculo do projeto

A ideação trouxe vários desafios, um dos quais era fazer com que partes do sistema fossem fáceis de interagir para os trabalhadores da fábrica, que muitas vezes usavam luvas. Teclados ou mesmo telas sensíveis ao toque industriais não eram uma opção porque é difícil operá-los com luvas. Para completar, também tivemos que lidar com o fato de que a superfície, com a qual os trabalhadores estarão interagindo, ficará gordurosa. Isso significava que não poderíamos colocar informações importantes (como rótulos) diretamente no objeto com o qual o trabalhador interage. Com todas essas “restrições”, optamos pelos códigos QR e scanners. Os scanners eram operados à mão (com ou sem luvas) e não se importavam com a sujeira.

Tela de acesso ao terminal de oficina

Protótipo

Eu peguei meus esboços e mudei para o Figma para gerar maquetes de wireframe de baixa fidelidade para as principais páginas. Foi feito um trabalho extra para flexibilizar todos os elementos da página, a fim de manter uma interface confortavelmente acessível em todos os dispositivos, desde smartphones a grandes exibições. Você pode ver abaixo os modelos para o painel, a página do projeto e a tela de acesso ao terminal da oficina.

Modelos de wireframe de baixa fidelidade para as principais páginas

Com os wireframes no lugar, comecei a trabalhar no design visual do ERP. Primeiro, escolhi as cores principais. Em seguida, criei uma versão menos detalhada do logotipo que planejava usar no cabeçalho.

Ajustes de branding para o ERP do Steiger

Até este ponto, meus colegas estavam trabalhando na arquitetura da informação . Queríamos ter certeza de que o framework que estávamos criando seria capaz de conter todo o conteúdo que precisa aparecer. O conteúdo foi representado principalmente por formulários nos quais os usuários com diferentes direitos e propriedade pretendiam adicionar dados ao longo do ciclo de vida de um projeto. As informações foram estruturadas em páginas agrupadas em seções, representando diferentes estágios do projeto.

Parecia que tínhamos tudo que precisávamos para trabalhar nos protótipos de alta definição. Com o sitemap na minha frente, construí o cabeçalho com a navegação principal:

  • Link do painel de controle / início
  • Outros links importantes relacionados a projetos, fornecedores e clientes
  • Definições
  • Informações e configurações da conta
  • Mensagens
  • Notificações
  • Procurar

Navegação Principal

Nota: Em monitores pequenos, o menu de navegação principal foi acessado pressionando o ícone do hambúrguer. Isso abriu uma gaveta onde todos os itens de menu estão listados.

Quando o cabeçalho estava no lugar, comecei a projetar o painel. Cada tipo de usuário tinha diferentes direitos e diferentes áreas de trabalho e interesse dentro da empresa, portanto, diferentes conjuntos de painéis precisavam aparecer em cada painel. Juntamente com a equipe, criamos uma lista de todos os tipos de painéis e eu projetei todos os painéis individualmente. Depois que todos os painéis foram concluídos, criamos os painéis individuais para cada tipo de usuário. Abaixo, você pode ver o painel do usuário de RH, que era uma das páginas mais complexas.

painel de controle

A página abaixo explora como seria a página de Ofertas. Com base nas informações que recebi dos tecnólogos, os filtros de data foram usados de maneira um pouco diferente do esperado. Tudo isso porque, na maioria das vezes, o usuário não sabe exatamente a data de criação da oferta. Então, levei isso em consideração ao projetar o selecionador de data.

Esperávamos que a página de ofertas nos desse a maior parte das dores de cabeça. Os materiais relacionados a esta página indicaram que a página possuía muitos campos e funcionalidades, impossibilitando ao usuário encontrar o que precisava sem algum tipo de orientação.

Os usuários estavam familiarizados com as etapas de criação da oferta, então decidimos aproveitar isso e agrupar os campos de acordo com sua relevância durante cada estágio do processo.

Nota: Cada estágio tinha a opção de ser bloqueado, aprovado ou dispensado pelo proprietário do projeto. Os ícones à esquerda mostram o status atual do palco. Alguns estágios também têm números exibidos à direita para mostrar que há mensagens sobre esses estágios.

Agrupar os campos em etapas tornou as páginas mais curtas e o processo de preenchimento dos campos menos difícil. No entanto, houve uma etapa específica no processo que ainda esperávamos que os usuários tivessem dificuldades: foi o estágio de cálculo. Esse formulário era complexo e exigia que os cálculos em tempo real fossem feitos em segundo plano enquanto o técnico estava concluindo os campos. Nós conversamos com alguns técnicos e, felizmente, eles já tinham um “hack” para facilitar os cálculos. Eles geralmente dividiam a tarefa em 4 subtarefas:

  • materiais,
  • horas de trabalho para criar as peças,
  • horas de trabalho para montar as peças juntas
  • adicionando-os todos

Criamos guias usando essa estrutura exata e a página começou a parecer muito menos assustadora.

O fato de algumas partes do conteúdo não serem exibidas significava que os usuários precisavam alternar com frequência entre as guias. Para evitar isso, alocamos espaço no visor para mostrar o resultado do cálculo independentemente da guia em que o usuário estava.

Cálculo da oferta

Teste

Depois que as páginas mais importantes foram projetadas, fiz o upload delas para a InVision e criei um protótipo. Em seguida, realizamos alguns testes com “usuários reais” (tecnólogos e gerentes de projeto) para ver como eles se comportariam, pensariam e sentiriam ao interagir com o ERP. Isso me deu algumas idéias preciosas e algumas idéias para melhoria:

  • Os usuários não sabiam onde procurar seu projeto. Em sua mente, Ofertas e Produção não eram itens separados.
  • Os usuários acharam difícil adicionar um novo projeto.
  • Os usuários nem sempre encontravam os botões para salvar seu trabalho.
  • O Dashboard ficou um pouco pesado com a cópia (texto) e o conteúdo geral.

Este foi um teste qualitativo e analisamos cada entrevista separadamente. Como resultado, voltamos e retomamos alguns dos trabalhos que fizemos nas fases anteriores. Abaixo, você pode ver uma captura de tela após esses ajustes.

Conclusão

O Steiger ERP foi o primeiro projeto da minha carreira como designer, no qual havia um orçamento dedicado para UX. Foi interessante ver como o Design Thinking pode ajudar uma empresa que tem tão pouco a ver com design (pelo menos no sentido tradicional).

Próximos passos

Estamos agora em uma fase em que o ERP é lançado e estamos analisando a forma como os trabalhadores estão usando os recursos do projeto. Esperamos que, com o uso de heatmaps e discussões de usuários, possamos melhorar ainda mais o fluxo de trabalho dos funcionários da Steiger.