[UX Design case] GM Benefits — Plataforma de benefícios flexíveis para as empresas
Neste artigo vou descrever com detalhes um estudo de caso desenvolvido para o curso de UX/UI Design da Awari.
O objetivo do curso, de 200 horas, é de abordar os principais tópicos da construção de um produto, passando pelas seguintes etapas: concepção do problema, user research, artefatos de síntese, contextos de negócios, metodologias de desenvolvimento, arquitetura da informação, wireframes, mockups, prototipação e construção de um guia de componentes.
Além disso, ao longo do curso eu tive o auxílio da Veronica Sartori, minha mentora, e do Luiz Bordim, meu professor. Gratidão enorme por todas suas colaborações no desenvolvimento do meu projeto.
A escolha do problema
A primeira tarefa proposta foi de escolher um problema real que pudesse ser resolvido. Por conta do meu background profissional no setor de RH, decidi então seguir por esse caminho.
Fazendo uma breve análise com pessoas do meu ciclo pessoal, vi que era uma reclamação em comum entre meus colegas sobre os benefícios que eles recebiam em suas empresas, os quais não variavam muito do tradicional: vale refeição e vale transporte. Dessa forma, pensei que a insatisfação com benefícios empresariais poderia ser um bom problema a ser abordado.
Entretanto, para validar se esse é de fato um problema, fiz uma série de pesquisas (desk research) a fim de levantar dados relevantes sobre tal assunto.
Depois de estudar bastante sobre a área, pude notar que, de acordo com os dados das pesquisas, esse era de fato um problema existente. Além disso, vi também que benefícios flexíveis e customizados pode ser uma boa solução para tal problema. Os dados pesquisados apontaram que tal a adoção desses benefícios flexíveis resulta em um aumento da produtividade do colaborador, redução do turnover de contatações e aumento da visibilidade e de atração de novos talentos.
Beleza! Problema encontrado e um forte indício de solução também encontrado. Com isso, tracei como objetivo prototipar uma plataforma de rede de benefícios flexíveis, onde o usuário final (funcionário ou colaborador da empresa) terá acesso a todos os benefícios oferecidos pela empresa, incluindo opções alternativas às tradicionais, como Netflix, Gympass, Spotify, descontos em lojas, dentre outros.
User research e construção de personas
A etapa seguinte do projeto foi a de validação da ideia. Na minha cabeça as peças já começaram a se encaixar, mas precisava saber com as pessoas se de fato a minha proposta seria uma solução para tal problema.
Para validar a proposta, realizei uma pesquisa no Google Docs com perguntas objetivas com a intenção de saber o grau de relevância dos benefícios para as pessoas, bem como entender melhor seus perfis.
Divulgada em diversos canais de redes sociais, dos mais variados nichos, obtive em 2 dias 96 respostas. Dentre essas 96, selecionei 6 pessoas com perfis distintos para realizar entrevistas e entender mais profundamente sobre seus perfis.
O objetivo primordial da pesquisa foi, sobretudo, anular objeções referentes a achismos e suposições levantadas pelos stakeholders.
Dessa forma, consegui destacar padrões através dos dados coletados, os quais serviram não só como norte no momento de construção do produto, mas também para possibilitar uma entrega com maior assertividade e empatia. Além disso, todas as funcionalidades foram pensadas e prototipadas em solucionar dores dos perfis de usuários que participaram desta pesquisa.
Com os dados compilados e os padrões em mãos, construí um mapa de empatia para, assim, desenhar as minhas personas.
Pude perceber, de acordo com os dados coletados, que tive 3 padrões distintos de acordo com suas preferências pelos benefícios: um perfil mais júnior que prefere benefícios em alimentação, um perfil de nível mais pleno que prefere benefícios em educação e um perfil de nível sênior que prefere benefícios na área de saúde. Portanto, foram criadas três personas distintas:
Destaco aqui que não busquei focar tanto em levantar dados demográficos nas entrevistas. Dessa forma eu almejei dar um enfoque maior em descobrir quais são as necessidades e os desejos dos entrevistados.
As pesquisas foram fontes valiosas de muitos insights que se tornaram funcionalidades no protótipo. Foram 4 a 5 semanas dedicadas à etapa de user research.
Desenvolvimento da solução
Nas etapas predecessoras à arquitetura de informação, realizei um forte benchmarking e utilizei a metodologia Jobs to be done para me auxiliar na construção das soluções para o aplicativo.
O benchmarking teve o objetivo de buscar referências através de aplicativos, estudos de caso e concepções. Nesta etapa foram analisadas não só concorrentes diretos e indiretos, mas também empresas de outros setores e trabalhos publicados em sites específicos, como Dribbble e Awwwards, por exemplo.
Para construir as funcionalidades do produto, utilizei a metodologia de Jobs to be done baseado no artigo que li do professor Marcelo Nakagawa, onde ele divide as tarefas de acordo com as necessidades do usuário, partindo desde uma funcionalidade mais básica até uma funcionalidade onde o cliente se sinta melhor em relação aos demais por utilizar determinado produto.
A partir da aplicação dessa metodologia, consegui documentar e priorizar as funcionalidades do meu aplicativo, o que foi de suma importância para agilizar meu processo de construção da arquitetura de informação do produto.
Portanto, antes de iniciar a fase seguinte, foi decidido que seria construído um aplicativo que ofereceria benefícios flexíveis divididos em 7 categorias:
- Saúde e bem-estar
- Mercado e express
- Refeição
- Educação
- Cultura
- Mobilidade
- Saldo livre
Além disso, dentro do aplicativo seria possível visualizar faturas dos gastos, transferir saldos entre as categorias, ter acesso a cupons de desconto de empresas parceiras e pagar contas diversas utilizando o saldo livre (contas de água e luz, por exemplo).
Arquitetura de Informação
Essa é uma atividade fundamental para construir as telas do aplicativo de forma assertiva e não gerar retrabalho nas etapas posteriores. Sabendo disso, foram construídos:
- Fluxo do usuário
- Sitemap
- Organograma de telas
Foram cerca de 8 a 10 dias dedicados para a validação do fluxograma e do organograma de telas, haja vista a importância de ter todos os fluxos bem definidos antes de iniciar os esboços das telas. Outro ponto a ser destacado aqui é a facilidade e agilidade em fazer alterações nos fluxos em relação às telas, ou seja, as alterações aqui requerem menos esforço do que se fossem feitas em cima de telas/wireframes já prontos.
Fazendo o esqueleto: sketches e wireframes
Uma vez que a arquitetura de informação havia sido finalizada e aprovada pela minha mentora, chegou a hora de iniciar as primeiras versões da tela.
Até a versão final do protótipo foram feitos 3 tipos de telas, em uma evolução de níveis de fidelidade:
- Esboços no papel: baixa fidelidade
- Wireframes em escala de cinza já no Figma: média/alta fidelidade
- Mockups com cores e componentes: alta fidelidade
A seguir estão algumas fotos dos sketches feitos no papel antes de serem transformados em wireframes no Figma:
Feitos os esboços, parti para a confecção de wireframes já com o UX Writing pronto. Nesta etapa eu não me preocupei com escalas de cores, imagens, ícones dos benefícios e animações de transições. O objetivo foi de deixar eles o mais próximo do que seriam os mockups e já com as ligações entre telas para, posteriormente, realizar um teste de usabilidade.
Segue alguns dos principais wireframes:
Finalizada e validada a primeira versão dos wireframes, estruturei um roteiro de teste de usabilidade com o objetivo de validar os fluxos do usuário, bem como analisar os gargalos e empecilhos encontrados pelos usuários ao longo da sua jornada.
Para tal teste, elaborei 12 atividades que contemplassem todos os fluxos desenhados anteriormente. Em uma ligação pelo Zoom, foram feitas três sessões com usuários distintos, onde eu pude avaliar suas ações através do compartilhamento de telas.
Ao final das sessões, identifiquei alguns gargalos, como a dificuldade em reconhecer o significado de ícones, dificuldades com senhas, dentre outros detalhes observados. Ao final pedi que dessem sugestões de pontos a serem melhorados, o que também me ajudou na análise final desses testes.
A importância em realizar o teste de usabilidade nesta fase foi de ganhar agilidade caso houvesse alguma alteração (e houve). Por ser um wireframe de alta fidelidade, é possível avaliar os principais fluxos de navegação já nessa etapa. Tais alterações poderiam levar mais tempo se fossem feitas na fase de mockup.
Resultados finais
Funcionalidades definidas, fluxos definidos e a base das telas já definidas. Agora o objetivo é dar vida ao protótipo: cores, ícones, componentes, sombras, alinhamento e, por fim, animações de transições.
A seguir, irei mostrar os fluxos das principais atividades e comentar sobre cada um. Ao final desse estudo de caso será disponibilizado os links para os protótipos e o arquivo do Figma.
Guia de estilo e componentes
Um dos tópicos abordados no curso foi sobre Design System, entretanto, por se tratar de algo bastante robusto e completo, torna-se algo que fugiria um pouco da proposta do curso.
Porém, para aplicar alguns dos conceitos de design system, fiz a documentação de alguns elementos do design da GM Benefits. Foram elas:
- Cores primárias e secundárias
- Tipografia e suas características (tamanho, espaçamento, peso, etc)
- Iconografia usada
- Grids utilizados
- Espaçamentos entre elementos
- Componentes utilizados
Conclusões
A construção do produto se iniciou no dia 30 de agosto de 2020 e terminou no início de dezembro de 2020. Foram meses intensos para a construção de um produto que tenha funcionalidades relevantes e que solucionem um problema real.
Ao longo do curso eu passei por todas as etapas de construção de um produto digital, onde pude aprender os principais conceitos, metodologias e ferramentas utilizados no mercado. É importante ressaltar que tudo isso apoiando no design thinking, ou seja, na mentalidade de resolver problemas através de processos criativos e voltados ao usuário.
As mentorias com a Veronica e as aulas ao vivo (principalmente as de dúvidas) foram de grande importância para otimizar meu tempo e esforço nas atividades mais prioritárias.
Muito obrigado pela sua atenção. Esse é só o começo!
Contatos e links
LinkedIn: linkedin.com/in/gabrielpmesquita/
Behance: behance.net/gabrielpmesquita
Email: gabrielpmesquita.contato@gmail.com
Link do protótipo: https://www.figma.com/proto/Kq8eeyrziACa7MSYfOgd0H/Wireframes-GM-Benefits?node-id=246%3A621&scaling=scale-down
Link do arquivo das telas: https://www.figma.com/file/Kq8eeyrziACa7MSYfOgd0H/Wireframes-GM-Benefits?node-id=246%3A470