Product design & bug bash: como validar interfaces e garantir a qualidade da sua entrega de ponta a ponta

Gif de uma ilustração de insetos andando sobre um chão cor de rosa. Fonte: Giphy

Uma grande dificuldade enfrentada por nós, designers de produto, é o famoso handoff para os desenvolvedores. Handoff pode ser traduzido como “entrega” e é aquele momento em que passamos nossas telas, fluxos e ideias para os desenvolvedores. Existem vários passos que não podem ser esquecidos, como; exportar os assets direitinho, fazer um guia de estilo, documentar, respeitar o grid, o design system etc. Mas, para garantir a qualidade do que está realmente chegando até nossos usuários, nossa entrega não pode parar por aí. Mesmo estando em fase de desenvolvimento, existem outras etapas e rituais onde o designer pode (e deve!) acompanhar e contribuir na implementação da solução. Uma delas é o bug bash.

Mas que raios é bug bash?

Bug bash é um processo muito utilizados pelos guardiões da qualidade, os famosos Quality Analysts (ou QAs, para os íntimos). Eles geralmente reúnem pessoas para colocar a mão na massa e testar o produto ou funcionalidade que o time está lançando. É uma metodologia que visa encontrar os bugs antes mesmo de subir para produção e expõe o produto à testes não previstos.

Bug Bash é uma metodologia de testes que pretende encontrar a maior quantidade de bugs [erros e inconsistências] na menor quantidade de tempo, envolvendo pessoas de diferentes áreas do produto.

Se quiser saber mais sobre o passo a passo tem um texto super legal aqui.

A guide to starting bug bashing now

Mas o que eu, designer, tenho a ver com isso? Muito!

Quem nunca reclamou que as coisas subiram diferentes do que estão no protótipo? Que designer nunca achou um comportamento diferente do esperado em um fluxo milimetricamente pensado? Vários! Agora eu vou te contar um caso rápido de como o meu envolvimento acidental em um bug bash ajudou a estruturar um processo bem legal e ainda envolveu todo o squad.

O time era novo e era nossa primeira entrega: uma plataforma de cadastro de leads. Tinha fluxos, telas, ilustração e, claro…prazo apertadíssimo. Estava tudo pronto e queríamos o produto no ar logo, mas não podíamos lançar sem antes testar e, como o tempo estava curto, a QA do time envolveu todo mundo no processo de caça aos bugs. Mas antes, a gente precisava estruturar um lugar para reportar todos os bugs rapidamente, com descrição e detalhes, para não ter que ficar passando post-it a limpo depois. A gente também precisava saber em qual dispositivo a pessoa estava testando, qual navegador, qual versão e, o mais difícil, a gente precisava explicar o que cada pessoa do time deveria testar e porque.

Foi nesse momento que o pensamento necessário do designer de solucionar problemas aflorou

Como consolidar tudo isso em uma coisa só? E foi assim que começamos, mapeamos todas as necessidades dos testes, demos print em todas as telas e colocamos em uma planilha um tanto quanto bagunçada. Foi aí que me veio aquela famosa frase “dá pra deixar organizado e bonitinho?”. Claro que dá! Afinal, isso a gente também faz.

Gif de uma ilustração uma mão cor de rosa abrindo com vários insetos. Fonte: Giphy

Comecei a estruturar a planilha para que qualquer pessoa conseguisse reportar um bug facilmente, tela por tela. Ficou fácil, o tester (a pessoa que estava testando) achava o bug e colocava logo ao lado do print da tela, com descrição e a devida prioridade, aquele bom e velho MVP. E nosso primeiro bug bash foi um sucesso.

Gif mostrando uma interação na planilha criada para o bug bash. Temos três páginas na planilha, e as interações mostradas estão na primeira delas: Participantes. Seis colunas estão nessa página: “ quem está testando” , “contato com o produto”, usuário simulado, “tipo do dispositivo” , “marca do dispositivo” e “navegador”

Encontramos 40 bugs em uma hora!

Mas ainda não era o suficiente. Tinha todo o trabalho de reporte, colocar no Jira com descrição, prioridade e outras coisas. Resolvemos fazer uma segunda versão. Agora, cada tester informaria o dispositivo, o navegador e o fluxo que estava testando. E, quando o processo terminasse, todos os bugs eram reportados automaticamente [via script] para o JIRA, já priorizados com descrição e detalhes. A parte do script eu tive que pedir ajuda aos universitários e foi um sucesso maior ainda.

O que antes se gastava horas para testar, reportar, priorizar, foi substituído por apenas uma hora de trabalho

Foto de pessoas participando de um bug bash com a planilha nos computadores e o layout nos celulares.

O melhor disso tudo foi acrescentar a categoria de melhorias. E era aí que eu entrava. Com o InVision aberto do lado, eu não estava focada apenas em encontrar bugs, mas sim em achar inconsistências com o layout e com a experiência. Foi assim que comecei a validar a interface e garantir que a qualidade não ficava em segundo plano, sempre me colocando no lugar do usuário. E, para alegria de todos, os desenvolvedores também estavam envolvidos (inclusive os front-ends) e a gente discutia juntos se a melhoria era essencial para a entrega. Esse processo me ajudou muito a entender o que era “must have” e o que era um pouco de vaidade. Me ajudou também a defender melhor os meus pontos, já que estávamos com todo o time reunido e o tempo era precioso.

Como o processo ficou mais rápido e automatizado, conseguimos separar mais tempo para focar em qualidade

E isso refletiu lá no início do processo. Sabendo que toda entrega vai passar por um novo bug bash, todo o time começa a se aplicar mais para evitar futuros erros. Quem diria que uma mera planilha organizada traria tantos resultados? E foi errando, aprendendo e fazendo mil versões de um Google Sheets que uma designer e uma QA conseguiram melhorar as entregas, tentando aplicar qualidade em todo o processo e, claro, envolvendo todo o time, pois a entrega é de todo mundo.