E enfim, para quê que serve tudo isso?
Para quê que serve toda essa análise que a gente fez,
do que está acontecendo dentro do meu app, dentro da minha solução?
O mais importante, a ideia principal aqui é a gente identificar os problemas,
combinando esses vários dados, identificar problemas que o nosso design tenha e,
a partir daí, levantar hipóteses sobre o porquê desses problemas.
E eu posso dar alguns exemplos para vocês.
Por exemplo, a gente pode ter uma tela na qual o usuário demora muito mais tempo do
que nas outras.
Será que a gente carregou muitos elementos naquela tela?
Será que aquela tela está confusa, ele não consegue clicar?
Essas podem ser várias hipóteses.
Outro exemplo: funil de conversão pode ter muita perda na etapa do endereço.
Será que o nosso cadastro de endereço está complexo,
ele pode ser melhorado de alguma forma?
Será que o usuário não está conseguindo interagir com os campos do formulário?
E a partir daí você pode ir levantando essas várias hipóteses,
a partir dos problemas que você identificou para a partir
daí investigar as causas e criar um roadmap para a melhoria do seu design.
A gente na Taqtile costuma usar uma tabela parecida com essa que vocês estão vendo
agora, que é elencando as várias hipóteses de trabalho,
as várias hipóteses de áreas do app que você levantou e vários casos de estudo
para você analisar se essas hipóteses são verdadeiras ou não.
Alguns casos vão ser bem retos e diretos e você não vai precisar
investigar muito o porquê das coisas.
Por exemplo, pode ser que você descubra que há tamanho de tela que ninguém está
conseguindo fazer compra e pode ser que você nem tenha testado nesse tipo de tela,
porque ele é muito esquisito, é uma tela pouco usada e,
quando você testar o seu aplicativo naquela tela,
vai ficar óbvio ali que ali há um problema e que você precisa arrumar.
Alguns problemas vão ser auto evidentes como esse, mas há outros problemas que são
mais complexos e você não vai conseguir tão facilmente descobrir o porquê.
Então, existe uma série de outras análises que a gente consegue fazer com
outros tipos de ferramenta para ir atrás do porquê que certas coisas
estão acontecendo e aí a gente vai abordar aqui os testes de usabilidade,
os testes remotos, os session recordings e os testes A/B.
Para fazer esse tipo de análise, voltando também ao ponto de ferramentas,
a gente vai usar de novo o Hotjar como exemplo,
que tem um outro conjunto de ferramentas que a gente consegue usar e a gente vai olhar
também principalmente para uma plataforma que se chama Lookback,
que permite uma série de coisas legais termos de testes de usabilidade.
Essas duas ferramentas não são exaustivas.
Você pode olhar outras coisas como o Smartlook,
o Jaco e o Fullstory também te ajudar.
A questão dos testes de usabilidade, que seriam o nosso primeiro ponto,
eu não vou entrar grandes detalhes,
porque a gente já falou bastante disso outras aulas do curso.
Aqui basicamente a ideia mesmo é do que você fez lá no Design Sprint: você vai
convidar alguns usuários, vai dar algumas tarefas para eles e vai,
a partir dessas tarefas, tentar comprovar ou não as hipóteses que você levantou lá
sobre o que está acontecendo.
Uma variação bacana desse teste de usabilidade é o que a gente chama de teste
de guerrilha.
Se você precisar de velocidade no teste, você precisa resolver rápido
algum problema ou descobrir rápido a resposta para uma questão,
não necessariamente precisa fazer isso com laboratório ou no escritório,
convidar as pessoas, marcar uma agenda e tudo o mais.
Você pode ir nas lojas ou ir na rua e buscar os seus
usuários no que a gente chama de guerrilha.
Por exemplo, pode ser que o seu cliente tenha uma loja ou tenha
um espaço onde os usuários finais dele vão com frequência.
Você pode ir lá, levar o app instalado com as modificações que você quer testar e
com as hipóteses que você levantou e parar um usuário no meio da rua e pedir: cara,
dá uma olhada aqui para mim, executa essa tarefa e rapidamente você consegue
obter algumas respostas para as suas hipóteses.
Sempre não se esqueça de gravar o que você está fazendo com o usuário,
porque é legal você ter material, até fica bem profissional para você apresentar
para o seu cliente, se você tiver um cliente e estiver fazendo trabalho com terceiro.
A segunda possibilidade que a gente tem aqui são os testes de usabilidade remotos.
Podem existir casos que o seu usuário está muito longe.
Se você estiver desenvolvendo um produto que é mundial e você está com
um problema na Índia, por exemplo.
Pode ser muito difícil você conseguir viajar até a Índia para fazer
teste de usabilidade lá.
Então, você pode fazer alguns testes remotos e a ideia aqui é a mesma coisa só
que usando uma plataforma que permita que você dê tarefas e
cheque como o usuário está se comportando à distância.
O Lookback faz exatamente isso.
Aqui vocês podem olhar o que ele está fazendo.
Tem um exemplo aqui da Netflix, essa pessoa está sendo entrevistada e a gente
consegue acompanhar, tempo real, tudo o que está acontecendo,
o que ele está fazendo na tela, o que ele está falando, quais são as impressões.
Você consegue incluir todo o seu time na plataforma e fazer as anotações.
Então, você consegue executar todo o teste, que você faria num laboratório ou
num teste de guerrilha, à distância com gravação e tudo o mais.
São possibilidades bem interessantes.
Esse tipo de plataforma não costuma custar muito barato,
mas é uma possibilidade bem interessante para quando você não consegue
estar corpo a corpo com o seu cliente final.
O terceiro ponto são os session recordings.
Existem plataformas, o Hotjar é uma delas, que permitem que você faça gravações
dos usuários que estão de fato usando o seu aplicativo ou a sua solução web.
Esses usos são gravados com os usuários no site final
mesmo lá funcionando ou no aplicativo final funcionando que está na loja.
Ele é SDK, é um pedaço de software que é integrado na
sua solução e ele consegue fazer a gravação do que o usuário está fazendo.
Então, alguns segundos depois do usuário ter visitado o seu site
e feito uma série de coisas lá, você já tem disponível
vídeo onde você pode ir assistir: pode onde o mouse dele passou,
qual o scroll que ele fez, onde ele clicou, onde ele desistiu da solução.
E você pode usar isso, assistir esses vídeos como ferramenta para investigar
os problemas e as hipóteses que você identificou anteriormente.
Por fim, a quarta possibilidade é fazer testes A/B.
O conceito básico de teste A/B é você entender se duas versões diferentes de uma
funcionalidade ou de uma tela têm resultados diferentes
termos de analytics e de resultado do que você está esperando.
Eu não vou entrar em grandes detalhes sobre o teste A/B,
porque ele vai ser assunto da próxima aula.
É assunto bastante complexo, envolve algumas noções de estatística.
Então, a gente não vai entrar nele agora.
Uma vez que você tenha executado então todos os testes,
buscou descobrir os porquês dos problemas,
a gente normalmente volta para aquelas hipóteses que a gente tinha montado
e tenta montar uma matriz de resultado, ou seja, tentar validar quais
hipóteses a gente chegou à conclusão de que são válidas e que vale a pena mudar,
o que a gente descobriu que não é válido e não vale a pena mexer e coisas que são
inconclusivas, ou seja, que precisam de pouco mais de estudo.
A partir dessa matriz de deu certo, deu errado ou vale a pena mudar ou vale a pena
não mudar, você pode criar um roadmap, você pode criar conjunto de funcionalidades
novas que você pode usar para melhorar o seu design e continuar evoluindo ele,
assim como o Joomla, a gente falou que o Joomla é uma linguística com fluxo
infinito, ou seja, você vai melhorá-lo daqui para a frente.
Esse processo nunca vai acabar, porque novas versões de telas são lançadas,
novos sistemas operacionais, novos navegadores e o mercado muda,
os usuários finais mudam, novas gerações entram no jogo.
Então, o seu design nunca vai acabar e sempre vai ter que continuar evoluindo e
esse processo todo que a gente mostrou para vocês nessa aula,
você pode repeti-lo várias vezes em vários ciclos e assim obter
um roadmap para ir melhorando o seu design e o aperfeiçoando ao longo do tempo.
Eu acho que é isso.
Obrigado!
Vejo vocês na próxima aula.
