Avalados por :
Como integrar a experiência do usuário ágil em projetos de desenvolvimento: lições aprendidas e dicas práticas
- Creado 01/03/2024
- Modificado 01/03/2024
- 2 Vistas
0
Cargando...
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:
O assustador para o designer:
Mas no final: ótimo!
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
Pedro Pascal
Se unió el 07/03/2018
Facebook
Twitter
Pinterest
Telegram
Linkedin
Whatsapp
Sin respuestas
No hay respuestas para mostrar
Se el primero en responder
contacto@primeinstitute.com
(+51) 1641 9379
(+57) 1489 6964
© 2024 Copyright. Todos los derechos reservados.
Desarrollado por Prime Institute
Hola ¿Puedo ayudarte?