Usuário Em Uma Frase

O que é um usuário em uma frase

A técnica de escrever um usuário em uma frase serve para resumir quem é o público-alvo de um produto, serviço ou funcionalidade num formato enxuto o suficiente para qualquer pessoa no time lembrar sem consultar documentação. Não é um conceito novo, mas muita gente ainda aplica de forma errada porque confunde resumo com definição técnica. A estrutura que eu uso na prática é simples, mas exige escolhas difíceis: [Perfil socioeconômico] + [comportamento atual] + [principal necessidade ou dor] + [onde ele busca resolver].

Isso gera algo como: "Mariana, 28 anos,ãodeclasseB,no interior de Minas, que trabalha meio período e sente vergonha de pedir ajuda para lidar com burocracia bancária, então evita ir a agências e faz tudo pelo aplicativo mesmo cometendo erros." Essa frase tem contexto real, não apenas dados demográficos. Eu já perdi uma semana inteira refatorando uma tela de onboarding porque a frase do usuário que o produto tinha definido era "João, 35 anos, homem, classe C, São Paulo, quer economizar dinheiro". Isso é uma ficha técnica, não um usuário. Ninguém consegue projetar nada significativo com essa informação. A workaround que eu descobri foi parar, entrevistar três pessoas reais que se encaixavam parcialmente nesse perfil e reconstruir a frase a partir do que elas realmente faziam, não do que achavam que deveriam fazer.

Pegadinhas que ninguém conta

A primeira pegadinha é acreditar que uma única frase resolve o problema de representação de todos os usuários. Isso nunca acontece. O que a frase faz é servir como âncora de conversa, não como verdade definitiva. Quando eu vi isso pela primeira vez, achei que tinha descoberto um atalho. Na verdade, ela serve mais para impedir que o time fique vagando durante reuniões do que para definir quem o produto é. A segunda pegadinha é mais técnica: a frase precisa sobreviver ao primeiro ciclo de teste com usuários reais. Me deparei com um caso em que o produto foi lançado e, depois de três semanas, percebi que o perfil descrito na frase nunca usou o aplicativo porque o público-alvo real era outro. A frase estava escrita por pessoas que nunca tinham falando com usuários de verdade. Eu mudei o processo interno para exigir pelo menos cinco entrevistas gravadas antes de qualquer frase ser aprovada, e isso aumentou o tempo de definição de dois dias para cerca de duas semanas, mas reduziu drasticamente retrabalho posterior.

O problema das frases genéricas

Frases como "usuário jovem que quer praticar esportes" são inúteis porque não especificam qual esporte, qual nível de experiência, onde pratica e quais barreiras reais ele enfrenta. A frase perde valor quantitativo quando você não consegue responder a perguntas concretas a partir dela. Se alguém perguntar "e aí, o que ela faria num momento de crise?", você tem que conseguir responder sem abrir uma pesquisa de mercado nova. Um detalhe prático que eu encontrei: frases muito longas (mais de quarenta palavras) tendem a ser ignoradas em reuniões. Frases muito curtas (menos de quinze palavras) perdem contexto essencial. O sweet spot fica entre vinte e cinco e trinta e cinco palavras, onde dá para caber perfis, comportamentos e motivações sem virar um parágrafo.

Alternativas quando a frase não funciona

Em produtos complexos com múltiplos segmentos distintos, uma única frase simplesmente não aguenta o peso. Nesse caso, eu prefiro usar um conjunto de três a cinco frases curtas, cada uma representando um segmento relevante, e manter todas visíveis no mural do time. Funciona melhor do que tentar empurrar quatro perfis diferentes num único parágrafo. Também existe o caso em que o produto é aberto e qualquer pessoa pode ser usuário. Aí a frase perde completamente o sentido. Eu já vi times tentarem aplicar esse método em ferramentas com audiências massivas e genéricas, e o resultado foi sempre frustração. Nesses cenários, segmentação por jornada de uso ou por nível de expertise costuma funcionar melhor do que tentar definir um usuário hipotético em uma só frase.

Usuário em uma frase na prática

O jeito que eu aplico isso no dia a dia é escrever a frase num cartão físico ou num quadro visível, não em um documento que ninguém lê. A frase precisa estar à vista durante sprints de design e desenvolvimento, porque a utilidade real dela é servir como referência rápida quando alguém pede para adicionar uma funcionalidade que não se encaixa no perfil. Quando a frase fica enterrada em um wiki, ela perde a função. O processo de validação que uso leva de duas a três sessões de trinta minutos com membros do time que não participaram da construção da frase. Eles tentam projetar uma solução baseada apenas nela e apontam o que não conseguiram responder. Isso revela falhas que eu jamais veria sozinho. O resultado geralmente é uma segunda versão da frase, mais enxuta e mais precisa, pronta para circular entre o resto do time. A parte mais chata, que eu preciso mencionar, é que esse método não substitui pesquisa qualitativa. Ele apenas organiza o que a pesquisa já produziu. Times que usam a frase como substituto de entrevistas estão gastando tempo de forma errada. A frase é um produto secundário do trabalho real, não o trabalho em si.

Resumo técnico do processo

• Entreviste pelo menos cinco usuários reais antes de escrever a frase
• Mantenha a frase entre vinte e cinco e trinta e cinco palavras
• Valide com colegas que não participaram da construção
• Coloque a frase em local visível, não em documento oculto
• Revisite e reescreva a frase após cada ciclo de lançamento com usuários

Se a frase sobreviver ao primeiro ciclo de lançamento sem precisar de ajustes dramáticos, você provavelmente acertou. Se precisar reescrevê-la a cada sprint, volte para as entrevistas. Esse é o indicador mais confiável que eu conheço de que a representação do usuário está funcionando ou não.