UX Research

UX Research — Discovery Qualitativo, Persona, Jornada e Teste de Usabilidade

Entende quem é o usuário e qual problema dele vale resolver, antes de qualquer spec ou tela. Sem esta etapa, o time desenha pela própria intuição — e o primeiro pilar do UX Design é "você não é o usuário" (Fabricio Teixeira, UX Design — Introdução e boas práticas, Casa do Código). Esta skill produz os artefatos de pesquisa que alimentam o PO (01) e o UI/UX (02).

Governanca Global

Esta skill segue GLOBAL.md, policies/execution.md, policies/handoffs.md, policies/token-efficiency.md, policies/source-driven.md, policies/verification-before-completion.md e policies/anti-ai-writing.md.

Gate anti-AI: personas, insights e relatórios são prosa que humanos do time vão ler. Rodar os padrões de policies/anti-ai-writing.md antes de entregar e oferecer /humanize como passe final. Persona com cara de gerador automático não engaja empatia — que é o ponto inteiro.

Gate de integridade da pesquisa: nenhum insight, número ou citação de usuário pode ser inventado. Persona e jornada só valem se forem destilados de pesquisa real (entrevista, observação, métrica). Persona sem pesquisa por trás é ficção decorativa — explicitar quando é hipótese (proto-persona) versus baseada em dado.

Referencias (carregar sob demanda)

• references/metodos-pesquisa.md — qualitativo vs quantitativo, recrutamento, roteiro de entrevista em profundidade, teste de usabilidade passo-a-passo, análise e síntese de insights, as 10 desculpas para não testar
• references/personas-jornada.md — template de persona, mapa de empatia, mapa de jornada (journey map), arquitetura de informação, card sorting, taxonomia, proposição de valor
• references/sintese-tematica.md — pipeline de 5 fases (familiarização → coding → temas → revisão → síntese) para quando 5+ sessões tornam o passo 4 padrão insuficiente

Carregar apenas a referência que o entregável pedido exige.

Quando Usar

• entender quem é o público-alvo antes de especificar uma feature ("para quem estamos construindo?")
• validar se um problema vale a pena ser resolvido antes de investir em build ("produto que ninguém usa")
• conduzir/roteirizar entrevista em profundidade ou focus group com usuários
• criar persona baseada em pesquisa real (não chutada)
• mapear a jornada do usuário (journey map) ou mapa de empatia
• planejar e rodar teste de usabilidade qualitativo (em protótipo, wireframe ou produto no ar)
• definir arquitetura de informação, taxonomia ou rótulos via card sorting
• escrever a proposição de valor de um produto novo antes da spec

Quando Nao Usar

• definir UI, wireframe, tokens, componentes, fluxo de tela → skill 02 (ui-ux-design). Research entrega o insight; 02 desenha a interface
• acessibilidade técnica (WCAG, ARIA, screen reader, contraste) → skill 22 (accessibility-specialist)
• benchmark visual de concorrentes, moodboard, tendências de design → skill 29 (design-intelligence). Aqui se faz análise competitiva funcional/de problema, não estética
• definir eventos, funil, métrica de produto, tracking plan (quantitativo de instrumentação) → skill 21 (data-analytics). Esta skill usa métricas como pista, mas não as instrumenta
• escrever user story, critério de aceitação, escopo, priorização formal → skill 01 (po-feature-spec). Research entrega persona+jornada+insight; 01 transforma em spec

Entradas Esperadas

• problema ou hipótese de produto a investigar
• contexto de negócio (objetivo, restrições, quem é o cliente)
• acesso a usuários reais (ou aproximação do perfil) para entrevista/teste
• material existente: métricas (Analytics, logs de busca), e-mails de suporte, atendimento, pesquisa anterior — fontes de pista para o research
• docs/repo-audit/current.md se o research é sobre produto existente

Saidas Esperadas

• insights sintetizados (3-7 bullets acionáveis por sessão — não relatório de 40 páginas)
• persona(s) baseada em pesquisa, com comportamento, necessidades, dores e motivações
• mapa de jornada e/ou mapa de empatia do fluxo investigado
• roteiro de entrevista ou plano de teste de usabilidade quando o pedido é conduzir pesquisa
• proposição de valor quando o produto é novo
• arquitetura de informação / taxonomia quando o pedido é organização de conteúdo
• handoff sinalizado para skill 01 (PO) e skill 02 (UI/UX)

Posicao no Pipeline

Problema  →  [UX Research 51]  →  PO Spec (01)  →  UI/UX (02)  →  Build (03/04)
             entende QUEM/PORQUÊ   define O QUÊ      define COMO

UX Research antecede o PO. Quando o problema já está claro e validado, pode-se pular direto para 01 — research não é etapa obrigatória de toda task, é etapa de toda task com incerteza sobre o usuário ou o problema.

Protocolo

1. Definir o problema de pesquisa (antes de qualquer método)

Whitney Hess, citada no livro: UX é definir o problema que precisa ser resolvido (o porquê), para quem (o quem) e o caminho para resolvê-lo (o como). Começar pelo porquê e pelo quem.

Antes de escolher método, responder:

• Que hipótese ou decisão esta pesquisa precisa informar?
• O que já sabemos (métricas, suporte, pesquisa anterior)? Research não começa do zero — métricas de site, palavras mais buscadas no campo de busca, e-mails de suporte e atendimento online já são pistas dos principais problemas
• Qual a decisão que muda dependendo do resultado? Se nenhuma, a pesquisa é teatro

2. Escolher o método pelo tipo de pergunta

Regra do livro: qualitativo busca insight, não estatística. Quantitativo dá o "o quê" e "quanto"; qualitativo dá o "por quê". Eles se complementam — métricas apontam onde dói, entrevista explica a dor. Detalhes de cada método em references/metodos-pesquisa.md.

3. Conduzir (entrevista ou teste)

• recrutamento: teste com 3-5 usuários do perfil. "Testar com 1 usuário já é infinitamente melhor que testar com 0." O perfil demográfico pode ser aproximado — o que importa é testar com pessoas que usariam o serviço
• ambiente: casual, não laboratório elaborado (intimida e enviesa). Pode ser remoto
• postura: o pesquisador não é profeta que sabe como as pessoas pensam — é investigador. Não direcionar, não enviesar, não "vender" a solução. Deixar o usuário verbalizar problemas e desconfortos
• contexto real importa: algumas ideias só surgem observando o usuário no contexto real de uso (ex.: o atalho de lanterna no app de leitura de medidor de gás surgiu de ver gente levando lanterna ao porão escuro)

Roteiro e passo-a-passo em references/metodos-pesquisa.md.

4. Sintetizar insights (leve, rápido)

Do livro: pesquisa não precisa de relatório formal tabulado. No caminho de volta da pesquisa, sair com 3 bullet points que resumem o aprendizado do dia. O benefício real do teste não é o relatório — é a exposição do time a usuários reais. Sintetizar para decisão, não para arquivo.

Para 5+ sessões: o "3 bullets no caminho de volta" tende a perder o que se repete entre participantes. Usar references/sintese-tematica.md (pipeline de 5 fases: familiarização → coding → temas → revisão → síntese) para agregar antes de destilar nos bullets finais.

5. Produzir o artefato (persona, jornada, AI, proposição de valor)

Conforme o pedido. Templates em references/personas-jornada.md. Todo artefato cita as fontes de pesquisa que o embasam.

Checkpoint: para cada afirmação do artefato ("usuários preferem X", "o maior atrito é Y"), apontar de qual entrevista/métrica/observação especificamente ela veio — se não conseguir apontar, é opinião do pesquisador vestida de dado, não insight de pesquisa. Reescrever ou remover a afirmação antes de entregar.

6. Gates + handoff

Rodar gate anti-AI e gate de integridade. Entregar para 01/02 com as fontes anexadas.

Heuristicas

• Você não é o usuário. Intuição é input válido, não o único. A pesquisa existe porque o time não consegue prever o que o usuário pensa/sente/deseja
• Comece pelo usuário, não pela tecnologia. "Comece com a experiência do usuário e depois defina a tecnologia usada" (Steve Jobs, citado no livro). O caso QR Code: febre entre empresas, ignorado pelos usuários — tecnologia que resolve problema que ninguém tinha
• Pesquisa contínua > pesquisa-evento. Não precisa ser etapa separada com CNPJ e prancheta. Pode ser uma manhã por semana conversando com usuários reais, custo diluído no projeto
• Teste cedo, falhe rápido. Teste em protótipo, wireframe, no verso do guardanapo. Quanto mais cedo, mais barato corrigir
• O que você não desenha também é design. Saber dizer não a features é parte do research — identificar briefing inflado e afunilar pela proposição de valor

Anti-Padroes

• Persona inventada (ficção decorativa): criar persona "Maria, 32, gosta de praticidade" sem nenhuma entrevista por trás. Persona sem pesquisa é hipótese — marcar como proto-persona e validar
• Pesquisa que não muda decisão nenhuma: rodar entrevista para confirmar o que o time já decidiu. Se o resultado não pode mudar o rumo, não é pesquisa, é justificativa
• Direcionar o usuário no teste: "você não achou esse botão lindo e fácil?" — pergunta enviesada invalida o dado. Pedir tarefa, observar, não sugerir
• Confundir o que o usuário diz com o que faz: em qualitativo é comum o usuário dizer uma coisa e fazer outra. Observar comportamento > coletar opinião declarada
• Superplanejar a pesquisa até nunca fazer: ensaiar demais o roteiro e nunca sair da mesa. 15 minutos combinando as regras do jogo e o resto é improvisação controlada
• Pular research e ir direto pro wireframe: desenhar interface (skill 02) sem saber para quem — inverte o pipeline
• Entrar no território da skill errada: definir ARIA/contraste (é 22), moodboard estético (é 29), tracking plan (é 21), user story formal (é 01)

Evidencia de Conclusao

• método escolhido coerente com a pergunta de pesquisa
• insights sintetizados em bullets acionáveis (não relatório inchado)
• artefato pedido (persona/jornada/AI/proposição) produzido e ancorado em fontes reais
• gates anti-AI e de integridade passados
• handoff para 01/02 sinalizado

Handoff

• PO Feature Spec (skill 01): recebe persona + jornada + insights + proposição de valor para escrever user stories e critérios de aceitação. Esta skill responde "para quem e por quê"; 01 responde "o quê"
• UI/UX Design (skill 02): recebe persona, mapa de jornada, arquitetura de informação e insights de usabilidade para desenhar fluxos e telas. 02 também recebe o resultado de testes de usabilidade para iterar a interface
• Data Analytics (skill 21): quando a pesquisa qualitativa aponta a necessidade de medir quantitativamente (validar com volume), 21 instrumenta os eventos
• Design Intelligence (skill 29): quando o research de problema indica necessidade de benchmark visual/estético dos concorrentes
• /humanize: passe final em persona, insights e relatório antes de circular no time

Integracao com Pipeline

• Orchestrator (09): roteia para cá no início de tasks com incerteza sobre usuário/problema (discovery), antes de invocar o PO (01). Para problema já validado, roteia direto para 01
• Context Manager (08): persistir personas e jornada para reuso entre features do mesmo produto — não re-pesquisar o mesmo público a cada feature
• Documenter (10): registrar personas e mapa de jornada como artefatos de produto reutilizáveis
• Repo Auditor (18): quando o research é sobre produto existente, consumir docs/repo-audit/current.md antes de explorar

Fonte

Conteúdo destilado de Fabricio Teixeira, UX Design — Introdução e boas práticas no Design da Experiência do Usuário (Casa do Código). Frameworks citados: disciplinas de UX (Dan Saffer), Kano Model (Noriaki Kano), estratégia dos cupcakes (Adaptive Path), pesquisa com usuários (Jared Spool / UIE).

O pipeline de síntese temática em references/sintese-tematica.md foi adaptado do método de análise temática de Braun & Clarke, via o pipeline de síntese de pesquisa qualitativa do projeto cookiy-ai/user-research-skill (MIT) — extraída apenas a metodologia de análise; nenhuma referência à plataforma de origem foi trazida.