Teste de usabilidade. O que é e como funciona?

 

Há algum tempo temos usado na Jera princípios e práticas de User eXperience. Uma delas é o teste de usabilidade que tem por objetivos observar o uso de um produto e investigar questões que envolvem navegação e entendimento da interface.

Mas o que é exatamente o Teste de Usabilidade?

O teste de usabilidade é um método de avaliação da compreensão de uso de uma plataforma pelo usuário real, mas sem a necessidade de um produto finalizado, geralmente é feita com protótipos mais simples e rápidos, que podem ser descartados com menos custo de desenvolvimento.

O teste mais comum é uma avaliação com 5 usuários, onde eles recebem uma série de tarefas para serem executadas. Por exemplo fazer cadastro, ou fazer uma compra online, qualquer coisa que sirva para validar as principais funções de um app. Ele é baseado nas teorias de Nielsen sobre usabilidade e testes com usuários. A amostragem de 5 pessoas tem uma porcentagem de credibilidade muito alta, e mesmo com 100 pessoas, o nível das respostas teria uma pequena variação.

Para que serve?

O teste serve primeiro para evitar retrabalho, já que um protótipo é facilmente ajustado, e um produto final tem mais trabalho e mais custo em alterações, mesmo que simples. Seus resultados são usados para correções que facilitem a navegação do usuário, projetar melhorias e funcionalidades futuras, ou até descartar funcionalidades que atrapalhem o uso.

Um teste de usabilidade ajuda a diminuir custos e focar esforços no que os usuários têm mais necessidade, com o foco no maior sucesso dos clientes e na interação deles com a plataforma.

Jornada do teste

O teste tem uma série de etapas para um resultado mais eficaz. Não necessariamente todas precisam ser feitas para um teste bem acabado, mas por padrão elas ajudam a ter respostas mais precisas. Vamos usar de exemplo um app para ver os horários e datas de jogos de futebol.

Personas

Antes de mais nada, as personas são levantadas no primeiro momento do projeto, antes de ter um layout pronto, e são uma representação do nosso público alvo. No nosso exemplo, seriam pessoas que acompanham constantemente jogos de futebol, torcem para algum time e sempre estão se programando para evitar passeios de família na hora do seu jogo favorito. Assim podemos entender quais são os problemas deles, e como o app vai interagir com esse mundo já estabelecido pelo usuário.

Planejamento

Já conhecendo nossos usuários, começamos a planejar o teste. Sobre como recrutamos essas pessoas, quais funcionalidades serão testadas, e entender o que agrega mais valor ao nosso usuário. Aqui definimos todos esses passos e montamos um roteiro para o momento dos testes e deixamos pronto o nosso guia para montar o layout dos testes.

Recrutamento

Depois de entender o nosso público geral, precisamos filtrar um pouco as pessoas para o teste. Quem seria melhor para a plataforma, um torcedor de algum time específico? Alguém que pratica o esporte regularmente mas não acompanha aos jogos se encaixa no nosso foco? Para entendermos se as pessoas atendem o nosso critério, montamos um questionário que ajuda a filtrar essas questões importantes para um público final mais alinhado às nossas expectativas.

Protótipo

Em seguida, vamos montar um app como um cenário de filme, parece de verdade, mas não é. O protótipo serve para analisar o fluxo dos usuários e como eles entendem as funções. Não necessariamente precisamos fazer ele salvar as informações que o usuário preencher no cadastro, ou mostrar uma lista completa com todos os times de futebol do mundo no filtro. Ele tem que dar uma sensação de que funciona, mesmo sem realmente ter uma programação por trás. E aqui fazemos todo o fluxo que foi planejado lá atrás para garantir que não seria esquecido algo importante.

Teste

Aqui iremos trazer nossos usuários para usar o protótipo, vamos ver como eles fazem essa navegação. Se eles ficam confusos em algum momento, ou fazem um fluxo diferente do esperado, e conversamos, para entender as dúvidas, as expectativas. E também como ele procura esses horários de jogos hoje, por algum portal de esportes, pesquisando na internet, pelo jornal, ou qualquer outra coisa que solucione isso. Guardamos então todas essas informações organizadas para entender onde houve problemas, possíveis funcionalidades para um futuro ou até mesmo coisas que precisam ser removidas.

Análise de dados

Por fim, após realizar os testes e anotar os resultados dos 5 usuários, vamos olhar os pontos de maior atenção. Assim podemos ver se em algum momento o fluxo está complexo demais ou não. Se a pessoa não conseguiu entender o filtro por times, se ela clicou no perfil achando que iria encontrar o calendário, ou qualquer outra coisa que precise de uma alteração.

Ações de melhoria

Depois de entender todos os pontos que não funcionaram como esperávamos, vamos propor as ações de melhoria. Por exemplo, como trocar os ícones de perfil, colocar textos explicando alguma tela, e deletar a tela de filtro por torneios que ninguém usou. Aqui podemos recomeçar o processo, e testar novamente com outras pessoas para entender se nossas soluções foram viáveis, ou deixar para a validação do produto final. O importante é que aqui vamos garantir que alguns erros críticos foram corrigidos antes de frustrar os usuários.

Conclusões finais

O teste é indicado para validar qualquer plataforma antes de um gasto de desenvolvimento alto. Testes ajudam a economizar esforço no desenvolvimento e dinheiro com a refatoração de algum fluxo. Protótipos são feitos pensando em ser descartados. Assim é o momento ideal para encontrarmos falhas críticas que possam atrapalhar usuários reais quando a plataforma estiver em ação.

Design além do visual: uma ferramenta para impulsionar seu negócio

Por ser uma área relativamente nova, em especial no campo da TI, o papel do design tende a ser mal interpretado por muitos. Ele acaba sendo associado principalmente às questões visuais. Embora muito importante, o visual é apenas parte das muitas áreas contidas nessa competência.

Gosto de pensar no design, como um todo e não só a parte visual, um diferencial do nosso trabalho e, em todas as fases se mostra muito presente: do entendimento à modelagem, passando pelas definições de negócio e validação até, finalmente, trabalharmos questões estéticas e de usabilidade.

Em vista disso, resolvi escrever este artigo para falar rapidamente sobre as competências do design que utilizamos e suas atribuições. Então tente pensar em design como uma ferramenta para resolução de problemas, ao invés de meramente arte.

“Qual é o problema que queremos resolver?”

Descoberta

Normalmente, quando recebemos novos projetos, o cliente nos apresenta uma solução para algum problemas existente no mercado que ele gostaria de transformar em aplicativo.  Um bom designer resiste à tentação de sair desenhando belas telas e já no início faz a pergunta mais importante de todo projeto: “Qual é o problema que queremos resolver?”.

Muitas vezes essa é a única pergunta que precisa ser feita para sabermos se aquele empreendimento é promissor ou não.  Se o cliente não consegue responder é sinal que a solução está comprometida, ou seja, tem grandes chances do negócio morrer no momento em que for lançado. Afinal, se ninguém compartilha de uma dor não há problema, e se não há problema, para que precisaríamos de uma solução?

Para responder a esta pergunta fundamental existem diversas metodologias, tais como UX (User Experience) research, Lean Startup Canvas e, a que utilizamos aqui na Jera, Lean Inception do Paulo Caroli, autor do livro Direto ao Ponto. Todas compartilham fundamentos comuns ao Design Thinking, que consistem em definir o problema, gerar empatia nos profissionais envolvidos no desenvolvimento do projeto, imaginar soluções para o problema, prototipar e validar a solução.

Do resultado final deste trabalho saem duas possíveis conclusões igualmente benéficas:

  1. Não existe problema e a ideia não deve seguir em frente;
  2. Existe problema real que as pessoas gostariam de ter resolvido, acompanhado de algumas possíveis soluções.

Em ambas situações todos saem ganhando. Pode-se evitar o investimento de tempo e dinheiro em um software que não gera valor e não tem clientela. Ou pode-se vislumbrar se a solução gerada trará retorno satisfatório e quais são os requisitos mínimos para possibilitar a operação da empreitada.

Assinatura

Se a ideia seguir em frente, passamos então para a etapa de branding. Nesta fase, nascem não apenas os logotipos, mas também a personalidade e a voz de uma empresa. O objetivo é entregar uma apresentação visual mais coerente do negócio que está surgindo.

Não que seja impossível desenhar uma bela logo sem um complexo estudo de mercado, muito pelo contrário. Mas designers experientes farão uma série de perguntas e estudos para construir um ícone que tenha tudo a ver com a imagem que a empresa deseja passar aos consumidores.

Na Jera, a maioria dos nossos projetos são de novos negócios. Por isso, formatamos um processo reduzido de branding para ajudar a ganhar tempo sem deixar a harmonia de lado.

No resultado final desse trabalho, entregamos o estudo da personalidade, aparência e voz da marca. Também é definido como ela se relaciona com o mercado, sem esquecer, obviamente, do logotipo.

Arquitetura

Considerando que as duas etapas anteriores estão bem resolvidas, é o momento de definir como funcionará cada tela do aplicativo. Nesta fase, nós iremos decidir como será o fluxo das telas do app e encaixar nele as funcionalidades estabelecidas anteriormente. Isso nos permite completar os objetivos definidos também na descoberta.

Nesse momento, nos preocupamos com os requisitos técnicos, hierarquia de informação, funcionalidades e a quantidade de passos do início ao fim da jornada do usuário. Buscando sempre a simplificação e o menor número de interações possível.

No fim, é entregue um wireframe de baixa fidelidade visual e um fluxograma, que mapeia todas as telas e requisitos do app. O material produzido já pode ser utilizado para testar as interações com o usuário final. Mas deve ser usado principalmente para colher feedbacks valiosíssimos que serão utilizados para melhorar o protótipo antes de passar à próxima fase. Além, é claro, de ser uma importante documentação ao longo do desenvolvimento da interface funcional.

Design de interface

Finalmente, esse é momento que todos esperavam no início! Agora a parte visual poderá ser trabalhada com a segurança de que o problema está resolvido, a identidade foi definida e os requisitos de sistema estão mapeados. Isso, é claro, pensando hipoteticamente, já que o produto ainda não foi testado em ambiente real de mercado para sabermos se a solução é a esperada pelos clientes.

Esse é um trabalho para o designer visual que, ao contrário das outras etapas, trabalha praticamente sozinho. Cabe a ele aplicar todos os conceitos de psicologia da forma, harmonização de cores e linguagem tipográfica para a consolidação de um sistema de design consistente. Esses são conceitos muito mais complexos e que não devem ser chamados de “arte”, uma vez que não são arbitrários, subjetivos ou ainda “feitos para chocar”. Embora existam inúmeros exemplos de interface que são de causar arrepios.

Enfim, teremos aqui um protótipo fiel do que será desenvolvido por nossos programadores.

Conclusão

screenshot-2018-02-22-at-17-57-36

São muitas as áreas dentro do design e não convém comentar todas para não nos estendermos no assunto. Entretanto, acredito que as mencionadas aqui compõem o mínimo que uma startup deve se preocupar ao lançar um novo produto, para ser o diferencial na vida de seus consumidores.

Acredito ainda no design como uma ferramenta essencial para potencializar o sucesso de um novo negócio, muito mais do que um mero apelo visual e sempre com aquela primeira pergunta em mente: Qual é o problema que queremos resolver?

Mas e você? Tem algum problema real que precisa ser resolvido? Conte-nos sua ideia e nós ajudaremos a descobrir uma solução. Clique aqui e faça um orçamento conosco! 

 

Texto: Ney Ricardo
Imagem: Dan Saffer’s diagram

Testes de software: como testar seu software corretamente

Existem diversos tipos de testes de software e eles são dividido em três principais categorias: Unitários, de integração e ponta a ponta.

Os testes, muitas vezes esquecidos ou até desprezados, fazem parte do desenvolvimento de todo software que se preze. Se uma falha acontecer na mão de um usuário, você não terá chance para se explicar. E assim, o negócio de alguém pode estar em risco por uma simples bobagem feita no código. Então, a melhor forma de garantir a qualidade do aplicativo que você está fazendo é testando ele.

Mas, afinal, de quem é a responsabilidade de testar a aplicação? É do desenvolvedor? Do analista de teste / tester (responsável por encontrar erros, falhas, bugs e outros tipos de problemas que não foram detectados durante o desenvolvimento de um software)? Do gerente de projeto / PO (profissional responsável por priorizar as atividades que maximizam o valor do produto e garantir o retorno do investimento)? A resposta é: todos. Sim, todos devem testar a aplicação, desde o início do desenvolvimento.

Para evitarmos futuras dores de cabeça e correções relâmpago, a equipe de desenvolvimento de software faz (ou pelo menos, deveria) testes em todas as aplicações produzidas. Testes de software são divididos primariamente em três categorias: unitários, de integração e ponta a ponta.

  • Testes unitários são feitos em partes isoladas do código, para cada componente. É como se testássemos cada “peça” de um aparelho antes de colocá-las. Vamos pensar que estamos montando um carro. Para garantir a segurança e evitar erros antes de unir todas as peças, é preciso testar cada uma delas separadamente. Por exemplo, para ter certeza que o veículo está funcionando normalmente antes de ir para o mercado, você tem que testar separadamente o freio, o volante, o câmbio, etc.
  • Testes de integração são testes unitários feitos em mais de uma parte do código. Eles juntam múltiplos componentes (normalmente 2) e verificam a comunicação e integração entre os mesmos. Este é o teste que garante que a ligação entre as peças está funcionando. Pense no caso do carro novamente: quando você utiliza o volante para dirigir-lo, a roda tem que responder ao pedido e mover o automóvel.
  • Testes de ponta a ponta são testes que validam todo tipo de comportamento possível dentro da aplicação, ou seja, simulam a atividade do usuário final. Se usarmos o exemplo do carro, esse tipo de teste seria dirigir o veículo após tudo estar finalizado, como se fosse o usuário normal. Garantindo assim que todas as peças do produto final e as comunicações entre elas estão funcionando corretamente.

Apenas os testes de ponta a ponta bastam?

Ora, mas se testes de ponta a ponta simulam um usuário real, então, em teoria, é a melhor escolha:

  1. O desenvolvedor fica feliz, afinal a responsabilidade de testar não é dele
  2. O analista de teste fica feliz, pois consegue testar simulando um usuário real, então seus testes de software são mais valiosos
  3. O gerente do projeto / PO fica feliz, pois isso vai garantir que o usuário final terá uma experiência melhor

MAS, infelizmente, não é bem assim que funciona. Se dependermos apenas de testes de ponta a ponta, o procedimento ficaria algo mais ou menos assim:

  1. O desenvolvedor faz uma feature/versão e passa para o tester do seu projeto
  2. Se o tester encontrar algum bug, ele cria um relatório do erro, e o desenvolvedor é notificado
  3. O desenvolvedor verifica o erro, checa o código, e corrige o bug
  4. Após toda a validação, uma versão de produção é lançada e enviada ao cliente

O que foi vantajoso nesse processo?

  • Erros que afetariam diretamente o usuário final foram detectados e corrigidos.

O que houve de errado nesse processo?

  • Os desenvolvedores tiveram que esperar o relatório de bugs para poder resolvê-los;
  • Bugs pequenos podem estar escondidos atrás de bugs maiores;
  • Encontrar a causa dos bugs pode levar um bom tempo.

Obtenha um procedimento mais efetivo

A melhor forma de conseguir sucesso durante o processo é utilizando testes unitários:

Testes unitários são testes de software feitos em partes isoladas do código, verificando métodos e funcionalidades específicas de um componente. Por estarem isolados, é muito mais fácil encontrar e corrigir erros. São testes rápidos e confiáveis.

O grande problema dos testes de software de ponta a ponta é a espera – você não sabe do erro até que ele ocorra na mão de um possível usuário, ou seja, quando já é tarde demais. Testes unitários conseguem ser precisos, ou seja, você sabe o que deu errado com mais precisão, sem esperar chegar ao usuário.

Apesar de todas essas vantagens, há uma coisa que o teste unitário não faz: simular um usuário real.

Evite possíveis bugs

A melhor maneira de nos prevenirmos contra bugs no desenvolvimento é utilizar cada teste corretamente e também usar o nosso tempo durante este processo de forma mais eficiente.

Por isso, utilizamos a pirâmide de testes de software proposta pela Google:

img_blog

 

A sugestão é que se faça uma divisão de 70/20/10, ou seja:

  • 70% de testes unitários;
  • 20% de testes de integração;
  • 10% de testes de ponta a ponta.

Isso serve para tentar sempre evitar uma pirâmide invertida (focada em testes de ponta a ponta), ou em formato de ampulheta (foco em testes unitários e ponta a ponta, mas nenhum em integração).

Texto: Leonardo Miyagi
Imagem: Rafaela Brum

*Este texto foi baseado em um artigo publicado pela própria Google, falando sobre testes de ponta a ponta (End-to-End Tests): https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html

Como entregamos um produto valioso utilizando as metodologias do Design Thinking — Capítulo 3

Nesta série dividida em três capítulos, nós, designers da Jera, relataremos nossa experiência com o projeto New App. Pelo qual utilizamos técnicas do Design Thinking e trabalhamos em conjunto com os desenvolvedores durante todo o processo de design.

No capítulo anterior relatamos como trabalhamos na resolução da falta de engajamento do cliente da Jera com a nossa ferramenta de gerenciamento. E o erro que cometemos que deixou nosso cliente insatisfeito.

Neste capítulo contaremos como trabalhamos para corrigir os nossos erros e qual foi resultado da segunda fase de testes. Relataremos também, nosso esforço para chegarmos a solução da falta de foco das equipes da Jera na Sprint 0 e Sprint Final.

Capítulo 1

Capítulo 2

Começamos tudo de novo

Após a “bronca” que levamos dos nossos clientes, vimos que a tentativa de solucionar vários problemas de uma só vez e em tão pouco tempo foi “um tiro no pé”. Assimilamos os erros cometidos e concluímos que era preciso reduzir funcionalidades, que menos era mais.

Com o foco centralizado no usuário, fizemos um Mapa de Empatia, entendendo melhor quem é o nosso cliente, o meio em que vive, suas expectativas, medos e o que ele realmente precisa. Assim, ficou mais simples entender o que realmente seria importante para ele. Decidimos então que funcionalidades deveríamos focar:

  • Acompanhar o andamento das Sprints do projeto;
  • Visualizar tarefas pendentes;
  • Acesso a documentos e protótipos;
  • Relatar problemas;

Com isso em mente, começamos os rabiscos de novo, pensando em facilitar qualquer atividade que o usuário precisaria fazer. O que antes era um tela cheia de informações que eram ignoradas, tornou-se uma tela com 4 botões simples, que levaria o usuário a um caminho mais claro antes dele concluir a tarefa desejada.

mockup_new_app
Tela principal do nosso segundo protótipo

 

Protótipo pronto, partimos para a segunda fase de testes.

Solução do problema de falta de foco

Antes de revelar como foram os testes. Contaremos como chegamos a solução da falta de foco das equipes da Jera na Sprint 0 e Sprint Final.

A Sprint 0 e Sprint Final é um período importante em que a equipe deve se concentrar. Porém poucos estavam realizando estas etapas efetivamente, por vários motivos, tais como: resolver problemas de outros projetos, distração com mídias sociais e auxílio a outros colegas quando estavam sem tempo (alguns tinham dificuldade em dizer “não”).

A solução encontrada foi identificar as equipes que estavam nestes períodos por meio de uma bandeirinha. Desta forma, quem estivesse com a bandeira teria um sinal que deveria focar no projeto em que está trabalhando e quem estivesse de fora não incomodaria o time com a identificação.

Além da sinalização da Sprint 0 e Final, sentimos a necessidade de incluir outra situação, quando a equipe está atropeladas de tarefas a serem realizadas no projeto e o tempo de entrega está quase no fim. Denominamos este caso de “Projeto Explodindo”.

O processo de produção das bandeiras foi o mais interessante, pois deixamos de criar soluções digitais para criar soluções físicas. Largamos o computador para fazer um trabalho artesanal que nos lembrou a época da escola. Recortamos papel, cortamos madeira, colamos papel e plástico, e nos divertimos muito com isso.

producao-das-bandeirinhas

Após terminar a produção, fizemos quatro bandeiras para sprint 0 e final com a cor amarela e três bandeiras para o caso de o projeto estar atrasado com a cor vermelha.

Hoje, as equipes estão utilizando as bandeiras e já tivemos bons feedbacks, muitos dizendo que as interrupções foram reduzidas e que a concentração para os projetos está sendo bem maior.

Segunda fase de testes

Ansiosos para saber como seria o resultado, colocamos o segundo protótipo para ser testado, desta vez, com pessoas que se encaixavam no perfil dos nossos clientes e com atividades mais focadas nas principais funções. Realizamos o mesmo procedimento do primeiro teste.

O resultado foi surpreendente, a diferença entre os dois testes foi “gritante”. Os usuários realizavam as tarefas rapidamente, um ou outro demoraram mais que um minuto. Um bom exemplo foi a função de visualizar as tarefas pendentes, em que a média caiu de 1min31s para apenas 17s.

Abaixo é possível visualizar a comparação da média de tempo na realização das tarefas entre o primeiro e o segundo teste:

media_testes_de_usuário
Média de tempo na realização das tarefas do primeiro e segundo protótipo

 

Mesmo com a melhora significativa, tivemos que corrigir alguns pequenos detalhes que trouxeram alguma dificuldade para os usuários.

Entrega da última sprint

Chegou a hora tão esperada. Ao mesmo tempo que estávamos confiantes pelos bons feedbacks, estávamos nervosos, porque sempre há alguma tensão quando nosso trabalho é avaliado.

Primeiro apresentamos as bandeirinhas, e tivemos uma boa resposta dos nossos clientes. Eles elogiaram a solução a que chegamos e a forma de como a executamos. Que dessa vez, deu pra ver que trabalhamos em equipe.

Depois apresentamos o aplicativo. Muita calma nessa hora. E…

O Jeff e o Ney gostaram também do resultado que apresentamos e ficaram surpreendidos com a diferença entre os dois testes. E deram sinal verde para que os desenvolvedores começassem o desenvolvimento do aplicativo. Este feedback nos deixou aliviados.

O que aprendemos

Ao utilizar metodologias do design thinking, ir a fundo no projeto, estudar e selecionar os reais problemas, propor soluções com uma base técnica bem definida, realizar testes e pesquisas com os usuários, ajudou-nos a fugir da subjetividade e tomar decisões com argumentos concretos, tendo a certeza de estar no caminho certo e entregar um produto valioso ao nosso cliente e ao usuário final dele.

A experiência de trabalhar em conjunto com os desenvolvedores trouxe-nos uma visão mais lógica na construção de um produto. Com a opinião técnica deles do que é possível ou não fazer, era fácil para nós, designers, desenharmos uma solução.

A redução de documentação também foi algo positivo, já que o desenvolvedor estava ao nosso lado e entendia o projeto todo, participando da criação, compreendendo tudo aquilo que foi feito e não simplesmente executando algo que caía em suas mãos.

O projeto New App foi um grande aprendizado para todos e levaremos este conhecimento para o restante das nossas carreiras.


É isso! Chegou ao fim nossa jornada.

Gostaríamos de receber seu feedback. O que achou do nosso processo? O que podemos melhorar? O que podemos acrescentar? O que podemos fazer de diferente?

Autores: Carol Cabral e Vinicius Rocha

como lançar um aplicativo de sucesso