Recentemente li dois posts sobre como “encaixar” UX em times que estão usando metodologias ágeis. Um deles é o “Agile UX: Como trabalhar com os designers” do Guilherme Chapiewski que trabalha na Globo.com. O outro é o “Agile UX: como integrar UX e desenvolvimento” do Antonio Carlos Silveira do Yahoo! Brasil.

Como o próprio Antonio apontou bem, essa preocupação sobre como integrar UX em um time de desenvolvimento de software que segue alguma metodologia ágil existe desde o início das metodologias ágeis. Alguns posts sobre o tema:

• Agile Development Projects and Usability: Jakob Nielsen descreve maneiras de garantir que a qualidade da usabilidade não seja ameaçada pela adoção de metodologias ágeis.
• Agile / Scrum Product Development Process: Marty Cagan propõe uma forma de integrar UX e Scrum.
• Extreme Programming vs. Interaction Design: Entrevista com Kent Beck e Alan Cooper sobre design de interação e XP. Nessa entrevista, chamada por alguns de “duelo de titãs”, Beck defende o desenvolvimento do design de interação de forma incremental, enquanto Cooper defende que o desenvolvimento de software não deve começar antes de todo o trabalho de design de interação ser concluído.
• UX Agile: um blog totalmente dedicado à questão de integrar UX aos times de desenvolvimento que usam metodologias ágeis.

Aliás a busca por Agile UX no Google retorna muitas e muitas páginas dedicadas ao tema.

Um exemplo interessante é a apresentação abaixo, da Leisa Reichert que ela apresentou na Web 2.0 Expo Berlin:

Sem dúvida há várias maneiras de se integrar UX e metodologias ágeis e o correto é escolher a maneira que se adapta melhor à sua situação e disponibilidade de recursos (tempo, dinheiro e pessoas).

Contudo, queria adicionar meus 2 centavos a essa conversa. Apesar de ser importante termos especialistas em UX, pessoas que conheçam a fundo sobre arquitetura da informação, design de interação, design visual e todos os temas relacionados à experiência do usuário, acredito que UX deve ser uma preocupação de todas as pessoas do time. Não há razão alguma para o PO e os membros do time não se preocuparem com o tema e deixarem tudo nas mãos de um especialista. E se esse especialista um dia não estiver disponível? Se ele estiver ocupado cuidando de outras coisas? Ou mesmo se não tivermos um especialista em UX no time?

Não estou querendo dizer que UX não é um tema complexo, que requer muito estudo e prática, mas acredito que todos nós devemos conhecer os conceitos básicos de UX.

Vou citar duas situações exemplo que ilustram bem a importância de todo o time se preocupar com UX:

1. Feedback: imagine que você tem em sua aplicação uma determinada função que não é executada na hora e que pode levar até 2 horas para acontecer. Na interface você implementa o comendo que executa essa função só que não informa o prazo. O usuário certamente vai se perguntar o que aconteceu, se a função foi de fato executada. Um solução é avisá-lo desse prazo logo após o comando ser invocado. O ideal é avisar antes mesmo de ele invocar o comando que executa a função.
2. Opções: imagine que você está desenvolvendo um formulário de pagamento com opções de pagamento por cartão de crédito. Você recebe o protótipo com um select que permite escolher entre Amex, VISA e Mastercard. Você implementa esse protótipo. Na hora de colocar em produção você recebe a informação de que inicialmente o sistema só irá aceitar Mastercard. Você edita o select e remove as outras opções. A sua interface vai ficar com um select de uma opção só! O correto aqui seria remover o select enquanto houver uma opção só.

Ou seja, não é necessário ser um especialista em UX para ajudar no desenvolvimento e melhoria de UX dos sistemas que seu time cuida. Leia, estude, informe-se, afinal conhecimento nunca é em excesso!