MÓDULO 4.3

🎭 Customização de personas

As 3 personas padrão (Engenheiro/Segurança/Ops) cobrem casos gerais. Mas você pode adicionar personas para domínios específicos: UX, Data, Mobile, Compliance.

1

🤔 Por que customizar

As 3 personas padrão são esqueleto comum. Funcionam pra 80% dos casos. Mas há domínios onde os 20% restantes são o que importa: UX, dados, compliance regulatório, mobile. Aí customizar persona dá lift de qualidade.

Sintoma típico: você roda 3 rodadas, plano sai aprovado, mas "falta alguma coisa". Esse algo é geralmente a perspectiva que o esqueleto não cobre.

2

🎨 Persona: UX/Designer

Pergunta principal:

"Esse plano respeita a experiência do usuário?"

Foco:

  • • Estados de loading, empty, erro
  • • Affordances claras (usuário sabe o que clicar?)
  • • Feedback visual em ações lentas
  • • Acessibilidade (WCAG, leitor de tela)
  • • Mobile-first ou desktop-first?
  • • Onboarding: como novo usuário descobre?

Use quando: feature tem UI complexa, fluxo crítico de conversão, app B2C com competição.

3

📊 Persona: Data/Analytics

Pergunta principal:

"Esse plano gera os dados certos pra decisão?"

Foco:

  • • Eventos rastreados são suficientes?
  • • Schema de eventos é versionado?
  • • Como medir sucesso quantitativamente?
  • • A/B test viável? Significância estatística?
  • • Pipeline de dados aguenta volume?
  • • Dados sensíveis são anonimizados?

Use quando: feature deve gerar insights, A/B test, dashboard, pipeline de ML.

4

📱 Persona: Mobile

Pergunta principal:

"Esse plano funciona em mobile real (offline, lento, bateria fraca)?"

Foco:

  • • Offline-first ou online-only?
  • • Sincronização quando volta online
  • • Tamanho de payload (rede ruim)
  • • Bateria (background tasks, polling)
  • • Push notifications: opt-in, deep link
  • • iOS vs Android: paridade?
  • • App store: privacy nutrition labels
5

🔄 Trocando a ordem

A ordem das personas importa. Engenheiro Sênior primeiro pega problemas estruturais que os outros dependem. Mas em alguns domínios você quer outra ordem.

# config.yaml — para feature de checkout
default_personas:
  - security    # PRIMEIRO: dinheiro envolve risco
  - engineer
  - ops

Em sistemas financeiros, security primeiro evita design errado depois descobrir que viola PCI-DSS. Reordenar economiza retrabalho.

6

🧩 Combinando personas (5+ rodadas)

# config.yaml — feature mobile B2C com analytics
default_personas:
  - engineer    # R1 - design
  - ux          # R2 - experiência
  - mobile      # R3 - mobile-specific
  - data        # R4 - tracking
  - security    # R5 - segurança
  - ops         # R6 - deploy

default_rounds: 6

Custo maior (~$3-4), mas pra features cross-time vale. Cada perspectiva pega problemas que as outras não veriam.

💡 Onde os prompts ficam

Os prompts das personas customizadas ficam em:

.claude/claudex/personas/
├── engineer.md
├── security.md
├── ops.md
├── ux.md           # custom
├── data.md         # custom
└── mobile.md       # custom

Você pode ajustar os prompts diretamente nos arquivos .md. Cada persona tem seu próprio sistema prompt.

📌 Resumo

✓
3 personas padrão — esqueleto comum, 80% dos casos.
✓
UX/Designer — UI complexa, fluxos críticos.
✓
Data/Analytics — A/B tests, dashboards, ML.
✓
Mobile — offline, bateria, paridade plataforma.
✓
Trocar ordem importa — security primeiro em fintech.
✓
Combinar 5-6 personas — para features cross-time.

Próximo Módulo:

4.4 — 🐛 Lendo o estado e debugando

← AnteriorPróximo →