Simulando um cenário real de trabalho por parte de um UX Designer e sua equipe
Escrito por: Gabriel Belisiario
April 20, 2022
A elaboração de um estudo de caso real na área de UX muitas vezes pode ser complicada, pois dentro de uma organização, as informações acerca do produto ou serviço devem ser preservadas. Logo, minúcias sobre o contexto, informações sobre o produto ou o porquê de determinada escolha ter sido feita podem ser perdidas quando tentamos exemplificar o processo, principalmente quando se trata de um time, no qual muitas decisões são feitas por meio de diálogo e muitas iterações entre os membros.
Por isso, exemplificarei como um processo de melhoria a partir de um comentário de uma pessoa na loja de aplicativos poderia ser realizado em um contexto real. Observa-se, no entanto, que a estrutura aqui descrita não deve servir como base para futuros projetos, visto que o processo utilizado pode variar muito.
* Comentário #1 — Confirmação para efetuar ligação
* Comentário #2 — Editar uma Mensagem Enviada
O aplicativo é muito bom e o brasileiro não vive sem. Mas gostaria de fazer uma sugestão que pode fazer diferença. Seria uma confirmação do usuário, quando fosse fazer ligação pelo app. Às vezes clicamos sem querer nos ícones de ligação de áudio ou vídeo e fazemos ligações indesejadas. Espero que essa funcionalidade seja possível de ser implementada. Obrigada 🤗
Utilizando como base o comentário da Pessoa 1, é possível, em um primeiro momento caracterizar o comentário para que o product owner ou o profissional responsável pelo produto na empresa possa priorizá-lo de acordo com o roadmap ou backlog em sprints subsequentes, caso se trate de uma equipe adepta de metodologias ágeis, por exemplo. Por ser tratar de um contexto de alta volatilidade, este geralmente é o cenário em times de tecnologia.
Assim, a caracterização poderá variar de empresa para empresa e de time para time, mas um exemplo seria rotular o comentário da pessoa com base em categorias. Exemplo:
Adicionalmente, diferentes níveis de classificação poderiam ser incluídos, como por exemplo:
Como resultado, teríamos um comentário devidamente categorizado:
“Comentário Pessoa 1”
Agora com o comentário devidamente caracterizado, ele poderia ser enviado para o gestor. Assim, ele fará o melhor julgamento acerca do quão essencial esse comentário é em relação ao produto de uma maneira geral e quando a equipe focará seus esforços em sua correção.
Após a caracterização do comentário e o envio para o gestor, começaremos o trabalho de correção. Neste caso específico, a Pessoa 1 se sente frustrada pela falta de um recurso específico no aplicativo. Assim, a equipe poderia elaborar um storyboard para representar essa frustração e como seria o cenário ideal:
Com base no cenário desejado, o time pode começar uma sessão de pesquisa, empatia ou brainstorm com o objetivo explorar o problema e, posteriormente, gerar ideias para atingir o objetivo proposto. Muitas técnicas podem ser utilizadas, tais como:
Por se tratar de uma funcionalidade simples, técnicas mais elaboradas não se fazem necessárias neste caso específico, pois a sugestão relatada pela Pessoa 1 se trata de um problema resultado de uma das 10 Heurísticas de Nielsen não ser respeitada: “Prevenção de erros”. Assim, a solução já fica evidente: Um modal de confirmação.
No entanto, caso a solução não esteja clara, outras técnicas podem ser utilizadas para a devida compreensão, tais como Benchmarking, Pesquisa de Profundidade ou Teste de Usabilidade, por exemplo.
Após o time entrar em acordo e ter escolhido a suposta melhor solução para o problema, os esboços iniciais podem ser elaborados. A depender da complexidade da funcionalidade, ciclo do produto, tempo e orçamento do time, diferentes níveis de prototipação serão feitos. Ou seja, protótipo em baixa, média ou alta fidelidade.
Exemplo de Interface de Usuário (User Interface, ou UI) exibida após o clique em ligar:
Apesar de ser uma solução simples, por meio do teste do protótipo com os usuários reais inúmeros questionamentos e insights podem surgir, tais como:
Com isso, é possível desenvolver variações do design proposto. Considerando os questionamentos e ideias levantadas na seção de teste com usuários, poderíamos elaborar as seguintes opções:
Perceba que apenas com a adição do botão de fechar, o padding interno teve de ser expandido. Ou seja, enquanto o padding do primeiro modal é de 24dp, o segundo resultou em 48dp.
O motivo da expansão considerável entre o padding do design 1 e o design 2 é que, apesar do símbolo “X”, possuir apenas 30dp, o tamanho mínimo da área de toque recomendado pelo Google é de 48dp.
Por isso, modificações mínimas de design podem impactar na usabilidade do produto final. Contudo, por se tratar de uma alteração mínima de UI, o teste de usabilidade pode resultar em uma diferença entre as versões, mas não estatisticamente significante.
Exemplificando o resultado de um teste de usabilidade com 5 pessoas em cada uma das versões, poderíamos obter o seguinte resultado:
Na média, o design 1 obteve 2,4 segundos contra 3 segundos do design 2. Isso significa que o primeiro deve ser a versão final? Não.
Por conter uma amostra muito reduzida de pessoas, o resultado da análise estatística com intervalo de confiança de 90% resultou no seguinte gráfico:
Pelo intervalo de confiança sobrepor entre as duas versões, as duas médias não são consideradas significativamente diferentes, conforme o resultado do T-Test:
Agora, suponhamos que os mesmos resultados tenham sido obtidos, porém com uma amostra de 20 usuários? Para isso, apenas repeti os resultados do primeiro teste mais três vezes para resultar em uma amostra de 20:
Refazendo o gráfico teríamos o seguinte resultado:
Perceba que com a amostra de 20 pessoas o intervalo de confiança de 90% sobrepõe bem menos entre o Design 1 e o Design 2 em relação ao teste com 5 pessoas. Ainda assim, por haver uma pequena sobreposição entre as versões, realizando o T-Test será possível confirmar que há uma diferença estatística significante:
Por escolhermos o intervalo de confiança de 90% e o T-Test ter resultado em 0,09 (9%) isso significa que há uma diferença estatística significativa entre o Design 1 e o Design 2.
Por se tratar de uma diferença sútil entre as variações propostas, muitas vezes a validação poderia necessitar de uma amostra muito maior. Ou seja, muitas vezes maior que 100. Logo, o Teste de Usabilidade Moderado fica inviável. Outros métodos, tais como o Teste A/B ou um Teste de Usabilidade Não Moderado podem ser utilizados para a comprovação da diferença entre as versões.
Gostaria de recomendar os seguintes livros que podem ser utilizados para compreender e aplicar os termos técnicos de estatística mencionados acima:
- Measuring the User Experience: por se tratar de um livro especificamente de UX, todos os conceitos exemplificados são de fácil entendimento e aplicação.
- Manual de Análise de Dados: livro do meu professor no MBA em Digital Business pela USP/Esalq, Luiz Paulo Fávero, junto da Patrícia Belfiore. Se trata da principal referência para análise de dados no mercado.
Após a devida validação do Design proposto, o UX Designer poderá fazer o handoff para o time de tecnologia, ou seja, a especificação dos componentes para que o desenvolvimento possa ser iniciado.
Geralmente, os aplicativos contam com uma biblioteca própria de componentes chamado Design System. Assim, o UX Designer ou o responsável pela documentação do produto pode atualizar a versão do Design System já com os novos componentes elaborados, facilitando o desenvolvimento por parte da equipe de desenvolvimento.
Muitas plataformas podem ser utilizadas neste processo, tais como InVision, Zeplin, Sketch, Adobe XD e Figma. Sendo esta última, a mais popular atualmente.
Seja no desenvolvimento ou quando a funcionalidade já está implementada no aplicativo, deve-se acompanhar a nova feature. Para isso, podemos contar com o feedback dos usuários, a análise de métricas e, se necessário, novos testes de usabilidade ou testes a/b.
O ciclo iterativo de design proporciona a melhor experiência para o usuário, visto que de acordo com a demanda e o feedback da comunidade, funcionalidades e serviços podem ser adicionados, modificados ou excluídos.
Por isso, deve-se levar sempre colocar a pessoa usuário como centro das decisões e utilizar de dados para o devido embasamento das decisões tomadas durante o processo de design.
Finalmente, com o feedback da Pessoa 1 foi possível ter ciência do problema, estudar possíveis soluções, testar com usuários, e implementar a mudança no aplicativo.
[…] Falta muita coisa óbvia como: -editar o que escreveu errado sem querer. […]
Observação: os demais problemas citados pela Pessoa 2 requerem uma pesquisa mais aprofundada por parte do time de tecnologia do WhatsApp e por conta disso apenas a funcionalidade sugerida de editar o comentário será o objeto de estudo.
Irei pular as partes mais importantes em um ciclo de design, que se trata da pesquisa inicial, exploração do problema, caracterização do problema, geração de ideias, prototipação, e testes com usuários, visto que no Comentário #1 foi simulado um processo que poderia ocorrer em um contexto real de trabalho.
Apesar de cada funcionalidade possuir suas peculiaridades, o que impacta diretamente as ferramentas e métodos utilizados no ciclo de design, achei melhor já propor a funcionalidade sugerida pelo Comentário #2 para o artigo não ficar muito extenso.
Assim, caso queira se aprofundar no processo inicial de correção de uma funcionalidade, leia o Comentário#1 — Confirmação para efetuar ligação.
Utilizando como base o livro “Think Like a UX Researcher”, que estrutura uma User Story (Histórias do Usuário) da seguinte maneira:
“Como um usuário, eu quero _____ para que eu possa _____”
I
rei utilizá-lo como embasamento teórico para a adição da funcionalidade. Logo, o resultado poderia ser, como exemplo:
“Como um usuário, eu quero poder editar uma mensagem enviada para que eu possa ser mais eficiente na troca de mensagens”
Observe o erro cometido pela Pessoa 2 às 19:59 ao esquecer de colocar uma vírgula em sua frase, conforme Imagem 1:
As únicas opções disponíveis para a Pessoa 2 seriam:
**[…] Enfim, vou ali comer, gente […]
Ambas as opções prejudicam a eficiência da Pessoa 2 em sua utilização do aplicativo.
No entanto, com a nova funcionalidade, será possível clicar na mensagem que a Pessoa 2 deseja editar e um menu flutuante aparecerá com a opção de edição, conforme Imagem 2:
Após clicar em editar, a Pessoa 2 entrará no “Modo de edição” e um tooltip de aviso aparecerá por ser a primeira utilização da funcionalidade, conforme Imagem 3. O tooltip exibe a seguinte frase:
“Atenção: Sua mensagem aparecerá como “editada” e o histórico ficará disponível.”
Estando ciente e após clicar em “Ok” para fechar o tooltip, a Pessoa 2 editará a mensagem da maneira desejada, conforme Imagem 4:
Após a edição e a confirmação das alterações, a Pessoa 2 sairá do “Modo de edição” e sua mensagem já estará disponível, conforme Imagem 5.
Adicionalmente, caso a Pessoa 2 ou os usuários do grupo queiram ver a mensagem original, será possível clicar em “Editada em”. Assim, a mensagem original e com o horário de envio original ficará disponível e um fundo preto será adicionado para uma melhor visualização, conforme Imagens 6 e 7.
Após a visualização da mensagem original, basta a Pessoa 2 ou as pessoas do grupo clicarem tanto na imagem original quanto no fundo preto para voltarem ao chat, conforme imagem 5.
Conforme o desejo inicial da Pessoa 2 exemplificado pelo User Story:
Como um usuário, eu quero poder editar uma mensagem enviada para que eu possa ser mais eficiente na troca de mensagens.
Foi possível implementar uma nova funcionalidade ao aplicativo WhatsApp que proporcionará um aumento na eficiência de utilização, tanto para a pessoa remetente, que porventura possa enviar uma mensagem errada, quanto para a pessoa, ou pessoas, destinatárias da mensagem, visto que tanto a mensagem original quanto a mensagem editada ficarão disponível.
Obrigado pela leitura!
Sugestões, críticas ou elogios por favor entre em contato via e-mail, LinkedIn.
As ferramentas e metodologias mais adequadas de acordo com o contexto do projeto:
Aplicativo Educacional: Benchmarking Indireto
Estudo de caso sobre a utilização do Benchmarking Indireto em combinação com o Design Thinking para a implementação de uma funcionalidade.
Aplicativo Educacional (UI)
Estudo de caso sobre as mudanças implementadas na interface do usuário (UI) do aplicativo de uma empresa atuante na área da educação.
Estúdio de Tatuagem Dylest
Estudo de caso que aborda a contextualização, desk research, benchmarking, arquitetura de informação e o teste de usabilidade.
App de Delivery de Hortifruti
Uma rede de hortifruti gostaria de desenvolver um aplicativo. Acompanhe o processo inicial de pesquisa até a apresentação do conceito.
© 2023 Belisiario. All Rights Reserved.
Seções Externas
External Pages
Connect
