Meu Time Não Pensa na Experiência do Usuário… E Agora?

  • 20
  • 1
  •  
  • 27

E aí, galera!

Recentemente no canal #AgileUX, da comunidade agilidade.org, foi levantada uma questão bem interessante e achei válido trazer para o blog. O problema levantado foi: Meu time não se interessa pela experiência do usuário do nosso produto. E agora?

Decidi transformar essa discussão em um post, pois acredito que é algo muito recorrente em times e apareceram sugestões muito boas nessa discussão. Desde já, deixo meu agradecimento a todos os participantes envolvidos nessa discussão: Chrístian Carrard, Rafael Caceres, Guilherme Motta,  Raphael Albino e Bruno Camarini.

Então vamos lá, o que fazer nessa situação? Aqui vão algumas sugestões para determinados contextos 🙂

Meu time não sente empatia pelo usuário.

Penso que essa questão vai muito além de engenharia de time. É algo cultural e precisa ser trabalhado constantemente. Ou seja, seu time deve-se colocar no lugar do usuário e um dos melhores caminhos para isso acontecer é, de fato, colocá-los para utilizar o produto.

Um comentário muito bom que o Rafael Caceres fez foi:

Eles tem que sentir na pele que não adianta ter um código lindão e uma interface difícil de usar.

Outra recomendação é fazer com que seu time observe os usuários fazendo uso desse produto. Um dos princípios do Lean UX é o get out of the building, ou seja, ir para a rua e entender os principais problemas com quem sente essa dor. Essa observação é uma forma muito rica para levantar novos requisitos e identificar melhorias baseadas em problemas reais.

Destaco também uma técnica muito comum na área de design, conhecida como teste de usabilidade. Ou seja, seu usuário faz determinadas tarefas (definidas pelo seu time) e, pelo menos duas pessoas o observa, tomando notas sobre o seu comportamento.

Ex.: Entre na página principal de nosso produto e compre um livro.

Anotação: Enquanto o usuário tentava realizar a tarefa de comprar um livro, ele entrou na página de FAQ para saber como faz e demonstrou frustração por ter dificuldades em não conseguir realizar a tarefa com facilidade.

Para auxiliar essa observação, você pode pedir para o seu usuário falar em voz alta o que ele está fazendo e pensando. 
Mostre o impacto da atividade do seu time no dia-a-dia do usuário.

Quando times não tem esse mindset, geralmente o pensamento é:

Meu usuário é burro! Como ele faz isso se era para fazer aquilo?

Não sei se vocês sabem, mas usuários não dão a mínima para o código que está sendo desenvolvido ou para a tecnologia escolhida pelo time. Mas, isso não é motivo para fazer de qualquer jeito. Um código mal feito pode acarretar em inúmeros problemas para ele como, por exemplo, uma aplicação muito lenta devido ao número excessivo de requisições para determinado servidor, bugs que afetam diretamente a experiência do uso, entre outros. O pior caso que pode acontecer é seu usuário simplesmente parar de usar seu produto e começar a falar mal dele para outras pessoas.

Utilize métricas para mostrar o quanto isso está impactando na vida do usuário e, até mesmo, na sustentabilidade do negócio como um todo. Mas Diogo, quais métricas eu avalio? Bom, depende do seu negócio. Em geral, costumo usar as métricas de eficácia, pois elas estão relacionadas a felicidade do seu usuário. Em outro post escrevo mais sobre elas.

Procure sempre medir as ações de seus usuários. Números não mentem. :)
Capacite seu time.

Existem diversos treinamentos focados em User Experience e muitos deles tem como objetivo colocar o usuário no centro de tudo, destacando o seu ponto de vista sobre determinados problemas.

Particularmente esse aspecto muito me agrada, pois é uma forma poderosa de quebrar o famoso paradigma de que é culpa do usuário. Entretanto, uma ressalva que faço é que seu time precisa sentir essa necessidade. Fazer um treinamento apenas por fazer, faz com que o participante não sinta tanto interesse. Mas, se esse treinamento tem a capacidade de resolver uma dor que seu time esta sentindo, ele tem mais valor.

Prototipação Colaborativa.

Esse tópico eu já escrevi mais detalhado aqui em nosso pub. Algo interessante nisso é fazer com que o time todo participe do processo de criação de uma feature. Isso ajuda muito no alinhamento sobre o entendimento de negócio, técnico e comportamental que seu produto deve ter.

Uma dica importante é buscar inserir algumas questões de usabilidade nessas sessões. Você pode usar como base as heurísticas de Nielsen para trabalhar esse mindset durante o processo de construção.

Recomendo também utilizar a conhecida técnica da Jornada do Usuário antes de começar a rabiscar a solução, pois isso ajuda muito em entender o contexto dele.

Ex.: Minha solução é web, mas meu usuário passa a maior parte do tempo em pé, longe do computador.

Isso levanta alguns questionamentos sobre a solução que está sendo construída: faz sentido ser web ou app? Ou talvez um site responsivo? Se for responsivo, é interessante economizar em imagens e investir em mais texto? Entre muitos outros.

Fale sobre isso nas retrospectivas.

Como bom agilista, penso que isso é um assunto muito importante para ser debatido numa retrospectiva. Para esse tópico vou deixar uma citação que Raphael Albino fez durante a discussão:

Uma outra sugestão seria uma retrospectiva onde o tema seria o quesito design. Já fiz isso como uma equipe onde trouxe para pauta as dificuldades dos usuários (métricas de atendimento seriam bem bacanas), as inconsistências reais de interface (fatos e não gostos) e uma visão de mundo ideal da interface.

A discussão gerou ótimas ações de curto (ajustes que viraram itens de backlog), médio (rotinas mensais de avaliação da interface por parte do time) e longo (entrevistas trimestrais com usuários/atendentes para o levantamento das dores) prazo. 

É isso, galera! Tentei resumir alguns pontos que foram levantados na discussão. Para mim, foi algo muito rico e engrandecedor poder participar, pois foi de encontro com um propósito que tenho: fomentar a cultura ágil na área de design.

Grande abraço.

Leave a Comment