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

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.

Mostrando 3 comentários
  • Coca
    Responder

    @Driker, muito bom seu texto! Eu passo por isso de vez em quando, com algumas equipes de desenvolvimento para cliente interno. O que eu tento fazer, quando esse é o caso, é montar uma “reunião” estilo “get together” (pode ser um almoço ou café, por exemplo), onde o objetivo é que usuários, desenvolvedores, project managers, product owners e todos envolvidos se conheçam de fato e se aproximem. Em muitos casos, os desenvolvedores sequer sabem o nome dos seus usuários e os usuários sequer imaginam os rostos dos desenvolvedores ou sabem onde eles sentam no prédio…

    Depois dessa apresentação inicial, colocamos Dev para sentar junto com os usuários, entendendo o processo, os flows de navegação e, com isso, eles percebem muitos pain points um do outro e os Devs costumam ter muitos insights sobre como melhorar o software / produto e o user experience, de modo geral.

    Também é um ótimo momento para introduzir os “Showcases”, onde principalmente para novos produtos, o usuário pode dar feedback do que está em progresso e ambas partes trabalham de forma bastante colaborativa. 🙂

    • Diogo Riker
      Responder

      Oi, Coca!!!

      Que ideia sensacional essa reunião get together!!! Pelo que você falou é algo bem descontraído, certo? Muito bom. Já pensou fazer tipo um happy hour? Fechar um bar, colocar stakeholder e usuários pra conversarem… ia ser muito massa!

      No meu projeto atual, já fizemos algo semelhante e logo depois começamos o teste de usabilidade com esses usuários. Foi bem produtivo e todos passaram feedback muito importante para o produto que estamos desenvolvendo.

      No final eles deixaram o feedback do evento.. foi muito bom também.

  • Coca
    Responder

    Sim!! Descontraído e bem informal! A ideia eh mesmo aproximar as pessoas
    Amei a ideia do happy hour num pub! Com uma Guiness para brindar

Deixe um Comentário

Comece a digitar e pressione Enter para pesquisar