Este artigo foi originalmente publicado em 2014 em experience.sap.com
Em
parte 1
deste artigo, resumi o pano de fundo e os conceitos básicos da experiência do usuário ágil (UX). Neste artigo de acompanhamento, gostaria de me afastar da teoria e contar mais sobre minhas experiências práticas e pessoais trabalhando com esses métodos.
Com o aumento das abordagens ágeis e lean em nossa indústria, os profissionais de UX estão mais propensos do que nunca a se encontrarem apoiando projetos ágeis. No entanto, muitos de nós parecem frustrados com o desafio de integrar efetivamente a UX dentro de um quadro de desenvolvimento ágil. Como aconteceu comigo.
As razões são multifacetadas, mas fáceis de rastrear: Enquanto as equipes de desenvolvimento recebiam treinamento em desenvolvimento de software lean e em engenharia de software ágil com métodos scrum, os designers de UX não eram vistos como parte integrante do processo de desenvolvimento de software. O pensamento "cascata" nas equipes de desenvolvimento ainda não foi completamente erradicado. Nesse pensamento, os designers de UX criam designs pixel-perfect no início de um projeto de desenvolvimento, os "lançam por cima do muro" para a equipe de desenvolvimento e depois passam para o próximo projeto.
No último time com o qual trabalhei, tentamos utilizar esses métodos em nosso time de produto e em nosso time de desenvolvimento. Isso é o que aconteceu.
Nosso primeiro passo foi formar um time de produto multidisciplinar. Na primeira fase do projeto, o time de produto teve 4 semanas para realizar atividades de pensamento de design e pesquisa de usuários, enquanto o time de desenvolvimento estava ocupado com a manutenção de sistemas existentes e avaliando tecnologias para nosso novo produto. Após essas 4 semanas, tínhamos um protótipo validado pelo usuário final e um produto mínimo viável (MVP) pronto para nosso primeiro lançamento do produto. Como na SAP utilizamos scrum como um quadro de desenvolvimento de software ágil iterativo e incremental, nosso time de desenvolvimento já estava familiarizado com esse método e o vinha usando há algum tempo. Portanto, começamos com uma duração de sprint de 4 semanas, que acabou não sendo suficiente para a forma como queríamos trabalhar. Então, reduzimos para 2 semanas. Seis semanas antes do primeiro lançamento, quando nosso time estava sob grande pressão de tempo e precisava trabalhar de forma muito eficiente, reduzimos a duração do sprint para 1 semana e ajustamos nossas reuniões de sprint em conformidade.
Durante o processo de desenvolvimento, eu me sentava ao lado dos desenvolvedores e os ajudava com as iterações de design no código em nível pixel-perfect. Também tinha discussões com o time de produto sobre como proceder nos futuros sprints e criava wireframes para os elementos que decidíamos. Então, estava ao mesmo tempo
com
o time de desenvolvimento e
à frente
deles.
Tivemos a sorte de ter a oportunidade de falar continuamente com nossos usuários finais todas as semanas durante todo o processo de desenvolvimento e sempre tivemos a oportunidade de incorporar imediatamente seus comentários e descobrir necessidades.
Trabalhei por mais de um ano com o time e achei muito inspirador e educativo.
Algumas coisas que aprendi:
Dificuldades
Mudanças culturais são difíceis de superar no início:
-
Designers de UX adorariam ter muito mais tempo para pesquisas detalhadas, iterações e testes de usabilidade
-
A gestão de produtos e o desenvolvimento estão acostumados a especificações, e alguns adorariam ter todas as telas pixel-perfect antecipadamente
-
Foi um desafio para todos quando os designers tinham que fazer trabalho just-in-time e trabalho para futuros sprints simultaneamente
O assustador para o designer:
-
Você não sabe o que terá no final
-
Pode não ser o que você se propôs a construir originalmente
-
Seus designs preciosos não estão gravados em pedra; podem ser revisados em um sprint posterior e talvez descartados completamente
-
Você deve aceitar que, embora seja o especialista em UX, não sabe tudo, terá que continuar aprendendo constantemente
Mas no final: ótimo!
-
Você constrói um produto com o efeito de "realmente quero isso"
-
Nosso sucesso compartilhado e os excelentes comentários de todas as partes interessadas e clientes foram uma ótima experiência