Apesar do nome pomposo e intimidador, uma análise heurística pode se comparar a “passar um pente fino” em uma aplicação (sistema, site, aplicativo etc.) e assegurar que o usuário consiga realizar o que ela se propõe a resolver.

“Heurística é um método ou processo criado com o objetivo de encontrar soluções para um problema” – Wikipédia

Apesar de as heurísticas propostas por Nilsen para sistemas digitais serem as mais conhecidas até hoje – provavelmente por terem sido as primeiras, criadas em 1990 – existem algumas criadas depois que são interessantes: em 2004, Peter Morville criou “UX HoneyComb”, que dizia que as aplicações deveriam ser “úteis, desejáveis, acessíveis, confiáveis, encontráveis, utilizáveis e valiosas”, e Lou Rosenfeld escreveu “IA Heuristics”. Em 2006, foi publicada a ISO 9241 “Ergonomics of Human System Interaction e, em 2011, Resminu e Rosati escreveram o livro “Pervasive IA Heuristics”.

Então uma Arquiteta de Informação, Abby Covert, resolveu juntar as melhores ideias dessas quatro abordagens – que totalizavam 50 heurísticas – e criou um conjunto de 9 heurísticas que podemos aplicar em nossos projetos. As nove heurísticas apontadas por Abby dizem que um projeto digital deve ser encontrável, acessível, claro, comunicativo, útil, confiável, controlável, valioso e “aprendível” – essas são as características que devemos sempre buscar para nossas aplicações.

Por que fazer uma análise heurística?

Muitos clientes, quando seus sistemas estão quase prontos ou até mesmo depois de lançados, procuram profissionais de UX para realizarem um Teste de Usabilidade. Esse tipo de teste é extremamente útil, porém mais interessante quando queremos saber como o usuário interage com o sistema, entender possíveis falhas ou gaps.

Um Teste de Usabilidade deve ser evitado enquanto o sistema contém erros conhecidos, pois corre-se o risco de gastar verba e energia e, no fim, ter um relatório com falhas já conhecidas que prenderam a atenção do usuário.

Costumo recomendar que seja feita uma análise heurística até mesmo antes de o projeto ir ao ar, pois isso garante que o sistema terá sua primeira apresentação ao mundo com uma chance muito maior de aceitação, pouca frustração com erros, bugs, falhas etc.

Além do mais, não são necessários softwares específicos, laboratórios ou câmeras para se fazer uma análise heurística – apenas um dispositivo onde sua aplicação rodará, papel e caneca são suficientes.

Como fazer uma análise heurística?

Nielsen recomenda que a análise seja feita por entre 3 e 5 avaliadores que estejam acostumados com os conceitos de usabilidade, mas pessoas previamente instruídas sobre os critérios de avaliação também podem ser avaliadoras.

Outra prática útil é o avaliador ter um observador por perto, assim como em um teste de usabilidade, podendo propor tarefas, anotar reações e até mesmo gravar ou transcrever o relato do avaliador, caso sejam necessários melhores registros. É importante que os avaliadores não tenham contato uns com os outros para não haver influência e, se preferirem, eles mesmos podem escrever um relatório da análise seguindo os critérios passados.

O avaliador pode explorar livremente o sistema e então relatar os problemas encontrados, preferencialmente relacionando-os com os critérios heurísticos e classificando-os de acordo com a gravidade – entre 0 (não é considerado um problema de usabilidade) e 4 (problema gravíssimo que não permite a finalização de uma tarefa).

Caso prático

Recentemente, trabalhei no projeto de uma universidade que, apesar de ter uma landing page, formulários validados e um ótimo design, não convertia em inscrições no vestibular. Olhando “por cima”, tudo parecia seguir o que mandam as boas práticas. Porém, ao analisar mais de perto, verifiquei diversos problemas que, como foi reportado posteriormente, quando agrupados em um único fluxo, deixava o processo de inscrição bem complicado de ser finalizado.

Como falei antes, eu tinha um objetivo claro ao analisar o site: entender por que as pessoas acessavam a página, mas não completavam o processo de inscrição no vestibular. Em uma primeira navegada, para me habituar com o site antes da análise profunda, já tive o primeiro e mais grave problema: no momento de gerar o boleto para pagamento da inscrição do vestibular, o site retornava apenas um erro com um código na tela! Nem um botão de voltar, nem um link para contatar algum atendente, nada – apenas um código ininteligível para a maioria dos usuários.

Depois dessa experiência, voltei ao ponto de partida, a landing page, e comecei a relatar os problemas no passo a passo da inscrição. A tabela criada nessa análise mais minuciosa foi de problemas menores, como textos desalinhados que dificultavam a interpretação, e de problemas mais graves, como um botão crucial para passar para um próximo passo da inscrição que não tinha “cara” de clicável – o cursor nem virava “mãozinha” para ajudar a entender que aquilo era um botão.

A aparição de um código quando deveria ser gerado um boleto para pagamento da inscrição do vestibular foi considerado um problema 4 – ele impedia totalmente o usuário de completar o objetivo a que o site se propunha. Já o problema do botão que não parecia um botão foi considerado de grau 3 – ele não impedia, mas dificultava bastante um usuário menos acostumado a interfaces de prosseguir no processo de inscrição. Os textos desalinhados não eram um problema de usabilidade, então foram apenas sinalizados como possíveis pontos de confusão que poderiam ocorrer e foram considerados um problema de grau 0.

Contei com mais dois avaliadores nesse projeto que, apesar de terem relatado menos problemas que eu, até por não serem da área de usabilidade e sim trabalharem com tecnologia e terem sido previamente instruídos a como fazer a análise heurística, perceberam os mesmos pontos críticos no processo de inscrição e até outros que haviam passado despercebidos por mim (aí a necessidade de mais de um avaliador!), como duplicidade de informação em um menu dropdown e lentidão extrema ao selecionar alguns itens.

Resultados e correções

Depois de erros tabulados e organizados de acordo com a importância de sua correção, o responsável pela Análise Heurística propõe as melhorias e os ajustes necessários, então uma nova escala pode ser aplicada quanto à facilidade de correção – os pontos que devem ser atacados primeiro são os mais graves e de solução mais simples.

Por exemplo, para o erro da não geração do boleto, em um primeiro momento, sugeri que colocassem um telefone de contato da área responsável pelo vestibular para não “perder” esse usuário enquanto a análise e a correção não fossem solucionadas. Era uma solução paliativa, mas simples de ser aplicada e focada no objetivo da universidade.

Em relação ao botão que não parecia botão, a primeira coisa que sugeri foi fazer com que a “mãozinha” do mouse-over aparecesse, já que ela é considerada um padrão para links e botões e, depois, repensar o design do botão com um designer.

É importante verificar que o profissional de UX deve ter algum conhecimento de programação front-end e/ou ter um programador a quem recorrer para avaliar se as soluções propostas são as mais fáceis realmente ou se existem outras opções para serem consideradas.

Como vimos, é possível que uma Análise Heurística seja feita apenas introduzindo alguns conceitos de usabilidade e utilizando nossos próprios colegas para avaliações que podem apontar erros que, de outra maneira, poderiam passar despercebidos pelos atuantes do projeto.

E aí? Vai aplicar uma análise heurística no seu projeto?

***

Artigo publicado na Revista iMasters. Você pode assinar a Revista e receber as edições impressas em casa, saiba mais.