Ladies That UX PT
Published in

Ladies That UX PT

Dívida de UX: como identificar, documentar e priorizar na prática com Research Ops

Jovem negra com cabelo castanho e solto está em pé explicando as suas ideias em um quadro branco.

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.”

Jakob Nielsen — NN Group

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.
Jovem negra com cabelo preto e solto segurando o queixo .

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).
Jovem negra com cabelo solto e blusa branca sorrindo apontando para si mesma.

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:
  1. 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;
  2. Faça anotações (recomendo o Notion);
  3. Defina o objetivo da sua sessão de visualização (é um ponto importante, pois o Hotjar libera mais de 400 gravações por dia);
  4. Analise a feature sempre a partir da nova release;
  5. 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.

Gráfico de Severidade para Priorização de Dívidas de UX. Clique aqui para duplicar o gráfico.

“Visualizar a dívida de UX em um gráfico de dispersão pode ajudar a equipe a organizar, entender e priorizar os problemas com base no valor para o usuário e no nível de esforço necessário para corrigir o problema antes de adicioná-lo ao backlog”.

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.

--

--

--

Conteúdo em português da Comunidade Ladies That UX

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ana Laura Gabriel Moreira

Ana Laura Gabriel Moreira

UX Researcher Ops, gosto de compartilhar experiências, conhecimento e ferramentas para ajudar o dia a dia das pessoas pesquisadoras.

More from Medium

How an MFA in Poetry Prepared Me for a Career in UX Design

A drawing from Richard Scarry’s “What Do People Do All Day?” with an animal holding a quill and the caption “a poet writing poems”

Affective Computing, A new way to measure human emotions | GSR research in UX

Safety needs of people of marginalised genders: UX research case study

Two smiling brown women in suspended mid-air, a pink and blue rainbow and rainbow coloured flowers and stars in the background

Meet Antenna: Niamh Redmond

Niamh holding a dog on a beach