claude-plugins/design-media/docs/SPECS/DRAFT-metodo-design-pro.md

DRAFT — Método Design Pro (camada de processo sobre Open Design)

Estado: Rascunho — origem: síntese Gemini de vídeos de páginas de alta qualidade (2026-07-22), adaptado ao stack Descomplicar. Aplica-se a: websites/landing pages, propostas comerciais, decks PPTX, banners, vídeo — qualquer artefacto de design.

0. Quem define o enquadramento (lição do teste WhatSMS, 22-07-2026)

O enquadramento — proposta de valor, posicionamento, o que se está a vender — pertence ao dono do produto. Nunca se deriva de análise do agente nem de diagnóstico de subagente.

No primeiro teste real deste método, o briefing enquadrou o WhatSMS como "responder a mensagens fora de horas" e pediu mock-ups de conversa. Resultado: uma landing page de bot de WhatsApp, quando o produto é um sistema de automação de contacto multicanal. O design estava competente; o enquadramento destruía o posicionamento.

Regras que daí resultam:

• Perguntar o posicionamento, não os acessórios. Cor e tipografia têm defaults; a proposta de valor não tem. Perguntar sobre a segunda, nunca presumi-la.
• "Está robótico" é um pedido de tom. Não é licença para reescrever posicionamento nem deitar fora copy existente. Preservar por omissão; mudar só o que foi pedido.
• Um diagnóstico que chama "AI slop" ao copy pode estar a apontar estilo, não substância. Nunca converter em mandato para substituir tudo.
• Briefing longo escrito sozinho é sinal de alarme, não de rigor. Quanto mais completo, mais eficazmente impede o motor de fazer as perguntas certas ao dono do produto. O Open Design pergunta — deixá-lo perguntar em vez de pré-responder tudo.

---

1. Contrato de Entrada (Zero Rascunhos Genéricos)

O pilar 1 (objectivo/posicionamento) recolhe-se com o dono do produto, nunca se deduz — ver secção 0.

Proibido gerar qualquer artefacto sem os 4 pilares explícitos ou deduzidos e confirmados:

1. Objectivo comercial — o que o utilizador/cliente deve sentir ou fazer no fim.
2. Layout narrativo — ordem exacta das secções/slides e comportamento de transição (scrollytelling em web; arco narrativo em decks/propostas).
3. Personalidade da marca — tom de voz, paleta intencional, espaçamento generoso (editorial feel). Fonte: design system no OD (Descomplicar ou cliente).
4. Público-alvo — perfil exacto que justifica a conversão.

Sem os 4 pilares → perguntar/deduzir e validar. Nunca template pré-feito como resposta.

2. Fluxo em 4 fases (mapeado às skills OD)

Fase	O quê	Skills OD
F1 Arquitectura	Grelha estrutural, tipografia, hierarquia de blocos (wireframe visual)	design-consultation, design-brief, design system
F2 Direcção artística	Implementação com micro-interacções, profundidade, impacto no início. Web: Next.js/TS + Tailwind + Framer Motion	creative-director, high-end-visual-design, frontend-design, gsap-*/emilkowalski-motion
F3 Variantes (Regra do Hero)	Secção crítica → 3-5 abordagens estruturais distintas (split / centered minimal / inset frame) para selecção antes de avançar	runs paralelos no OD, design-shotgun local; Google Stitch (stitch-loop, stitch-design-taste) para ideação rápida de variantes UI a partir de prompt/sketch/screenshot, com export Figma
F4 Auditoria adversarial	Validação crítica antes de entrega: consistência visual, tipos TS, acessibilidade, bundle, fluidez de animação, anti-AI-slop	design-review, impeccable-design-polish, pptx-html-fidelity-audit (decks)

3. Regra de Ouro da Modificação

• Macro (estrutura, layout, fluxo de páginas/secções) → resolvido e validado primeiro, ao nível global.
• Micro (espaçamentos, CTAs, detalhes) → só depois do macro aprovado. Nunca misturar os dois níveis na mesma iteração.

4. Pipeline Template-First (Envato & afins)

Um template profissional pode substituir F1+F2 — entra como ponto de partida, nunca como entrega directa.

4.1 Duas categorias de fonte

A. Templates com código/ficheiros (adaptáveis):

• Envato/ThemeForest (HTML, Next.js, Elementor kits, PPTX, vídeo) — licença cobre projectos de cliente
• UI8, Craftwork (UI kits), Relume (biblioteca Figma de secções), Framer/Webflow templates

B. Galerias de inspiração (extracção de DNA, nunca cópia):

• Dribbble, Pageflows, Recent.design, Landingfolio, Screensdesign
• Mobbin (fluxos de apps reais), Awwwards, Godly, Land-book, Lapa Ninja, SaaSFrame

4.2 Fluxo de adaptação (categoria A)

1. Seleccionar — escolher template alinhado com o layout narrativo do Contrato de Entrada (não o contrário).
2. Extrair — estrutura, grelha, tokens do template (brand-extract, image-to-code, web-clone, análise directa dos ficheiros).
3. Retheme — aplicar o design system do cliente/Descomplicar sobre a estrutura (theme-factory, redesign-existing-projects). Zero cores/fontes do template sobram.
4. Recontentar — copy e conteúdo reais segundo os 4 pilares; remover secções que não servem o objectivo comercial (cortar > acrescentar).
5. F4 Auditoria — igual ao fluxo normal; atenção extra a resíduos do template (placeholders, lorem ipsum, links demo, créditos).

4.3 Fluxo de referência (categoria B)

1. Capturar screenshots/URLs das referências escolhidas.
2. Extrair DNA: paleta, tipografia, grelha, ritmo de secções, padrões de interacção (design-researcher / visão OD).
3. DNA alimenta F1/F2 como direcção de arte — o artefacto é gerado de raiz com o nosso design system.

4.4 Biblioteca local de templates

• Templates descarregados (Envato) arquivados em pasta própria com metadados (fonte, licença, tags de uso) — candidata: Hub/04-Recursos/Design/templates/ — para reutilização entre projectos.
• Cada adaptação bem-sucedida regista o par template→resultado para acelerar selecções futuras.

5. Directrizes operacionais do agente no Open Design

Regras de execução para qualquer agente (Claude Code, Gemini CLI) a operar como motor no OD. As que repetem as secções 1–3 não se duplicam — referem-se.

1. Contrato de Entrada (secção 1) — os 4 pilares antes de qualquer geração.
2. DESIGN.md é o contrato da marca — todas as decisões visuais (tipografia, paleta, espaçamento, componentes) vêm do DESIGN.md activo do projecto OD, nunca de adivinhação. A skill define o quê; o DESIGN.md define como fica. Manter o DESIGN.md sincronizado com o design system (Descomplicar ou cliente).
3. Declarar a skill/formato certo — indicar explicitamente o tipo de saída (web-prototype, dashboard, mobile-app, deck) para activar a directriz OD correcta.
4. Macro → micro (secção 3, Regra de Ouro).
5. Variantes antes de fechar (secção 2, F3) — 3 a 5 variações radicalmente diferentes da secção crítica, resto igual; escolher direcção, só depois refinar.
6. Referências visuais concretas — screenshots via menção @ no chat OD ou ficheiros no projecto; nunca só descrição textual quando existe referência (liga à secção 4.3).
7. Ecossistema no mesmo projecto OD — landing + dashboard + app do mesmo cliente vivem no mesmo projecto, para herdar DESIGN.md, paleta e tipografia sem deriva (handoff contínuo).
8. Componentes externos adaptados, não recriados — gráficos animados, tabelas complexas: importar de bibliotecas (ex: 21st.dev, shadcn/ui) e adaptar ao design system, em vez de gerar do zero.
9. Acesso directo via MCP — usar mcp__open-design__* (get_artifact, write_file, search_files, start_run) para trabalhar sobre o código vivo do projecto; nunca depender de exports estáticos/zips. Passar project explícito (contexto activo expira ~5 min).
10. Código final limpo e exportável — HTML/CSS/JS determinístico, responsivo em iframe isolado, pronto para a equipa importar para React/Next.js/Vue sem limpeza. Nada de placeholders, estilos inline órfãos ou dependências fantasma. (Web em produção segue depois PROC-DEV-STANDARD no dev container.)

6. Integração futura (após aprovação do SPEC v3.0.0)

• Este método torna-se o corpo da skill design (router) — gate de contrato + orquestração das 4 fases.
• Para websites, avaliar skill dedicada create-pro-website (Next.js/TS/Tailwind/Framer Motion) que empacota o output OD no nosso stack (dev container, regra 48).
• Quality gate: nenhuma entrega sem F4 com score ≥7/10 (design-critic) e zero findings bloqueantes do design-review.