Este é um artigo sobre UX em contexto de desenvolvimento ágil de software (Agile). Ao longo do texto serão utilizados alguns termos comuns.

O dia a dia de um user researcher varia, como em qualquer outra profissão, consoante o local/cliente em que está inserido. Para além disso, a execução das suas tarefas também está condicionada pelo tipo de projeto: os que têm uma data de início e de fim estipulada e aqueles que são de melhoria contínua.

O foco deste artigo é a visão de quem tem vindo a trabalhar, nos últimos anos, na área de UX research em contexto de desenvolvimento ágil de software.

O Desenvolvimento Ágil e o UX Research

As metodologias Agile foram desenvolvidas para tornar o processo de desenvolvimento de software menos burocrático e lento e, consequentemente, mais eficaz.

Entregar um serviço que cria valor para o cliente, num curto espaço de tempo, e que pode ser melhorado mais tarde de forma iterativa, pode ser tentador para a maioria das empresas.

Existe, no entanto, um senão. As equipas de desenvolvimento de software não trabalham sozinhas: precisam de researchers e de designers, cujo trabalho está, muitas vezes, dependente de inputs de áreas como Compliance e Segurança para o lançamento de uma simples funcionalidade.

Ou seja, o desenvolvimento ágil de software, da forma como foi concebido, não é muitas vezes ajustado ao tempo que os researchers e designers necessitam para realizar o seu trabalho com qualidade. Por isso, quando dizem que se pode pesquisar um tema ao mesmo tempo que este está a ser desenvolvido, num sprint de quinze dias, fico com a sensação clara de que os profissionais de UX ainda têm um grande trabalho de sensibilização pela frente.

Familiarização com a cultura de UX 

Imagem: https://www.springboard.com/blog/becoming-a-ux-researcher/

Quando falo em tempo, refiro-me também a toda a preparação necessária para criar um plano de research:

“User Researcher: Responsável principalmente pelas entrevistas a utilizadores, do tipo quantitativo (ex.: questionários online) ou qualitativo (ex.: testes com 5 ou mais utilizadores). Analisam os dados recolhidos e observados e disponibilizam os mesmos às equipas de produto e em alguns casos aos stakeholders. As suas atividades estão intimamente ligadas aos UX Designers que, por sua vez, também participam nas entrevistas, mas essas já previamente preparadas pelos Researchers (ligar, agendar, preparação de questionários, etc.)”
Eduardo Horvath, Head of Product & UX / Advisor / Blockchain Enthusiast

Implementar uma cultura de UX numa organização é muito difícil. A maior dificuldade é convencer os responsáveis e decisores, que procuram resultados rápidos, da necessidade de termos tempo para conseguirmos uma resposta clara às seguintes questões: quem são os nossos utilizadores/clientes; quais são as suas necessidades.

A culpa, como é claro, não é do desenvolvimento ágil de software. Se os researchers não derem visibilidade sobre em que consiste o seu trabalho e como dele se tira valor, é normal que os diferentes stakeholders não entendam que o tempo é extremamente valioso.

Sugiro alguns pontos a ter em consideração para dar visibilidade ao trabalho do researcher:

• ter o plano de research afixado para que a equipa de produto perceba o que vai ser estudado;
• mostrar os resultados a toda a organização e o tempo que cada iniciativa envolveu;
• enviar os relatórios do research para toda a equipa de produto e não só para os Product Owners;
• envolver elementos da equipa de desenvolvimento de software nas visitas aos clientes e nos testes de usabilidade;
• explicar o que fazemos quando algum elemento da equipa de produto não percebe bem a função do user researcher, porque se não percebe é porque não estamos a ter o impacto que é suposto.

Estas sugestões podem até parecer simples, mas no decorrer do dia a dia são facilmente esquecidas, principalmente quando trabalhamos para uma grande organização.

O Research está numa linha temporal diferente

Como os researchers precisam de tempo para processar a informação e de idear com os UX designers qual a melhor solução a apresentar ao cliente, os sprints de 15 dias estão dessincronizados quando executados em paralelo com os do desenvolvimento.

É habitual haver um sprint só de research, porque o nosso trabalho está sempre numa linha temporal diferente, ou seja, estamos sempre a trabalhar em temas que poderão ser desenvolvidos no futuro, enquanto que a equipa de desenvolvimento se foca no que é para lançar daí a um curto período de tempo.

Imagem: https://dscout.com/people-nerds/agile-qualitative-research-remote-tips

Como a imagem acima apresenta, o research pode ser realizado em sprints de 15 dias, mas temos de ter a noção de que este modelo mostra o cenário ideal, não o que acontece na maioria dos casos.

A fase de recrutamento de utilizadores é a que demora mais tempo e, para mim, é a mais difícil de enquadrar nos timings do desenvolvimento ágil. Encontrar pessoas com o perfil certo para que os resultados sejam relevantes é um desafio constante, principalmente porque, muitas vezes, acabamos por depender de empresas de recrutamento, que também precisam do seu tempo para encontrar os candidatos mais adequados.

O recrutamento contínuo pode facilitar este processo, para que quando seja necessário realizar um estudo de usabilidade, já tenhamos devidamente identificados os participantes que podem colaborar nesse mesmo estudo, prontos a serem chamados.

Em suma

Já se nota uma mudança de paradigma, principalmente porque as empresas finalmente estão a perceber que o UX research tem um impacto muito grande nos seus clientes. Ou seja, a voz dos profissionais de UX é, cada vez mais, solicitada para ajudar na tomada de decisões.

Para que os profissionais de UX continuem a conseguir impactar as empresas e os negócios, têm de envolver o maior número de interlocutores, sem nunca esquecer quais são os princípios do desenvolvimento de software: criar hipóteses, testar e implementar. Quanto mais pessoas estiverem envolvidas, maior o conhecimento coletivo.

Ao partilhar os resultados do research de forma acessível, não só conseguimos economizar tempo, mas também capacitamos a equipa de produto, criando uma visão partilhada e que pode ser iterada por todos.

O nível 2 da Certificação UX-PM, para além de mostrar como integrar as principais ferramentas e atividades de UX em diversos projetos, incluindo UX research, dá alguns exemplos e dicas de como podemos envolver os stakeholders nos diferentes momentos em que os researchers e designers necessitam de tornar visível o seu trabalho.