O melhor momento para se realizar o teste de usabilidade

Nas últimas semanas, estive envolvido na estruturação de uma proposta de metodologia de projetos para a empresa onde trabalho (razão do meu sumiço do blog). O objetivo era criar um passo a passo para desenvolvimento de novos projetos, desde a prospecção até a manutenção. Na etapa de prognóstico, surgiu uma dúvida: em que fase do desenvolvimento colocar o teste de usabilidade?

A metodologia previa que seria feito primeiro a divisão e classificação das seções, depois os wireframes e o storyboard, seguindo para aplicação do conceito visual (layout) e finalizando com a codificação HTML e CSS para posterior implementação da programação.

Em uma metodologia dessas, em que fase do desenvolvimento colocar o teste de usabilidade? As opções eram após a elaboração do protótipo em papel, após a elaboração do protótipo navegável (fase dos wireframes), após a finalização do HTML e CSS (teste com o layout aplicado) ou após a programação ter sido implementada. Testar com o projeto no ar não foi cogitado.

Sabemos que quanto antes um erro de usabilidade for detectado, melhor. É mais rápido (portanto, mais barato) modificar uma linha em um documento do Word do que alterar um HTML. Ocorre que realizar testes em fases muito primitivas do projeto - como o protótipo em papel, por exemplo - pode não trazer grandes benefícios.

Quando realizar o teste de usabilidade?

A conclusão que cheguei foi que o melhor é realizar o teste no protótipo navegável. Tenho usado para a elaboração de wireframes o Axure RP Pro, um software fantástico que simplifica bastante a criação e gera protótipos navegáveis em HTML. Claro que o código fica um lixo e não pode ser aproveitado para a versão final, mas o que interessa nessa fase é testar a navegação, a disposição dos elementos na tela, a facilidade de uso.

Tomei a decisão depois que refleti que, pelo menos onde trabalho, o que importa na verdade é a interface e a navegação. Com isso bem definido e amarrado, o layout é apenas a “casca” que dá um atrativo visual ao que está sendo feito. Fiz uma analogia com a separação entre informação (HTML) e formatação (CSS) tão essencial para se compreender a importância dos web standards.

A vantagem é que é muito mais rápido (e barato! notaram que me preocupo muito com custos?) mudar um wireframe - principalmente no Axure - do que modificar uma imagem no Photoshop e recodificar o acronym title=”Hyper Text Markup Language” lang=”en”>HTML ou CSS. A desvantagem é que depois que o layout for aplicado, pode surgir alguma outra falha em relação ao que foi pensado no planejamento. Além disso, os usuários recrutados para o teste têm que abstrair e entender que aquilo é somente o esqueleto do website ou sistema.

O ideal mesmo seriam duas rodadas de testes, ou até mesmo três caso se queira testar o site com a programação implantada. Infelizmente não há tempo nem dinheiro para o mundo das idéias, então sempre tentamos encontrar a solução mais adequada à realidade.