O Guru de usabilidade e autor de Usability Engineering, Jakob Nielsen, expõe sua preocupação de que os métodos ágeis são uma ameaça para as abordagens tradicionais para design e usabilidade. Ele diz que a maior ameaça do Agile para a usabilidade é que esté é um metodo proposto por programadores e cobre principalmente a parte de implementação do desenvolvimento dos sistemas. Alistair Cockburn acredita que esta reclamação não é verdadeira:
- Não importa quem propôs uma boa idéia, somente se a idéia é boa.
- Isto inicia uma divisão do tipo "nós contra eles" na comunidade ao invés de "nós mais eles" caminhando juntos.
- Diferente de outras ameaças que o Nielsen identifica, ele não oferece uma solução, então ele nos deixa com este problema não resolvido de "nós contra eles", o que é inaceitável.
Solução proposta: Use apenas boas idéias - não se preocupe com de onde a idéia veio. Como Kurt Morris postou na lista agile usability, “É inacreditável o que se pode conseguir uma vez que você deixe para trás a mentalidade "nós vs eles".”
Nielsen avança disparando o problema que o hábito ágil de quebrar as estórias em pequenas tarefas ameaça encobrir a experiência total do usuário, permitindo que funcionalidades sejam desenvolvidas de forma inconsistente. Pior que isso, ele diz: "a interface do usuário pode acabar parecendo um monte de remendos". A solução de Nielsen:
- Executar testes de usabilidade rapidamente e repetitivamente. Ele diz “Testes semanais são completamente factíveis e á a você uma certeza de integrar vários feedbacks dentro de um sprint.”
- Fluxos de trabalho paralelos permitem que o trabalho de usabilidade possam ser feitos um passo a frente do trabalho de desenvolvimento.
- Uso de protótipos de baixa fidelidade (como papel) que não requer código, minimizando o tempo gasto antecipadamente.
Jeff Patton destilou 12 boas praticas de usabilidade (ecoando muitas do Nielsen):
- Drive: praticantes de UX fazem parte do time do cliente ou product owner.
- Pesquisa, modelo, e design antecipado - mas apenas o mínimo necessário
- Comunique seu trabalho de design
- Use um fluxo de desenvolvimento paralelo avançado e acompanhe o avanço
- Ganhe tempo de design com estórias complexas de engenharia
- Cultive um grupo de usuários para validação que você possa usar para validação contínua
- Agende continuamente, pesquisas com usuários em um flxuo separado do desenvolvimento
- Aproveite o tempo do usuário para diversas atividades
- Use RITE para iterar com a UI antes do desenvolvimento
- Faça protótipos de baixa fidelidade
- Trate os protótipos como especificação
- Torne-se um facilitador de design
O método RITE (pdf) que o Jeff descreve vem do estúdio de jogos da Microsoft: "O RITE se diferencia dos testes de usabilidade “tradicionais” por enfatizar mudanças extremamente rápidas e verificação efetiva destas mudanças." Especificamente, os praticantes fazem alterações na UI (protótipo ou aplicação) assim que o problema é encontrado e a solução é apontada. Alterações como renomear botões, alterar o texto de itens de menu freqüentemente acontecem antes de outro participante chegar. Mudanças mais complicadas, porém obvias são feitas tão rápido quanto possível. Desta maneira a mudança pode ser testada rapidamente.
Além disso, Jeff percebe que seu papel mudou: “Como eu comecei a trabalhar com times ágeis, minha abordagem mudou em favor do design colaborativo. Cada vez mais eu me encontro atuando como um facilitador para coletar e modelar informação de grandes grupos de pessoas. Eu me vejo trabalhando com grupos de usuários e desenvolvedores para escrever cenários e esboçar o design da interface de usuário.”
Finalmente, Alistair disse (em relação à divisão de desenvolvimento/usabilidade): "Apenas se lembre, há apenas nós"