Antes de vir trabalhar na Concrete Solutions, me dedicava exclusivamente a um único produto. Nele, eu tive as mais diversas experiências, e decidi compartilhar algumas delas. Depois que vi os aprendizados do Victor Lima, pensei que se tem uma Lean Story que eu gostaria de participar, é a que vou descrever neste artigo.

Entrei nesse antigo time com a missão de entregar a melhor versão iOS e o mais rápido possível. Depois do setup inicial e do planejamento do app, tudo estava pronto para começar o desenvolvimento, e começamos a todo vapor. Era tanta excitação, que mal podíamos esperar para lançar o app, ter os pedidos via iPhone e ver os números subirem. O plano era simples: lançar a primeira versão bem mínima, basicamente uma máquina de criar pedidos; completamente linear, sem menu, perfil, push ou qualquer funcionalidade que não fosse essencial. Foram quase dois meses de trabalho intenso, até que depois de testes e mais testes, estava tudo pronto! Finalmente podíamos publicar na AppStore.

Nesse dia, estávamos na casa de um dos sócios e, completamente por acaso, uma festa de adolescentes estava acontecendo no prédio. Decidimos descer com o app até a festa para testar com os convidados, afinal normalmente eles são antenados e usam vários apps diferentes. Quem melhor do que eles para opinar? O que poderia ter de errado com o nosso aplicativo? Tenho orgulho de dizer: falhamos miseravelmente.

Criando o teste

A intenção era ter um aperitivo de como seria o app na mão das pessoas. Adolescentes não eram nosso maior público alvo, mas essa neutralidade e fácil ambientação nos daria um resultado bem próximo da realidade, além do que, ouvir o que eles teriam a dizer seria ótimo. Chamamos seis pessoas e, antes de começar, definimos as diretrizes do teste e um padrão bem consistente de “Guerrilla Usability”.

Definindo as regras

Explicamos o conceito do produto e a transparência do teste – Ganhamos a confiança dos usuários: eles se sentirem especiais torna a experiência ainda mais desejável.

Ambiente agradável – Fazer o teste parecer um desafio ou sufocar o usuário com perguntas geram ações tomadas de modo diferente, e não queríamos isso.

Pensamento em voz alta – Pedimos ao usuário que nos dissesse o que estava tentando fazer, qual era a dificuldade encontrada ou nos fizesse qualquer pergunta que viesse à cabeça (mas não responderíamos).

Não influenciar ou dar dicas – Resistimos à tentação. É incrivelmente difícil ver alguém ter dificuldades em algo que para nós é muito simples.

Tentamos lembrar: somos apenas espectadores – Não pisque! Tentamos ficar atentos a cada expressão facial, cada pergunta feita e cada toque na tela. A quantidade de aprendizado gerado foi enorme.

Feedback – No final, pedimos uma avaliação completa do processo e ficamos atento às dicas e anseios.

Documente o máximo possível – Se puder, é legal filmar os testes e anotar todas as informações que estiverem ao alcance. Analisar todos os elementos do usuário e testar com calma é o ponto-chave pra definir a próxima iteração.

Medindo o resultado

Depois de todos os testes feitos, documentados e filmados, era hora de acalmar os ânimos e avaliar com frieza os resultados. No nosso caso, foram muito surpreendentes e bem longe de bons.

Métricas de performance

Taxa de completude: Precisamos medir se os usuários completaram a tarefa e quantos deles conseguiram.

Tempo investido: Tão importante quanto completar a tarefa é saber quanto tempo em média isso custou. Menos tempo = mais eficiência.

Quantidade de páginas visitadas: Já sabemos se a tarefa foi completada e em quanto tempo. Saber quantos page views foram necessários dá ainda mais clareza aos resultados.

Erros: Quantos, quais e a qual a relevância dos erros que aconteceram com as ações dos usuários?

Avaliação final: Como foi a experiência em geral?

O teste funcionou muito bem, mesmo decidindo na hora as diretrizes e a forma de medir foram justas e deu tudo certo.

Todos os entrevistados que nos ajudaram completaram a tarefa e, como a aplicação estava pronta para ser publicada, não tivemos erros.
À primeira vista parece incrível, mas na verdade o resultado foi horrível!

Apesar de completarem a tarefa, os usuários demoraram muito mais do que gostaríamos e a quantidade de páginas visitadas foi enorme. Estava claro que tinha alguma coisa errada e percebemos assim que começamos os testes. Em certo ponto todos acabam travando e nos bombardeando com perguntas, enquanto para nós a resposta estava bem debaixo do nariz. Vendo de fora, os pontos em que quase todos travavam e as expressões que eles faziam denunciavam tudo.

O ponto em comum

Foi até engraçado ver os dedos inquietos e os olhares percorrendo a tela procurando por uma solução. Se tem um ponto em qualquer teste que não deixa dúvida é a dúvida em si.

Tente se acostumar, essa vai ser a expressão mais vista no decorrer dos testes – e é completamente normal. A frequência com que ela aparece indica quantas barreiras foram encontradas e o tempo de duração é diretamente proporcional à dificuldade. Tomamos isso como termômetro pra medir a eficiência do app desde então.

No meu caso era constante: os usuários ficavam confusos o tempo todo e demonstraram que os passos eram árduos até o fim da tarefa. O termômetro estava prestes a explodir.

Foi aí que decidimos adiar o lançamento, rever os vídeos, anotar cada funil e trabalhar mais. O resultado estava longe do esperado e percebemos que com ajustes pequenos teríamos um enorme ganho, removendo vários dos pontos de confusão.

Conclusão

A verdade é que demorar demais é o pior erro. Testes de usabilidade devem ser feitos desde o princípio da idealização do produto e podem ser tão simples quanto wireframes, web, só html/css ou apps sem ação nenhuma, direto do storyboard. Um protótipo após o outro.

Pecamos pelo excesso, tentamos facilitar ao máximo e para isso oferecemos features não validadas. Simplesmente acreditamos na feature e focamos tanto no lançamento, que nem passou pela nossa cabeça se o usuário as quer ou se faz sentido. Por fim, jogamos fora um monte de código que, feito do jeito certo, poupariam dias ou semanas de trabalho.

O lema é repetitivo, mas é válido a cada vez que se ouve: “Get out of the building”

Ficou com alguma dúvida, tem alguma contribuição sobre o assunto ou alguma crítica ao texto? Fique à vontade para deixar seu comentário abaixo.

Até a próxima!