[UX Design case] GM Benefits — Plataforma de benefícios flexíveis para as empresas

Gabriel Mesquita
9 min readDec 18, 2020

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.

Mapa de empatia feito após as sessões de entrevistas.

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:

Júlia, 20 anos, estagiária e prefere benefícios de alimentação. Procura estabilidade financeira.
Álvaro, 25 anos, perfil pleno e prefere benefícios em educação. Quer crescer na carreira.
Renato, 37 anos, perfil sênior e prefere benefícios de saúde. Busca estabilidade para a esposa e filha.

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.

Abordagem da metodologia de JTBD do prof. Marcelo Nakagawa

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.

GM Benefits — Jobs to be done

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
Sitemap da GM Benefits.
Fluxograma da jornada do usuário em cada etapa do aplicativo.
Organograma de telas feito com base no sitemap.

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:

Tela inicial (dir.) e tela de perfil (esq.)
Telas referentes aos cartões dos benefícios (esq.) e telas de promoções e empresas parceiras (dir.)
Telas da seção “Pagar contas” (dir.) e telas de onboarding de cadastro (esq.)

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.

Esse é o onboarding do app. São as telas iniciais após o usuário baixar o aplicativo.
Página principal. Atalhos para ver faturas, transferir saldos entre benefícios e cartões de cada benefício.
Página de promoções: selecionando uma categoria, filtrando por preço ou desconto e conseguindo o cupom de desconto do prato de um restaurante.
Página de promoções: escolhendo os itens que possuem maior desconto. Não há filtro de categoria.
Página de cartões: todos os benefícios e faturas mensais.
Página cartões: realizando transferência de saldos entre benefícios.
Fluxo do usuário ao pagar uma conta com seu saldo livre. É possível realizar a operação utilizando um QR Code ou código de barras.
Área do perfil. O usuário consegue alterar seus dados pessoais, alterar e consultar senhas e tem acesso ao FAQ e ao suporte via chat.

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
Color scheme (dir.) e Grid e espaçamento entre bordas (esq.)
Iconografia (esq.), tipografia (centro) e espaçamento entre textos (esq.)
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

--

--

Gabriel Mesquita
Gabriel Mesquita

Written by Gabriel Mesquita

Product designer, engenheiro e faixa preta de judô. Escrevo para aprender e compartilhar conhecimento. https://gabrielmesquita.framer.website/

No responses yet