Persona de Usuário

Personas baseadas em pesquisa exigem dados reais do usuário, não suposições internas. Os insumos da pesquisa: entrevistas com usuários (mínimo de 12 a 15 sessões por persona primária para atingir a saturação de insights — as entrevistas exploram seu trabalho, objetivos, frustrações e fluxos de trabalho atuais); análise de tickets de suporte (quais segmentos de usuários geram quais tipos de tickets revela seus pontos problemáticos melhor do que as pesquisas podem); dados de uso do produto (o agrupamento comportamental por padrão de uso de recursos identifica arquétipos de usuários distintos dentro do produto); e dados de atributos do cliente do CRM (tamanho da empresa, setor, distribuições de títulos de função). Product Ops sintetiza esses insumos em 2 a 4 personas primárias (mais de 4 geralmente indica proliferação de personas que torna a tomada de decisões mais difícil, não mais fácil). Cada persona inclui: um nome e função descritivos ("Alex, o Líder de Suporte de Linha de Frente em SaaS Série B"), seus objetivos de trabalho primários, suas principais frustrações com as ferramentas atuais, seus "watering holes" (onde buscam informações) e seu nível de sofisticação técnica.

As personas derivam valor do uso ativo nas decisões, não de existirem em um documento do Notion. Práticas de integração eficazes: Vinculação de histórias de usuário (cada história de usuário nomeia explicitamente a persona que ela atende: "Como Alex, o Líder de Suporte, eu quero..."); perguntas de revisão de design (em cada crítica de design: "Alex acharia isso intuitivo? Ela encontraria este cenário em seu fluxo de trabalho real?"); conversas de priorização (pergunte: "A quem isso serve — Alex ou Sam (a persona de Administrador de TI)? Qual segmento representa uma oportunidade maior?"); treinamento de agentes (agentes de suporte treinados no modelo de persona entendem o contexto da função de seu cliente, permitindo respostas mais empáticas e contextualmente relevantes do que o suporte genérico ao produto); desenvolvimento de mensagens GTM (campanhas de marketing são adaptadas a pontos problemáticos específicos da persona e "watering holes" em vez de descrições genéricas de ICP). Product Ops facilita revisões anuais de personas — a pesquisa de usuário muda à medida que o produto evolui e novos segmentos de clientes são visados, garantindo que as personas não se calcifiquem em um mito organizacional.

Um dos erros mais comuns no design de personas é mapear personas diretamente para cargos — "o VP de Suporte" versus "o Agente de Suporte". O problema: duas pessoas com o mesmo cargo (ambas são "Gerentes de Suporte") podem ter trabalhos, objetivos e necessidades de produto totalmente diferentes, dependendo do tamanho, estágio e filosofia de suporte de sua empresa. E, inversamente, um "Líder de Suporte" e um "Chefe de Operações de Cliente" podem ter objetivos e necessidades idênticos. As personas devem ser construídas em torno de objetivos e tarefas, não de títulos de organograma. A pergunta de teste: "Duas pessoas com títulos diferentes, mas que trabalham e pensam da mesma forma, se reconheceriam nesta persona?" Se sim, a persona é baseada em função, não em título — o que é mais robusto. Product Ops valida cada persona fazendo com que 5 a 10 clientes leiam a descrição da persona e perguntando: "Isso soa como você? Se não, o que é diferente?" — usando esse feedback para refinar até que cada persona seja imediatamente reconhecível pelas pessoas que ela representa.