O debate entre persona e tarefas a serem feitas.
Esse artigo faz parte da série de artigos UX Translations. Foi escrito originalmente por Fei Ren via UX Collective e traduzido para português com intenção de ajudar mais designers e alcançar um público ainda maior. Você pode conferir o artigo original no link abaixo:
Personas, jobs to be done, user needs = goals + pain points
Ultimamente, eu tenho trabalhado em descobrir necessidades de usuário não atendidas para a minha empresa usando a estrutura de tarefas a serem feitas, e eu vi alguns debates entre pessoas que usam personas e pessoas que usam tarefas a serem feitas.
Uma crítica comum em usar personas feita por quem usa tarefas a serem feitas é que personas tendem a se concentrar nos atributos dos usuários (como localização, idade, ocupação…) em vez de necessidades não atendidas. No entanto, isso não é culpar as personas em si, é culpar as pessoas que as usam mal. Concentrar-se nas necessidades é exatamente pra que servem as personas. Tendo dito isso,, se a persona só mostra os atributos demográficos dos usuários, estão fazendo errado! As personas do design devem se basear numa quantidade significativa de pesquisa do usuário que identifique as necessidades não atendidas do usuário, ao invés vez de se limitarem a apenas coletar dados analíticos. Boas personas frequentemente podem servir como uma ferramenta de comunicação para resumir a pesquisa do usuário e para fornecer descobertas críticas quando você chegar à fase de solução. Para construir uma persona de sucesso, precisamos ter uma grande compreensão dos objetivos do usuário, pontos de dor e padrões de comportamento.
As tarefas a serem feitas também se concentra nas necessidades do usuário. A teoria é que as pessoas contratam produtos para fazer “tarefas”. A confusão comum para as pessoas que usam personas é o termo “tarefas”. O argumento é que as pessoas não contratam um produto para simplesmente fazer um trabalho, elas contratam um produto para satisfazer suas necessidades. No entanto, as tarefas na estrutura de tarefas a serem feitas não são soluções ou deveres, elas também devem refletir as necessidades. Então o que é uma “tarefa”? Eu gosto do que Alan Klement definiu em seu artigo: “uma tarefa a ser feita é o processo pelo qual um consumidor passa sempre que ela pretende transformar sua situação de vida existente em uma que ela preferiria, mas não pode, porque existem limitações que a impedem.” Isso parece familiar? Na realidade, isso soa muito parecido ao que estamos tentando alcançar com personas. A estrutura das tarefas a serem feitas também foca muito na pesquisa qualitativa dos usuários. Uma grande diferença entre os dois é a entrega. As personas fazem um trabalho melhor em promover a empatia, criando um usuário fictício que podemos representar enquanto a estrutura das tarefas a serem feitas é melhor na comunicação dos resultados desejados.
Necessidades não atendidas = objetivos + pontos de dor
É extremamente crítico descobrir as necessidades não atendidas dos usuários através da pesquisa tanto para personas quanto para as tarefas a serem feitas. Qualquer necessidade não atendida terá sempre dois componentes:
- O objetivo: o que você quer realizar e por que você quer realizar isso.
- O ponto de dor: o que te impediu de realizar isso.
Encontre os verdadeiros objetivos dos usuários: descubra como os usuários formam suas emoções
Às vezes é difícil identificar as verdadeiras necessidades dos usuários se mantivermos nossa pesquisa de usuário apenas em um nível superficial. É fácil ter a pergunta “O que você quer realizar” respondida muito rapidamente, mas às vezes sem saber “por que você quer realizar isso”, a resposta nos levaria à conclusão errada.
Deixe eu te dar um exemplo de uma necessidade não atendida onde encontrar o verdadeiro objetivo é o problema. Volte para o meu exemplo do ônibus de Ann Arbor. Se apenas perguntarmos “o que aconteceu” e “o que você quer realizar”, um usuário nos contaria uma história como esta:
“Verifiquei o horário do ônibus. O ônibus deveria chegar às 15h30. Cheguei no ponto de ônibus às 15h25. Já são 15h35, mas o ônibus ainda não chegou. Porque é que o ônibus sempre se atrasa? Eu fico irritado e ansioso quando ele se atrasa. Quero que o ônibus chegue no horário para não ter de esperar aqui!”
Como o usuário se queixou do atraso do ônibus, é fácil chegar à conclusão de que o objetivo do usuário é entrar no ônibus no horário. E eventualmente, podemos criar uma solução acerca da velocidade ou da impermeabilidade do ônibus.
No entanto, se perguntarmos “por que você se sente ansioso no ponto de ônibus quando o ônibus está atrasado?”, vamos ver mais de perto como este usuário forma suas emoções — irritação e ansiedade.
“Não faço ideia de onde ele esteja. Quanto tempo será o atraso? Está atrasado ou já saiu? Mudaram o ponto do ônibus para outro lugar? Devo esperar aqui ou devo chamar um táxi?”
Agora, ao fazer tal pergunta, temos uma ideia melhor de que o usuário não está essencialmente preocupado se o ônibus chega no horário. A ansiedade dele veio de não saber o status do ônibus. Então a solução deve ser projetada para melhorar a noção do status do ônibus.
Identificar os pontos de dor: compreender as limitações
Compreender os pontos de dor é compreender o que realmente impede as pessoas de alcançar seus objetivos. Uma coisa que tendemos a esquecer quando pulamos para a fase de solução é que compreender os pontos de dor de seu usuário alvo é tão importante quanto entender os objetivos que eles tentam alcançar. Às vezes, há produtos ou serviços no mercado que podem ajudar os clientes a alcançar seus objetivos, mas ainda fornecem pouco valor para eles.
Deixe deu dar um exemplo em que os pontos de dor impedem os usuários de atingir os seus objetivos. Dois anos atrás, eu trabalhei em um projeto para pessoas com baixa visão. A partir de nossa pesquisa de usuário, descobrimos que havia muitos tipos de tecnologias assistivas no mercado e muitos delas eram relativamente eficazes em proporcionar aos usuários uma melhor experiência de leitura.
As pessoas com baixa visão também estavam cientes das tecnologias assistivas disponíveis no mercado, mas ninguém que entrevistamos as utilizou. Qual era o problema? O preço. As pessoas não podem pagar pelos dispositivos, então eles escolhiam soluções de menor custo, e menor eficácia. Se criamos um incrível dispositivo que ajude as pessoas com visão baixa a alcançar seu objetivo de leitura sem remover o ponto de dor de acessibilidade econômica, ele se tornará outra tecnologia assistiva fracassada.
Uma vez que nem todos os seus usuários compartilham os mesmos pontos de dor, mas podem querer o mesmo objetivo, eles te ajudam a diferenciar, selecionar e priorizar para quem você vai projetar.
Recentemente, tenho entrevistado pessoas que estão tendo dificuldade com dissertações acadêmicas. Um tema comum dos objetivos que eles querem alcançar é ter suas dissertações revisadas e refinadas por especialistas. Algumas pessoas pensam que professores de redação são muito caros, enquanto outros não sabem onde encontrar professores particulares ou não estão confortáveis falando com professores. Embora o objetivo seja semelhante, os pontos de dor são diferentes. E porque os pontos de dor são diferentes, as suas necessidades são diferentes e não podemos ajudar todos a alcançarem seus objetivos usando a mesma solução. Como a imagem mostrada abaixo, qualquer combinação de objetivos e pontos de dor pode formar uma necessidade do usuário diferente. Para projetar pessoas com diferentes pontos de dor, as soluções também são muito diferentes.
O gráfico da estrutura das tarefas a serem feitas (mostrado abaixo) é bom para você ver quais tarefas são escassas à primeira vista. No entanto, não diz as razões pelas quais são escassas. Saber por que são escassas é crítico para decisões de design na fase de solução. É assim que acho que as personas podem nos ajudar.
*Notas da tradução:
Ainda que usemos muitas dessas palavras e expressões em inglês no nosso dia a dia como designers, a intenção do nosso projeto de tradução é democratizar o acesso a conceitos do universo de design e experiência do usuário, e isso inclui criar uma versão em português para esses termos.
Glossário:
- Tarefas a serem feitas: Jobs to be done (JTBD)
- Necessidades do usuário: User needs
- Objetivos: Goals
- Pontos de dor: Pain points
- Estrutura: Framework
Personas, tarefas a serem feitas, necessidades do usuário = objetivos + pontos de dor was originally published in UX Collective 🇧🇷 on Medium, where people are continuing the conversation by highlighting and responding to this story.
from UX Collective 🇧🇷 - Medium https://ift.tt/3gO7f9v
via IFTTT
Comentários
Enviar um comentário