Dívida de UX: como identificar, documentar e priorizar na prática com Research Ops
No meu segundo mês trabalhando como UX Researcher em uma Logtech me deparei com o desafio de identificar bugs que estavam atrapalhando a experiência do usuário no aplicativo após o lançamento de uma nova feature. Primeiro vamos entender o que é um bug e uma dívida de UX.
O que é um Bug?
Um bug é um comportamento inesperado que acontece com softwares e hardwares. Os problemas típicos geralmente são resultados de cenários não previstos no desenvolvimento.
A experiência do usuário pensa em tudo que afeta os usuários e sua interação com o produto. Logo, qualquer falha na experiência do usuário é um bug de UX.
“Bugs e travamentos enfurecem os usuários e impedem a conclusão de suas tarefas — às vezes a ponto de exigir soluções alternativas demoradas. Mas esses erros de implementação também reduzem a capacidade de aprendizado, porque os usuários geralmente desenvolvem superstições elaboradas em torno do problema.”
O que é uma dívida de UX?
A palavra “dívida” indica que você deve algo a alguém. Isto é, você pega algo de alguém e em alguma situação deixa de pagar de volta. A dívida de UX surge quando você tem problemas de experiência do usuário que não foram resolvidos em seu produto e que foram criados ao longo do tempo. Então, as pessoas que você deve, neste caso, são seus usuários.
Fatores que contribuem para dívida de UX:
- Não realizar estudos de usabilidade;
- Ignorar os padrões da marca e guias de estilo;
- Interpretação errada da visão do produto;
- Aquisição ou fusão com outros produtos;
- Má comunicação ou documentação entre o time;
- Teste de controle de qualidade insuficiente;
- Código legado ou dívidas técnicas atrasadas, tais como refactoring e tests.
Consequências de NÃO pagar dívidas de UX:
- Grande consumo de recursos para realizar o redesenho e recodificação do produto;
- Um projeto lançado abaixo do ideal afeta a participação da empresa no mercado a longo prazo, uma vez que os clientes darão uma chance e depois desistirão quando o projeto for muito difícil e não atender às suas necessidades;
- Os usuários tendem a se acostumar com o design ruim;
- Uma mudança no design pode fazer com que os usuários criem uma aversão pela empresa e produto, visto que serão forçadas a criar um novo hábito;
- Mudar o design para qualquer componente específico do UX geralmente degrada os sentimentos de consistência e coerência;
- Os fracassos do negócio viverão para sempre na internet, dado que o aprendizado é social, os usuários continuarão sendo informados por anos sobre os seus erros por meio de redes sociais e canais de reclamação como o Reclame Aqui, assustando assim novos clientes potenciais.
Como descobri que estava lidando com dívidas de UX?
Estudando sobre como os bugs comprometem a experiência do usuário me deparei com um artigo da Anna Kaley (especialista em experiência do usuário no Nielsen Norman Group) relacionado a Dívida de UX (Debt UX).
O artigo fala que as dívidas de UX são problemas conhecidos de experiência do usuário que ainda não foram corrigidos. Essas dívidas surgem quando designers e pesquisadores estão trabalhando com prazos apertados ou com muitas restrições.
Com isso, compreendi que os problemas que os usuários estavam enfrentando dentro do nosso produto estavam ligados às Dívidas de UX, visto que essas dívidas trazem consequências enormes para o usuário e para o produto.
Comecei a documentar os problemas em uma base chamada “Issues”, na qual os classifiquei como: “bugs”, “questions” e “features”.
O que é um issue?
Issue é um problema ou questão de um projeto específico usado para rastrear ideias, erros, comentários, tarefas e planejar o trabalho. Através de um issue você pode compartilhar e discutir propostas com os seus pares.
Como acompanhar as dívidas de UX?
Para acompanhar uma dívida de UX é necessário identificar os problemas e adicioná-los em uma base, pode ser criando uma lista no Google Sheets, Airtable, Excel ou Notion, por exemplo.
A dívida de UX pode ser adicionada diretamente ao backlog, caso você tenha autonomia para fazer isso na empresa, no entanto, ao colocar a dívida no backlog você corre o risco dela se perder ou de ficar sempre despriorizada em função de novas features.
No meu caso eu utilizei o Notion para documentar as dívidas de UX, porque ele permite:
- Criar padrões de relatórios deixando o trabalho mais ágil;
- Filtrar dados de forma fácil e rápida;
- Exportar relatórios em PDF (isso auxilia na comunicação com as partes interessadas, logo vou falar mais sobre isso).
5 coisas que você precisa fazer quando se depara com uma dívida de UX:
1. Identificar o problema
Durante a identificação dos problemas me deparei com as seguintes situações:
- Bugs — problemas inesperados que acontecem no produto, que comprometem, inviabilizam e/ou dificultam o uso;
- Features — sugestão de melhoria para alguma funcionalidade do produto;
- Questions — Algo que foi identificado e que pode ser definido como um bug ou uma feature posteriormente (você precisará de ajuda de pessoas que compreendem mais sobre a regra de negócio para poder classificá-lo melhor).
Meios que podem te ajudar nesse processo:
- Utilize uma ferramenta de análise comportamental: utilizei o Hotjar para entender como os usuários estavam interagindo com a nova feature e com alguns elementos do aplicativo. Ao assistir às sessões pude identificar bugs e obstáculos que estavam atrapalhando a experiência do usuário. Vou deixar aqui algumas dicas de como usar o hotjar na identificação de problemas:
- Procure um lugar que você consiga ficar focado(a) sem distrações por 1–2 horas — são necessárias cerca de 10 a 15 gravações para entrar em um bom fluxo;
- Faça anotações (recomendo o Notion);
- Defina o objetivo da sua sessão de visualização (é um ponto importante, pois o Hotjar libera mais de 400 gravações por dia);
- Analise a feature sempre a partir da nova release;
- Filtre as gravações a partir do seu objetivo (filtros que usei: referrer URL; new/ returning; duration; rage click; U-turn).
- Seja cliente do seu produto: teste as novas funcionalidades e registre os problemas encontrados;
- Converse com o Suporte, CS e CX: pois são equipes que estão em mais contato com clientes reais todos os dias.
2. Rastrear o problema
Depois de identificar os problemas, é necessário registrá-los em um documento. Para isso construí uma base de dados no Notion levando em consideração os seguintes pontos :
- Descrição do problema;
- Identificação do responsável por relatar o problema;
- Tags de identificação: bug, feature e question;
- Status do problema: aberto ou fechado;
- Data de reporte;
- Reports equivalentes — para identificar a frequência com que o problema ocorre;
- Prioridade de correção.
Atenção! A descrição do problema precisa ser clara e objetiva para que as partes interessadas entendam assim que lerem.
3. Priorizar o problema (backlog e lista de pendências)
A priorização foi realizada com base no impacto que o problema/bug teve na experiência do usuário:
- Alta: Qualquer coisa que afete o fluxo normal do usuário ou bloqueie o uso do produto.
- Média: Qualquer coisa que afete negativamente a experiência do usuário;
- Baixa: TODO o resto (por exemplo, erros de ortografia, ícones ausentes, problemas de layout, etc.)
Você também pode priorizar os problemas com os stakeholders usando a matriz de priorização, essa auxilia na tomada de decisão de forma colaborativa, classifica os problemas e comunica o progresso de pagamento das dívidas de UX para os stakeholders.
4. Comunicar o problema para os stakeholders
Para comunicar o problema você pode marcar uma reunião de apresentação com os stakeholders ou pode enviar a documentação por e-mail. Eu recomendo que você comunique os bugs e problemas com alta prioridade o mais rápido possível, pois possuem impacto na experiência do usuário e consequentemente no negócio.
Todos precisam saber que a dívida existe! É importante dar acesso a base de dados que armazena o problema por gravidade e status, além de falar a mesma linguagem que o restante da empresa. Então, certifique-se que ao descrever o problema a sua comunicação está clara e entendível para qualquer pessoa da empresa.
5. Planejar a correção
Após a comunicação dos problemas, pessoas POs e PMs ficaram responsáveis por priorizar a dívida de UX dentro de cada sprint conforme foram realizando melhorias gerais no produto (na empresa em que trabalho foi abordado dessa maneira, pode ser que no seu caso a abordagem seja diferente).
A Anna Kaley (especialista em experiência do usuário no Nielsen Norman Group) recomenda que sejam abordados pelo menos um ou dois itens de dívida de UX por sprint.
Conclusão
As dívidas de UX muitas vezes não podem ser evitadas, mas você pode reconhecê-las e organizá-las com o seu time. Quando você colabora para corrigi-las, você também ajuda a preservar a integridade do negócio e do produto. Ficou interessado no meu repositório de dívidas de UX? Você pode duplicá-lo clicando aqui. Você já precisou lidar com dívidas de UX? Me conta aqui nos comentários.
