Product Design Skills — Guia do Time

Bem-vindo ao ecossistema de skills de product design. Este repositório contém um pipeline completo para criação de produtos digitais — do discovery ao handoff — estruturado para uso com Claude (Sonnet 4.6 ou Opus 4.6) via claude.ai.

---

O que é este ecossistema

Um conjunto de 15 skills especializadas e 19 referências que transformam o Claude num assistente de product design estruturado, consistente e fundamentado em boas práticas. Cada skill cobre uma etapa específica do processo Double Diamond, carrega as referências certas para aquele momento e entrega outputs prontos para uso no Figma Make, FigJam, ou em qualquer LLM onde você querira refinar as entregas de cada uma das etapas.

O ecossistema não substitui o julgamento do designer — ele estrutura o processo, evita vieses comuns e garante que as perguntas certas sejam feitas antes de qualquer decisão.

---

Estrutura do repositório

product-design/
├── SKILL.md                    ← orquestrador — ponto de entrada único
├── skills/                     ← 15 skills especializadas
│   ├── problem-framing.md
│   ├── personas.md
│   ├── user-research.md
│   ├── competitive-analysis.md
│   ├── synthetic-users.md
│   ├── information-architecture.md
│   ├── design-critique.md
│   ├── user-flow.md
│   ├── wireframe.md
│   ├── ux-writing.md
│   ├── micro-interactions.md
│   ├── design-system.md
│   ├── usability-test-plan.md
│   ├── component-spec.md
│   └── design-documentation.md
└── references/                 ← 19 referências compartilhadas
    ├── accessibility.md
    ├── atomic-design.md
    ├── cialdini-persuasion.md
    ├── cognitive-biases.md
    ├── competitive-analysis.md
    ├── component-spec.md
    ├── design-systems.md
    ├── dont-make-me-think.md
    ├── information-architecture.md
    ├── innovators-dna.md
    ├── micro-interactions.md
    ├── nielsen-heuristics.md
    ├── nuds-nubank.md
    ├── personas.md
    ├── problem-framing.md
    ├── synthetic-users.md
    ├── user-research.md
    ├── ux-writing.md
    └── where-good-ideas-come-from.md

---

Como o orquestrador funciona

O arquivo SKILL.md é o ponto de entrada único do ecossistema. Ele funciona em três passos automáticos:

Passo 1 — Carrega as referências certas para o tipo de tarefa solicitada.

Passo 2 — Identifica o contexto do produto: fase, plataforma, design system, fidelidade esperada e restrições conhecidas.

Passo 3 — Roteia para a skill correta, garantindo que cada entrega use apenas o conhecimento relevante para aquele momento — sem sobrecarregar o contexto com informação desnecessária.

Você não precisa chamar as skills individualmente. Descreva o que precisa e o orquestrador faz o roteamento.

---

O pipeline no Double Diamond

As 15 skills cobrem as quatro fases do Double Diamond. Nem todo projeto precisa de todas as etapas — veja a seção "Modos de uso" abaixo.

╔══════════════════════════════════════════════════════════════╗
║  DESCOBRIR           │  DEFINIR                              ║
║                      │                                       ║
║  problem-framing ────┤                                       ║
║  personas            │  information-architecture             ║
║  user-research       │  design-critique                      ║
║  competitive-analysis│                                       ║
╠══════════════════════╪═══════════════════════════════════════╣
║  DESENVOLVER         │  ENTREGAR                             ║
║                      │                                       ║
║  user-flow           │  synthetic-users                      ║
║  wireframe           │  usability-test-plan                  ║
║  ux-writing          │  component-spec                       ║
║  micro-interactions  │  design-documentation                 ║
║  design-system       │                                       ║
╚══════════════════════╧═══════════════════════════════════════╝

A persona é o fio condutor de todo o pipeline — criada no discovery, ela é referenciada em todas as decisões até o handoff.

---

Modos de uso

Nem todo produto ou feature precisa percorrer o pipeline completo. Use o modo adequado ao contexto:

Modo 1 — Pipeline completo

Quando: produto novo do zero, mercado desconhecido, alto risco de errar o problema.

problem-framing → personas → user-research → competitive-analysis
→ synthetic-users → information-architecture → user-flow → wireframe
→ ux-writing → micro-interactions → design-system → design-critique
→ usability-test-plan → component-spec → design-documentation

Modo 2 — Discovery + Entrega

Quando: feature nova em produto existente com usuários já conhecidos. Personas e DS não precisam ser refeitos do zero.

problem-framing → user-research (focado) → synthetic-users
→ user-flow → wireframe → ux-writing → design-critique → component-spec

Modo 3 — Entrega direta

Quando: iteração em feature existente com problema bem definido.

wireframe → ux-writing → micro-interactions → design-critique → component-spec

Modo 4 — Pontual

Quando: ajuste cirúrgico em copy, animação ou componente isolado.

ux-writing
ou  micro-interactions
ou  component-spec

Regra para escolher o modo:

Se você consegue responder com confiança "quem é o usuário, qual é o problema real e por que essa solução resolve" — pode pular o discovery. Se qualquer uma dessas respostas for incerta, o discovery é necessário.

---

Como usar — passo a passo

1. Instale as skills no Claude

Copie a pasta product-design/ para o diretório de skills do seu ambiente Claude. A estrutura de pastas deve ser mantida intacta.

2. Faça o primeiro input

Para iniciar o pipeline completo, use o formato abaixo no problem-framing:

CONTEXTO DO PRODUTO
Setor/mercado: [ex: fintech, saúde, educação]
Estágio: [ideia nova / feature em produto existente / redesign]
Plataforma esperada: [mobile / web / ambos]

O QUE SABEMOS (fatos concretos)
- [dado observável, reclamação real, métrica, comportamento documentado]

O QUE ACREDITAMOS (hipóteses)
- [suposição sobre causa, usuário ou solução — marcada como hipótese]

QUEM ACREDITAMOS SER O USUÁRIO
- [contexto de vida: o que essa pessoa faz, não só quem ela é]

O QUE NÃO SABEMOS
- [gaps que você já reconhece — pode estar vazio]

RESTRIÇÕES CONHECIDAS
- [técnicas, de negócio, regulatórias, de prazo]

O que evitar no primeiro input:

❌ "Quero criar um app de finanças pessoais"
   → Isso é solução, não problema.

❌ "Os usuários precisam de um dashboard com gráficos automáticos"
   → Problema e solução misturados.

✅ "Autônomos relatam não saber se estão no lucro ou no prejuízo
    no fechamento do mês, mesmo usando planilhas. Acreditamos que
    o problema é falta de visibilidade em tempo real, mas não
    sabemos se é comportamental ou de ferramenta."

3. Encadeie outputs como inputs

Ao passar de uma skill para a próxima, use este formato:

SKILL: [nome da próxima skill]

CONTEXTO DO PRODUTO
[2–3 linhas sobre o produto, fase e plataforma]

INPUT DA ETAPA ANTERIOR ([nome da skill anterior])
[cole o output gerado — pode resumir se for longo,
 mas mantenha: persona, problema central e decisões tomadas]

TAREFA DESTA ETAPA
[o que você quer que esta skill entregue agora]

RESTRIÇÕES / DECISÕES JÁ TOMADAS
[o que não está em discussão — evita reabrir decisões validadas]

Dica: você não precisa colar o output completo de cada etapa — cole o resumo de decisões e a persona. Elas são o fio condutor que mantém todas as skills alinhadas ao longo do pipeline.

---

Qual modelo usar

Fase	Skill	Modelo recomendado
Discovery	problem-framing, personas, user-research	Opus 4.6
Discovery	competitive-analysis	Sonnet 4.6
Definição + Desenvolvimento	todas	Sonnet 4.6
Critique + Entrega	design-critique	Opus 4.6
Entrega	usability-test-plan, component-spec, design-documentation	Sonnet 4.6

Lógica: Opus onde a qualidade do raciocínio muda o resultado — discovery e critique são as fases onde uma inferência errada contamina tudo que vem depois. Sonnet para as fases onde a estrutura da skill já faz o trabalho pesado e a entrega é mais operacional.

---

As referências — o que cada uma cobre

As referências são a base de conhecimento compartilhada entre todas as skills. Elas não são lidas de uma vez — cada skill carrega apenas as relevantes para aquele momento.

Referência	O que cobre	Skills que usam
accessibility.md	WCAG, contraste, ARIA, foco, mobile	Todas
atomic-design.md	Hierarquia atoms → pages, nomenclatura	Todas
nielsen-heuristics.md	10 heurísticas com checklist por entregável	Todas
cognitive-biases.md	14 vieses por fase + protocolos de defesa	Discovery, critique
cialdini-persuasion.md	7 princípios com uso ético vs. dark pattern	Writing, flows, critique
dont-make-me-think.md	Usabilidade, carga cognitiva, teste de 5s	Dev, validação
innovators-dna.md	5 habilidades de descoberta + protocolos	Discovery, critique
where-good-ideas-come-from.md	7 padrões de inovação + condições	Discovery, dev
design-systems.md	Carbon, Spectrum, Material, NuDS comparados	Design system
nuds-nubank.md	Princípios e arquitetura do NuDS (público)	Fintech / mobile
information-architecture.md	Leis de IA, card sorting, padrões de nav	IA, wireframe
component-spec.md	Padrões de handoff, variantes vs. estados	Component spec
ux-writing.md	Princípios, padrões por componente, checklist	UX writing
micro-interactions.md	Timing, easing, padrões catalogados	Micro-interactions
personas.md	5 níveis de profundidade, modo hipótese/validado	Personas
problem-framing.md	Frameworks, HMW, mapa fato vs. hipótese	Problem framing
user-research.md	Métodos, roteiros, síntese de dados	User research
competitive-analysis.md	Frameworks de análise, benchmarks

---

Perguntas frequentes

Preciso usar o orquestrador ou posso chamar as skills diretamente? Você pode chamar as skills diretamente se souber exatamente qual precisa. O orquestrador é útil quando o contexto ainda está vago ou quando você quer que o sistema decida o melhor caminho.

O que faço se a skill pedir mais contexto? Forneça. Skills que pedem contexto estão protegendo a qualidade do output. Avançar sem contexto gera entregáveis que não servem ao produto.

Posso usar uma skill fora da sequência do pipeline? Sim. As skills são independentes. A sequência é uma recomendação para projetos completos — não uma obrigação para iterações pontuais.

Como atualizo as personas ao longo do projeto? Rode personas.md novamente com o modo "validado", usando os dados coletados no user-research como input. A persona atualizada substitui a especulativa e deve ser repassada como contexto para as skills seguintes.

Posso usar o pipeline para redesigns ou só para produtos novos? Para redesigns, comece pelo design-critique do produto atual, use os problemas identificados como input do problem-framing e siga o Modo 2 (Discovery + Entrega). Redesigns raramente precisam do pipeline completo.

---

Contribuindo

Para propor melhorias ou novas skills:

1. Identifique o gap com base em uso real — não em gaps imaginados
2. Verifique se o tema já está coberto em alguma skill existente
3. Se for uma referência nova, documente as fontes primárias utilizadas
4. Se for uma skill nova, siga o padrão de estrutura das skills existentes: frontmatter com name e description, seções de referências, contexto necessário, como estruturar, output esperado, exemplos bom/ruim e o que nunca fazer
5. Abra um PR com a justificativa do gap que a