Testar novos recursos, ao que parece, é um processo muito criativo e interessante. Mas e se os erros nas interfaces forem repetidos de um recurso para outro, e a maior parte do tempo for gasto capturando pequenos problemas de interface?
Nos meus quatro anos no Badoo, dos mais de mil bugs que encontrei, aproximadamente 20% estavam relacionados à interface do usuário e ao UX. Um terço deles é insignificante na escala do produto, mas ainda assim exige recursos de processamento, porque afeta diretamente a lealdade do usuário. Esses erros podem ser detectados apenas manualmente. Além disso, eles geralmente são encontrados apenas em determinados dispositivos em determinadas condições.
É possível evitar esses bugs mesmo no estágio de criação de novas funcionalidades e evitar o processamento da interface após o teste? Minha resposta é sim!
Neste artigo, usando exemplos da minha experiência, mostrarei como tornar o processo de teste menos rotineiro e parar de iniciar os mesmos erros, mostrar os erros mais comuns no desenvolvimento de interfaces de aplicativos móveis na plataforma Android e explicar de onde eles vêm com mais frequência. O artigo foi escrito com base no meu relatório na conferência Heisenbug, o vídeo pode ser visto
aqui .
Ninguém gosta de pesquisar e, mais ainda, de corrigir esses erros de interface:
E como é desagradável para os usuários trabalharem com aplicativos cheios de pequenos problemas de interface aos quais os olhos se apegam! Geralmente, esses problemas são repetidos de um recurso para outro e são herdados com novos produtos junto com os componentes.
Nós do Badoo também enfrentamos essa situação. O processo de desenvolvimento foi projetado de maneira a evitar isso. No entanto, problemas de interface ainda ocorriam periodicamente.
Nossa idéia se torna um novo recurso, tendo passado por várias etapas. Além disso, um dos mais importantes na busca e prevenção de problemas de interface não é o teste no estágio de controle de qualidade, como pode parecer, mas uma revisão. Nesse estágio, o gerente de produto e o designer analisam um novo protótipo de um recurso ou de todo o aplicativo e avaliam se eles queriam obtê-lo e se gostam de tudo. Este é um dos métodos mais úteis que ajudam a encontrar problemas na interface. Não se esqueça de incluí-lo em seu trabalho: uma revisão economizará uma quantidade enorme de tempo para todos os participantes do processo.
No entanto, isso não é suficiente. Apesar do fato de termos uma revisão, cerca de 20% do tempo gasto na descrição de pequenos erros e inconvenientes na interface. Que tipo de problemas são esses?
As causas mais populares de erros de UI / UX
Depois de analisar os problemas que eu e a equipe de desenvolvimento do Android encontramos com mais frequência nos últimos quatro anos, consegui identificar quatro causas principais de sua ocorrência:
Vamos em ordem e começar com o problema mais popular.
1. Disposição esférica no vácuo
Mais da metade dos erros que descobrimos foram causados por uma situação em que o layout criado pelo designer não respondeu ao grande número de perguntas que o desenvolvedor tinha no processo de criação do protótipo.
Vejamos um exemplo da minha experiência. Na imagem à esquerda está o layout do designer, na imagem à direita está a primeira iteração do protótipo.
No protótipo, vemos dados muito “bonitos” e não está claro o que fazer se o contato do usuário no notebook tiver um nome longo ou nenhuma foto. A renderização de maquetes para todas as ocasiões é uma tarefa demorada: para concluir a imagem, você precisa discutir todos os gargalos, caso contrário, eles poderão surgir apenas na fase de teste.
2. Subestimar a importância do design
Em segundo lugar, há situações em que o desenvolvedor ignorou o design e fez algo à sua maneira, sem considerar o layout.
Outro exemplo da vida. A tarefa era atualizar a tela de entrada de aniversário do usuário. À esquerda está o design e à direita está o protótipo do desenvolvedor.
O componente de seleção de data já foi escrito para alguns outros recursos, e o desenvolvedor o utilizou, enquanto o designer desenhou especialmente um componente completamente novo para facilitar o registro do usuário no aplicativo, ou seja, inserir a data de nascimento.
3. Lacunas na documentação
Em terceiro lugar na popularidade, existem lacunas na documentação ou perguntas ao gerente de produto. Por exemplo, testei um recurso com dicas para novos usuários sobre a finalidade de diferentes elementos da interface. Na figura à esquerda está o layout da documentação e na figura à direita é o que aconteceu no caso de uma conexão à Internet desconectada.
No caso de uma falha na conexão, o chamado caso zero apareceu, ou seja, uma tela informando ao usuário que não há conexão. É frequentemente esquecido sobre ele e, nesse caso, uma dica continuou aparecendo, mas essa situação não foi refletida na documentação do novo recurso.
4. Recursos do sistema operacional e firmware Android
A causa mais rara (mas ao mesmo tempo regular) de erros nas interfaces são atualizações ou firmware do SO dos fabricantes.
Por exemplo, no Android 9, eu me tornei o personagem Ghost in the Shell, porque após o aparecimento da "franja", as fotos dos usuários começaram a ter algo parecido com isto:
E os problemas não estavam apenas no UX. Também encontramos um caso em que as notificações no aplicativo começaram a aparecer sob essa "margem" em alguns casos.
Quando erros de UX / UI são permitidos
Existem casos em que você não precisa se concentrar nesses pequenos erros de interface? Claro que sim: se você faz MVP, existe um produto minimamente viável e seu objetivo é descobrir se o usuário vai gostar da ideia como um todo.
Concordo, nesse caso, não faz sentido perder tempo eliminando os menores bugs: não se sabe se isso dará resultado. No entanto, ninguém pode garantir que o usuário não gostou do novo recurso precisamente porque ele foi criado com 80% e não com 100%. Nesse caso, a criticidade dos erros é determinada pelo gerente de produto. O principal é não esquecer todos esses pequenos problemas e eliminá-los no próximo estágio, quando já está claro que o usuário gostou do projeto e ele passou do MVP para o estágio de desenvolvimento posterior.
O que fazer com tudo isso?
Como se livrar das causas acima de erros de interface, quais métodos usar? Vamos examinar os métodos e truques básicos que usamos no Badoo. Vamos começar com o mais demorado.
1. Crie seu próprio sistema de design
No Badoo, criamos nosso sistema de design Cosmos único, que simplificou a interação de designers e desenvolvedores e acelerou significativamente o processo de desenvolvimento.
Em termos simples, o sistema de design fornece respostas a todas as perguntas sobre o que pode acontecer com um ou outro componente da interface: quais estados ela pode ter, como fica dependendo do tamanho do texto e assim por diante. Na figura acima, isso é mostrado como um exemplo do componente Button. Quando existe um sistema de design, você não precisa desenhar layouts detalhados para novos recursos para todas as ocasiões.
O desenvolvimento do sistema de design é a escolha de grandes corporações com muitos produtos e interfaces complexas em diferentes plataformas, por exemplo, o Google com seu Material Design. Você precisará gastar dinheiro no desenvolvimento de um sistema desse tipo, mas no futuro isso ajudará a evitar um grande número de problemas.
E se não houver tempo para desenvolver um sistema de design ou se você tiver um aplicativo pequeno que não exija o uso de métodos tão complexos? Você pode escrever pequenas bibliotecas com componentes ou documentação resumida, ou seja, descrever os princípios existentes na empresa em diretrizes ou ajuda interna simples.
Leia mais sobre o Cosmos
na série de artigos do meu colega Cristiano Rastrelli e os links no final do artigo.
2. Use ferramentas de teste visual
A popularidade das ferramentas de teste visual está crescendo apenas, assim como o número de
soluções no mercado. Você pode ouvir sobre o uso do teste VRT em nossa empresa
no relatório do meu colega Karl Crawford no CodeFest. No entanto, não paramos por aí, porque queríamos não apenas comparar imagens, mas também armazenar scripts do usuário. Então, seguimos em frente e criamos nossa ferramenta multiplataforma LiveShots.
O LiveShots pode fazer muito mais: permite comparar as interfaces de nossos aplicativos não apenas entre as versões, mas também entre as plataformas iOS e Android. Ele funciona com base em nossos autotestes e coleta scripts de usuário com suporte para vários idiomas, para que mesmo alterações mínimas na interface não passem despercebidas. Você pode aprender mais sobre o LiveShots
em um relatório da minha colega Sasha Bayandin.
3. Construa uma boa bancada de testes
Passamos para ferramentas e métodos mais facilmente implementados. Uma bancada de testes bem montada ajuda muito na solução dos problemas de fragmentação e recursos de firmware de vários fabricantes de dispositivos móveis. Quantos dispositivos móveis você acha que precisa para testar a qualidade e encontrar problemas relacionados à fragmentação? Para não gastar muito tempo testando em dispositivos diferentes e ao mesmo tempo encontrar os problemas mais comuns de seus usuários, cinco a seis dispositivos (por exemplo, na plataforma Android) são suficientes. Você pode ler mais sobre como escolher dispositivos para uma bancada de testes
no meu artigo sobre Habr .
4. Use ferramentas auxiliares
Existem muitos aplicativos auxiliares interessantes para testar e solucionar problemas em interfaces. Os desenvolvedores de sistemas operacionais adicionam essas ferramentas regularmente diretamente à seção de configurações do dispositivo (consulte Opções do desenvolvedor). Entre as mais úteis, na minha opinião, está a exibição de Mostrar cliques e Mostrar limites de layout.
Dos aplicativos, recomendo o
Assistente do
desenvolvedor , que, como o inspetor de layout portátil, mostra informações detalhadas sobre os elementos da interface, como tamanhos e cores da fonte, e as
ferramentas do Designer com a capacidade de capturar capturas de tela com informações detalhadas sobre o modelo do dispositivo, resolução da tela, para que seja conveniente aplicá-las ao relatórios de bugs ou até mesmo um local para armazenar.
5. Encontre-se com mais frequência
Parece um método óbvio. No entanto, o que falar em uma reunião? Sobre erros repetidos - porque indica que os participantes do processo têm opiniões diferentes sobre suas responsabilidades e tarefas. Cada problema que você encontrou várias vezes requer uma análise obrigatória com todos os funcionários envolvidos.
Na conferência em que fiz uma apresentação, me fizeram perguntas sobre o que fazer se ninguém quiser se responsabilizar por pequenos problemas de interface, ou seja, todos os participantes do processo apontam um para o outro: o testador diz que verificar a interface é uma tarefa designer, desenvolvedor - que o gerente de produto ficou satisfeito com tudo quando mostrou o protótipo e o designer não entende por que, afinal, o produto é tão diferente do layout que ele criou. A melhor solução é resolver todos os mal-entendidos, ou seja, reunir-se e trabalhar para melhorar o processo, discutir e esclarecer as áreas de responsabilidade de todos os participantes do desenvolvimento, e não perder tempo pegando os mesmos erros.
6. Alimentos para cães
Outro método simples que já se falou muito é sobre alimentos para cães, ou seja, usando seus próprios produtos dentro da empresa. Representantes de grandes empresas como o Facebook gostam de falar sobre isso: é claro que, quando 20.000 funcionários assistem a seus produtos, o exército de testadores não é realmente necessário. De fato, o mais importante é que o dogfood o ajuda a conhecer melhor seu próprio produto e a entender as necessidades do usuário. Portanto, não o subestime.
7. Escreva uma lista de verificação
Com base nos problemas analisados, compilei uma lista de verificação que o ajudará a analisar rapidamente um novo recurso ou um aplicativo totalmente novo e economizar tempo na recuperação de gargalos de memória em aplicativos móveis, ou seja, onde erros de interface e problemas de usabilidade são mais comuns. Esta lista de verificação será especialmente útil se você a suplementar com suas especificações, com base nos erros mais comuns encontrados no seu projeto. Vamos desmontar.
Haverá exemplos bastante simples da minha prática:
- verifique todos os textos;
Os nomes dos botões não devem ser muito longos. Esta regra é verdadeira para qualquer idioma.
- verifique se existem indicadores de progresso;
Até as diretrizes do Google dizem que, se uma tela carregar por mais de três segundos, você precisará notificar o usuário de que um download está ocorrendo, por exemplo, mostrando algum tipo de animação. Da mesma forma, com outros elementos "pesados" - vídeo e fotos.
- verifique o que é mostrado na ausência de dados (zero casos);
É importante que, na ausência de dados, por exemplo, para um novo usuário que não tenha mensagens recebidas, em vez de páginas em branco em branco, seja exibido algum texto explicando o que está acontecendo e como continuar trabalhando com o aplicativo.
- verifique os botões e seu status;
É importante que os botões respondam ao pressionamento e é claro por que eles estão inativos, se assim for.
- comparamos recuos e alinhamentos com o layout;
Este é um momento muito doloroso, pois é impossível prever todos os tipos de fragmentação, mas a bancada de testes ajudará muito nisso.
- verifique se há espaços reservados na ausência de imagens;
Novamente, não mostre ao usuário uma tela branca na ausência de imagens e informações, mas explique que a imagem ou seção está ausente.
- verifique a interação da funcionalidade antiga com a nova;
Aqui, tudo é semelhante ao exemplo, com dicas para o usuário que citei acima.
É imperativo informar o usuário sobre a desconexão, pois, neste caso, não basta mostrar o indicador de download.
- Verificamos como as novas interfaces se comportam em pequenos dispositivos;
Sem comentário, veja a foto.
- verifique se as imagens estão otimizadas para dispositivos pequenos;
Nem sempre há espaço suficiente na tela pequena; portanto, todo o layout pode ocorrer devido a imagens não otimizadas.
- verifique a interação com diferentes versões do sistema operacional;
Seria bom manter uma lista de problemas que surgiram no aplicativo após a atualização do sistema operacional, para não cometer os mesmos erros repetidamente devido a essas alterações.
- verifique a interação com diferentes versões de firmware;
Da mesma forma: seria bom manter uma lista de problemas que surgiram no aplicativo em diferentes dispositivos e verificar como um novo recurso se comporta em condições semelhantes.
- verifique a animação (especialmente em dispositivos pequenos e fracos);
É melhor abandonar a animação e substituí-la por uma imagem estática para dispositivos fracos com uma resolução de tela pequena.
Portanto, sua lista de verificação pode ficar assim:
Em que momento você usa essa lista de verificação e quando é a maneira mais fácil de evitar bugs? Quando um recurso chega ao estágio de desenvolvimento e as primeiras perguntas aparecem, porque é tarde demais para fazer perguntas no estágio de teste.
Seria bom manter essa lista de verificação em mente no estágio de desenvolvimento - ajudará os desenvolvedores a levar em consideração todas as sutilezas ao projetar uma interface de aplicativo móvel, além de economizar tempo dos testadores no estágio de controle de qualidade.
Conclusões
Vamos resumir quais métodos podem ajudar a reduzir o número de problemas de interface em seus produtos:
- revisão de protótipo com gerente e designer de produto para cada novo recurso;
- o uso de listas de verificação detalhadas com base nos problemas mais populares relevantes para o seu produto, na fase de desenvolvimento ou até no design de novos recursos;
- análise e discussão das causas dos problemas freqüentemente encontrados ao projetar novos recursos;
- dogfood - o uso e bom conhecimento do seu produto;
- desenvolver seu próprio sistema de design ou criar um documento com diretrizes;
- implementação de ferramentas de teste visual.
Links úteis