ealmeidaandClaude Opus 4.8
04d9e50561
Licao do teste WhatSMS: o briefing enquadrou um sistema de automacao de contacto multicanal como bot de resposta a mensagens, e o resultado foi uma landing page de chatbot de WhatsApp. Nova seccao 0: perguntar o posicionamento e nunca presumi-lo; "esta robotico" pede tom e nao reescrita de posicionamento; briefing longo escrito sozinho impede o motor de fazer as perguntas certas. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
110 lines
8.5 KiB
Markdown
110 lines
8.5 KiB
Markdown
# 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.
|