Personas se tornaram um “clássico” na pesquisa de usuários. Protean, eles reinam como um medidor padrão de boas práticas em metodologias de UX. No entanto, do outro lado do Atlântico, os Jobs-to-be-done apresentam-se como um desafiante.

Raramente questionado, as personas são realmente úteis? Esta é a questão que queremos discutir com você. Fazer um olhar crítico sobre nossas práticas para aprofundá-las e criar novas, esse também é o objetivo que perseguimos por meio do nosso blog.
E quando os designers fazem as perguntas que construirão a experiência do usuário de amanhã, compartilhamos o fruto de sua reflexão.
Assim, página de Laubheimer, Especialista em UX na Nielsen Norman Group, abre o debate sobre personas vs jobs-to-be-done. Aqui está a tradução de seu artigo.

Personas x Trabalhos a serem feitos

As tarefas a serem realizadas concentram-se nas dificuldades e necessidades dos usuários. Personas bem executados, por outro lado, incluem detalhes adicionais sobre o comportamento e a atitude dos usuários.
Personas têm sido um elemento básico do processo de design centrado no usuário; mas nos últimos anos, os jobs-to-be-done, uma técnica centrada nas necessidades do cliente, viram o seu lugar assumir uma importância significativa.

Definição

Jobs-to-be-done é um conjunto de ferramentas baseado na ideia de que cada vez que o usuário “contrata” um produto, ele é usado para realizar uma missão específica (os famosos “jobs”) e, portanto, obter um determinado resultado. Cada JTBD realmente corresponde à lista completa de necessidades do usuário.

A crescente popularidade dos jobs-to-be-done faz alguns dizerem que as personas podem ser abandonadas, sendo os JTBDs uma técnica mais útil. Esta opinião é baseada em uma compreensão inicial pobre do propósito das personas. Deixe-me explicar: as personas seriam principalmente representações demográficas dos usuários, sem levar em conta fatores comportamentais. Esses fatores são, no entanto, essenciais para produzir boas personas em UX Design e estratégia de produto.

TRABALHOS A SEREM REALIZADOS: UM RECURSO ÚTIL

Focada em resultados e não em funcionalidade, a técnica JTBD é baseada em uma representação das necessidades do usuário. É obtido por estudos qualitativos realizados com usuários (pesquisas de campo, entrevistas ou teste de usabilidade simplificado).
Uma das etapas é determinar o que motiva os usuários a “contratar” um produto (lembre-se, eles têm missões a cumprir). Também permite, idealmente, descobrir os produtos concorrentes existentes cujos usuários estão dispostos a prescindir dos nossos. Tendo tudo isso em mente, a equipe de produto pode se concentrar na natureza das restrições e necessidades básicas do usuário. Então, de um novo ângulo, projete os recursos que melhor atendem às principais necessidades do usuário.

Um exemplo: serviços de entrega

Se uma análise das tarefas tradicionais descobrir que os entregadores geralmente precisam imprimir instruções de navegação entre cada parada em sua rota diária, é provável que os desenvolvedores tentem simplificar o formato e as instruções de impressão o máximo possível. Uma abordagem centrada em JTBD, por outro lado, se concentrará na "missão" do motorista (ou seja, obter conselhos de navegação enquanto dirige) e procurará soluções para esse problema (como um sistema GPS guiado por voz).
As ferramentas Jobs-to-be-done sugerem que a inovação e o ótimo design vêm da avaliação das necessidades reais do cliente e da criação de uma solução livre de produtos que já as atendem. No entanto, uma postura tão radical sobre a inovação pode vir a ser uma estratégia caro e arriscado para melhoria do produto. E por um bom motivo, aqui está a citação favorita dos apoiadores do JTBD:

"As pessoas não querem comprar uma broca de 60 mm, elas querem um furo de 60 mm" - Theodore Lewitt

Em vez de se concentrar em uma lista de recursos para um produto, a estrutura de tarefas a serem feitas exige que os designers reflita sobre os resultados :

• Os usuários conseguirão realizar (de maneira fácil e agradável) a missão para a qual “contrataram” o produto?
• Esta solução oferece um resultado melhor do que as soluções existentes?

A abordagem JTBD não prescreve um formato ou produto específico. Mas, na maioria das vezes, o trabalho a ser feito é definido por uma frase informando o que os usuários precisam fazer, juntamente com um conjunto de informações contextuais, como por que e onde eles estão fazendo isso.
Finalmente, uma descrição das tarefas a serem realizadas geralmente reúne dois tipos de critérios. Os primeiros são os critérios de sucesso funcional (o propósito da missão, as instruções claras para alcançá-la). Os segundos são os critérios de sucesso emocional (que pode ser dividido em critérios emocionais individuais dos usuários e considerações sociais, como como eles imaginam que serão percebidos pelos outros).
As tarefas a serem realizadas geralmente são resumidas em uma única frase descrevendo o que o usuário precisa realizar e qualquer contexto importante que possa afetar a missão (no exemplo a seguir, viajando para um congresso em vez de feriados). Jobs-to-be-done também inclui informações sobre critérios objetivos para o sucesso funcional, bem como critérios subjetivos para o sucesso emocional que contribuem para uma boa experiência.
Os critérios emocionais são frequentemente divididos em duas partes : critérios pessoais e considerações sociais.

PERSONAS BEM DESENHADOS SÃO MAIS DO QUE UM DIRETÓRIO DE DEMOGRÁFICOS

A maioria dos argumentos apresentados para sugerir que as personas se tornaram inúteis com a chegada de jobs-to-be-done baseiam-se no equívoco de que estas são principalmente representações demográficas de usuários.
Além disso, os dados demográficos são problemáticos para a tomada de decisões no design de produtos, pois não fornecem dados sobre comportamentos e atitudes do usuário e são mais adequados para fins de marketing e publicidade.

Na verdade, as personas devem ser representações complexas de usuários e vão além de simples dados demográficos ou pessoais.
As personas mais bem projetadas incluem uma riqueza de informações, incluindo:

• Detalhes demográficos, como idade, estado civil e renda;
• detalhes pessoais, como uma breve biografia, foto e nome;
• Detalhes cognitivos ou atitudinais, como informações sobre o modelo mental da pessoa, sua pontos de dor e sua percepção das tarefas a serem cumpridas ;
• Objetivos e motivações para o uso do produto;
• Detalhes comportamentais sobre como a persona tende a agir ao usar o produto.

Os dados demográficos e pessoais existem por duas razões principais:

• Para que os membros da equipe do projeto criem empatia com o usuário
• Como uma técnica mnemônica para ajudar a torná-lo memorável Pela equipa.

Infelizmente, muitas personas (que na verdade são segmentos de marketing que são passados ​​como tal) não vão além do nível demográfico ou pessoal. É por isso que esta ferramenta é frequentemente considerada menos útil que os JTBDs para tomada de decisão durante o projeto.
Uma persona ideal é amplamente baseada em características comportamentais complexas, dados de atitude e modelos mentais, exigindo também pesquisa qualitativa com usuários reais, para descobrir as razões por trás do comportamento do usuário. Essas personas complexas normalmente incluem informações relacionadas a objetivos específicos que os usuários devem alcançar ao usar o produto. Esses objetivos são diretamente comparáveis ​​às informações encontradas na definição do JTBD.

Personas bem projetados incluem detalhes sobre os objetivos do usuário semelhantes às descrições de tarefas a serem feitas, mas são enriquecidas com dados comportamentais, contextuais e pessoais que podem fornecer um conjunto abrangente de insights para orientar os designers. UX e equipes de produto em sua decisão fazer. (Fizemos a seguinte persona como exemplo em um relatório sobre o desenvolvimento eficaz de produtos Agile UX, mas é representativo de personas desenvolvidas para projetos que usam uma abordagem de design centrada no usuário.)

MENOS: JOBS-TO-BE-DONE NÃO PROMOVE EMPATIA

Uma das principais razões pelas quais as personas inicialmente se concentravam em representações realistas de usuários era se afastar de um modelo excessivamente formal de experiência do usuário que girava em torno de listas de tarefas e requisitos.
Isso permite que você pense no que a Experiência deve ser para o usuário. De fato, os JTBDs, no entanto, fazem algumas considerações sobre o contexto emocional e social das motivações dos usuários. No entanto, eles generalizam essas informações para toda a base de usuários.
Como resultado, perdemos a noção-chave do contexto preciso de uso do alvo e os designers perdem a oportunidade de criar empatia com o usuário.

 

PRIORIZE USUÁRIOS DIFERENTES COM PERSONAS

Imagine o seguinte cenário : fazemos parte de uma equipe de designers que projeta a nova versão de um aplicativo de produtividade de desktop. Nos últimos anos, concorrentes entraram no mercado com produtos inovadores, e a direção de nossa empresa deseja redesenhar seu produto para ser mais competitivo no mercado. Embora seja útil pesquisar seus clientes atuais e potenciais para descobrir quais JTBDs são importantes para eles, também vale a pena observar as principais diferenças entre esses dois grupos.
Se começarmos do zero para o redesenho do aplicativo, forçaremos os usuários existentes e leais a treinar novamente em seu uso, devido a uma mudança na rota que costumavam seguir. Isso também terá um impacto negativo em sua produtividade. Se redesenharmos completamente um recurso antigo (ou, como costuma sugerir a técnica “jobs-to-be-done”: criar uma solução totalmente diferente e inovadora para o problema), corremos o risco de penalizar o banco de dados.

Durante o design, você deve encontrar o equilíbrio entre as várias opções possíveis de acordo com o tipo de usuário, que muitas vezes tem motivações diferentes. Enquanto todos os compradores de uma furadeira têm a mesma missão a cumprir (furar furos), um profissional vai atentar para a durabilidade de sua ferramenta, enquanto um hobista que queira pendurar alguns quadros em casa ficará mais atento ao preço. Estando estas duas considerações em conflito, é necessário diferenciar e priorizar os usuários se não quisermos terminar com uma solução inovadora, mas provavelmente insatisfatória.
Embora o mesmo trabalho a ser feito possa ter requisitos diferentes para diferentes grupos de usuários, o inverso também é verdadeiro: um grupo de usuários (ou persona) pode "contratar" o produto para diferentes missões em diferentes contextos.

Um exemplo: reservas online

Posso usar o mesmo site de reservas para voos de negócios e lazer. Esses tipos de jornadas são de fato trabalhos distintos que trazem reflexões muito diferentes, mas meu modelo permanece o mesmo em relação ao sistema que me é apresentado, assim como minha atitude e meu comportamento - que eu para um NN/g conferência UX ou fazer uma caminhada no Peru. Meus comportamentos e minhas atitudes provavelmente se assemelham aos de certos grupos de usuários, bem como são totalmente diferentes dos de outro grupo. Por isso criamos múltiplas personas: para pensar nas diferenças entre os usuários que nos permitem equilibrar necessidades e priorizá-las entre as personas.
 

PERSONAS & JOBS-TO-BE-DONE: É UM JOGO!

Enquanto alguns pensam que os JTBDs podem substituir totalmente as personas, os dois são realmente compatíveis. Dependendo da necessidade do cliente e se a equipe responsável pelo produto já utiliza personas ou jobs-to-be-done, eles podem ser utilizados de forma complementar: as informações fornecidas pela ferramenta JTBD podem ser integradas às personas.

Para empresas que já utilizam JTBDs, não há necessidade de duplicar uma tarefa com personas: personas específicas podem complementar JTBDs existentes com informações únicas e diferenciadoras sobre critérios de sucesso funcional e/ou emocional.
E vice-versa: se estas são as personas que já existem dentro da empresa, mas que não contêm as motivações complexas nem os dados comportamentais essenciais para uma persona eficaz, podemos começar por aprimorá-las com informações semelhantes ao JTBD. Vamos começar aprimorando as personas com informações semelhantes a jobs-to-be-done: ao invés de listar os objetivos do usuário, vamos pensar neles como objetivos a serem alcançados. Vamos nos perguntar o que o usuário está tentando realizar. Quais são as principais considerações de sucesso (funcionais e emocionais) para essas missões?
Se há muita resistência dentro da empresa à criação de personas (se nossos colegas estão céticos ou nossa hierarquia se esforça para dar luz verde), mas ainda é possível influenciar o design do aplicativo graças a um apetite e meio de design centrado no usuário, os JTBDs podem ser uma alternativa útil. De fato, a cobertura da mídia em torno dessa ferramenta popular pode despertar um certo entusiasmo entre o cliente. Vimos também que JTBDs podem ser usados ​​em combinação com personas em uma segunda etapa.
 

Tirar

• Use usuários representativos e atribua-lhes tarefas representativas para realizar testes válidos. Um design pode ser perfeito para um grupo e terrível para outro.
• Diferenciar os públicos-alvo e suas motivações durante o projeto de um produto evita o aparecimento de funcionalidades ruins durante o processo. Usuários e objetivos: os ingredientes necessários para um UX Design de sucesso!
• Entenda a utilidade de uma persona bem executada torna possível representar as necessidades específicas dos usuários. A informação complexa que reúne promove a empatia durante o design do produto.

fonte

Persona vs tarefas a serem feitas, Página Laubheimer @Nielsen Norman Group

Referências

• Cartões UX por UX Republic
• kit persona por UX Republic

Contexto: Sébastien Faure, UX Content Manager @UX Republic @sebfaureUX / Phonesavane Soulivong, UX Communication & Marketing @UX Republic @psvn_soulivong / Tradução : Eric Bossin

---