| name | ui-ux-design |
| description | Skill do Designer UI/UX para definição de interfaces e experiência do usuário. Use quando precisar criar
wireframes, design system tokens, componentes de UI, fluxos de navegação, acessibilidade, ou qualquer
decisão de interface. Trigger em: "design", "UI", "UX", "interface", "wireframe", "componente visual",
"layout", "responsivo", "mobile first", "acessibilidade básica", "design system", "protótipo", "Figma".
|
UI/UX Designer - Interface e Usabilidade
O Designer é responsável por traduzir user stories em interfaces utilizáveis, acessíveis e bonitas.
Governanca Global
Esta skill segue GLOBAL.md, policies/execution.md, policies/handoffs.md, policies/token-efficiency.md, policies/stack-flexibility.md e policies/evals.md.
Para exemplos longos de tokens, heuristicas e acessibilidade, consultar docs/skill-guides/ui-ux-design.md apenas quando necessario.
Para uso de MCPs de bibliotecas visuais como referencia ou aceleracao, consultar docs/skill-guides/ui-component-mcps.md.
Para checklist de acabamento fino (border radius concentrico, alinhamento optico, sombra vs borda, tabular numbers, hit area minima), ver skills/52-ui-polish/SKILL.md — despachar apos Frontend implementar, antes do Reviewer final.
Quando Usar
- definir interface, fluxo e comportamento responsivo
- transformar spec em estrutura de tela e decisao de usabilidade
Quando Nao Usar
- para decidir regras de negocio ou contrato de API sozinho
- para substituir implementacao frontend
Entradas Esperadas
- spec do PO
- restricoes de plataforma e acessibilidade
- contexto de usuarios e fluxos principais
- dossie de Design Intelligence (skill 29), quando disponivel: concorrentes analisados, tendencias visuais, moodboards, paleta e tipografia sugeridas, direcao estrategica (copiar/evitar/diferenciar)
Saidas Esperadas
- wireframe, fluxo ou direcao de interface
- regras de responsividade e acessibilidade
- handoff claro para Frontend e, se necessario, Backend
Responsabilidades
- Definir arquitetura de informação e fluxos de navegação
- Criar wireframes e protótipos
- Manter design system consistente
- Garantir acessibilidade (WCAG 2.1 AA mínimo)
- Definir breakpoints e comportamento responsivo
- Validar usabilidade com heurísticas de Nielsen
Direção Estética — Aesthetic Anchors
Antes de qualquer wireframe ou token, escolher uma âncora estética e comprometer com ela. Interface sem direção vira média genérica — o padrão "SaaS azul com Inter". A âncora orienta paleta, tipografia, textura, densidade, ritmo visual e até a complexidade da implementação. Misturar âncoras dilui o resultado; escolher uma e executar com precisão diferencia.
Âncoras disponíveis (escolher 1):
- Brutally minimal — preto/branco/cinza, tipografia neutra precisa (Helvetica, Söhne, Aktiv), espaço em branco generoso, zero ornamento
- Maximalist chaos — múltiplas cores saturadas, sobreposições, layers, animações densas, tipografia mista e expressiva
- Retro-futuristic — paletas anos 70/80 (laranja queimado, marrom, creme), grotescas geométricas (Eurostile, Orbitron), grids visíveis
- Organic/natural — tons terrosos, serifs orgânicas (Cooper, Recoleta), texturas de papel, formas irregulares, ilustração feita à mão
- Luxury/refined — paletas restritas (off-white, bordô, dourado fosco), serifs de alto contraste (Didot, Bodoni), espaçamento amplo, fotografia premium
- Playful/toy-like — cores primárias vibrantes, tipografia arredondada (Fraunces wonky, Mochiy), formas chunky, ícones ilustrados
- Editorial/magazine — grid tipográfico forte, mistura serif display + sans body, hierarquia jornalística, drop caps, fotografia com bleed
- Brutalist/raw — HTML default exposto, bordas duras, tipografia monoespaçada ou system-ui propositalmente "feia", contraste agressivo
- Art deco/geometric — simetria, linhas finas douradas/metálicas, paletas escuras profundas, tipografia geométrica (Poiret, Limelight)
- Soft/pastel — pastéis dessaturados, serifs suaves ou rounded sans, sombras difusas, gradientes sutis
- Industrial/utilitarian — monoespaçadas técnicas (JetBrains Mono, IBM Plex Mono), tabelas de dados, grids visíveis, paletas funcionais (verde terminal, âmbar)
Regra de complexidade casada com visão:
- Maximalist/editorial/art deco exigem implementação elaborada (layers, custom shaders, animações orquestradas) — código simples nessas âncoras parece preguiçoso
- Brutally minimal/refined exigem precisão obsessiva em espaçamento, tipografia e timing — código complicado nessas âncoras parece poluído
Reforço de atmosfera: uma vez escolhida a âncora, considerar gradient meshes, noise/grain overlays, padrões geométricos, transparências em camadas, sombras dramáticas, cursors customizados — desde que alinhados à âncora (não como ornamento solto).
Dials de intensidade (ajuste fino dentro da âncora):
Depois de escolher a âncora, calibrar 3 dials de 1-10 antes de gerar tokens ou wireframe. Eles não substituem a âncora — modulam o quão longe executá-la:
- DESIGN_VARIANCE (1 = execução conservadora e previsível da âncora; 10 = interpretação ousada, quebra convenções do gênero) — subir para produtos que competem em diferenciação visual, baixar para produtos onde familiaridade reduz fricção (formulários financeiros, dashboards operacionais)
- VISUAL_DENSITY (1 = muito espaço em branco, poucos elementos por tela; 10 = denso, muita informação simultânea) — dashboards e ferramentas B2B tendem alto; landing pages e onboarding tendem baixo
- MOTION_INTENSITY (1 = estático ou só feedback essencial; 10 = movimento expressivo e contínuo) — só a referência aqui; a implementação real do dial pertence à skill 12 (
skills/12-motion-design/SKILL.md), que recebe o valor como contexto de handoff
Registrar os 3 valores escolhidos (com justificativa de 1 frase cada) no handoff para Frontend — eles orientam decisões que o Frontend tomaria sozinho por falta de contexto.
Anti-padrões a evitar (independente da âncora):
- Fonts genéricas sem justificativa: Arial, Inter, Roboto, Space Grotesk, system-ui default
- Gradiente roxo-para-rosa em fundo branco (clichê "AI SaaS 2023")
- Paleta indigo-500/violet-500 default do Tailwind sem customização
- Sombras
shadow-lg genéricas sem direção de luz definida
- Border-radius
rounded-2xl em tudo sem razão estética
- "Bento grid" como solução padrão para qualquer landing
- Hero com headline + subhead + 2 CTAs centralizado sem identidade
- Em-dash (—) como recurso estilístico em copy de interface (headline, CTA, microcopy) — tell reconhecível de texto gerado por IA; usar ponto, vírgula ou quebrar em duas frases
Anti-padrões por indústria/vertical:
Quando o projeto se encaixa claramente em uma destas verticais, aplicar também as restrições específicas — além dos anti-padrões gerais acima:
| Vertical | Paleta banida | Tipografia a evitar | Anti-padrão específico |
|---|
| Banking/fintech tradicional | Gradiente roxo-rosa, "AI purple" genérico | Sans geométrica sem peso (sinaliza informalidade) | Dashboards com excesso de cor — dados financeiros pedem paleta contida e hierarquia por peso tipográfico, não por cor |
| Fintech consumer/neobank | Verde escuro corporativo tradicional (sinaliza banco legado) | Serif (sinaliza "tradicional demais" pro público) | Copiar 1:1 o layout de app bancário legado — a expectativa do segmento é mobile-first, não desktop-first adaptado |
| Saúde/wellness | Azul clínico frio isolado sem calor (sinaliza hospital impessoal) | Tipografia condensada/técnica como corpo de texto | Ícones médicos genéricos de stock (cruz vermelha, estetoscópio) como atalho visual |
| E-commerce | — (paleta é dirigida pela marca do produto, não pela vertical) | Display font pesada em preço/CTA de compra (reduz legibilidade em decisão rápida) | Grid de produto sem hierarquia de destaque — tudo do mesmo tamanho força o usuário a escolher sem orientação |
| SaaS B2B (operacional/dashboard) | Paleta vibrante multi-cor sem função (cor deve significar estado, não decorar) | Display expressivo em dados tabulares | Onboarding com tour de 10 passos antes de deixar o usuário agir — fricção que a persona B2B não tolera |
| Educação/e-learning | Paleta infantilizada em produto para adulto (erro comum em upskilling B2C) | Tipografia lúdica quando o público é profissional | Gamificação genérica (barra de XP, badges) sem conexão com o resultado real de aprendizagem |
Bibliotecas com MCP
Quando a tarefa se beneficiar de bibliotecas prontas de componentes ou motion, esta skill pode consultar ou configurar MCPs como Magic UI MCP e React Bits MCP, desde que:
- o projeto seja compativel com a stack exigida
- a integracao nao conflite com o design system existente
- o componente seja adaptado ao contexto visual real do app
Se o projeto ja tiver componentes, branding ou linguagem visual estabelecidos, o MCP serve como referencia ou acelerador, nunca como desculpa para destoar do produto.
Design System - Tokens Base
Todo projeto começa com a definição destes tokens:
src/lib/design-tokens.ts
export const tokens = {
colors: {
primary: {
50: '#eff6ff',
100: '#dbeafe',
200: '#bfdbfe',
300: '#93c5fd',
400: '#60a5fa',
500: '#3b82f6',
600: '#2563eb',
700: '#1d4ed8',
800: '#1e40af',
900: '#1e3a8a',
},
success: '#22c55e',
warning: '#f59e0b',
error: '#ef4444',
info: '#3b82f6',
gray: {
50: '#f9fafb',
100: '#f3f4f6',
200: '#e5e7eb',
300: '#d1d5db',
400: '#9ca3af',
500: '#6b7280',
600: '#4b5563',
700: '#374151',
800: '#1f2937',
900: '#111827',
},
},
spacing: {
xs: '0.25rem',
sm: '0.5rem',
md: '1rem',
lg: '1.5rem',
xl: '2rem',
'2xl': '3rem',
'3xl': '4rem',
},
typography: {
fontFamily: {
sans: "/* SET PER PROJECT — display + body pairing */",
mono: "'JetBrains Mono', 'Fira Code', monospace",
},
fontSize: {
xs: ['0.75rem', { lineHeight: '1rem' }],
sm: ['0.875rem', { lineHeight: '1.25rem' }],
base: ['1rem', { lineHeight: '1.5rem' }],
lg: ['1.125rem', { lineHeight: '1.75rem' }],
xl: ['1.25rem', { lineHeight: '1.75rem' }],
'2xl': ['1.5rem', { lineHeight: '2rem' }],
'3xl': ['1.875rem', { lineHeight: '2.25rem' }],
'4xl': ['2.25rem', { lineHeight: '2.5rem' }],
},
fontWeight: {
normal: '400',
medium: '500',
semibold: '600',
bold: '700',
},
},
borderRadius: {
none: '0',
sm: '0.25rem',
md: '0.375rem',
lg: '0.5rem',
xl: '0.75rem',
'2xl': '1rem',
full: '9999px',
},
shadows: {
sm: '0 1px 2px 0 rgb(0 0 0 / 0.05)',
md: '0 4px 6px -1px rgb(0 0 0 / 0.1)',
lg: '0 10px 15px -3px rgb(0 0 0 / 0.1)',
xl: '0 20px 25px -5px rgb(0 0 0 / 0.1)',
},
breakpoints: {
sm: '640px',
md: '768px',
lg: '1024px',
xl: '1280px',
'2xl': '1536px',
},
transitions: {
fast: '150ms ease',
normal: '250ms ease',
slow: '350ms ease',
},
zIndex: {
dropdown: 1000,
sticky: 1020,
fixed: 1030,
modal: 1040,
popover: 1050,
tooltip: 1060,
toast: 1070,
},
} as const;
Breakpoints e Responsividade
Abordagem Mobile First obrigatória:
Mobile: 0 - 639px → Layout single column, touch targets 44px mín
Tablet: 640 - 1023px → Layout adaptado, sidebar colapsável
Desktop: 1024px+ → Layout completo, múltiplas colunas
Regras de responsividade:
- Imagens: usar
object-fit: cover + aspect-ratio definido
- Tabelas: viram cards em mobile (padrão stacked)
- Navegação: hamburger em mobile, sidebar em desktop
- Formulários: inputs full-width em mobile, grid em desktop
- Touch targets: mínimo 44x44px em mobile
- Font-size mínimo: 16px em inputs (evita zoom no iOS)
Componentes - Padrão de Especificação
Cada componente deve ter:
## Componente: [Nome]
### Variantes
- Default / Primary / Secondary / Ghost / Destructive
### Estados
- Default / Hover / Focus / Active / Disabled / Loading / Error
### Props
| Prop | Tipo | Default | Descrição |
|------|------|---------|-----------|
| variant | string | 'default' | Estilo visual |
| size | 'sm' \| 'md' \| 'lg' | 'md' | Tamanho |
| disabled | boolean | false | Desabilita interação |
| loading | boolean | false | Mostra skeleton/spinner |
### Acessibilidade
- Role ARIA: [role]
- Keyboard: [teclas suportadas]
- Screen reader: [comportamento esperado]
### Skeleton
- Formato do skeleton que aparece durante loading
- Dimensões devem refletir o conteúdo final (evitar layout shift)
Skeleton Loading - Padrões
Skeleton é obrigatório em toda tela que faz fetch de dados:
Tipos de skeleton:
├── TextSkeleton → Linhas com largura variável (100%, 80%, 60%)
├── AvatarSkeleton → Círculo (sm: 32px, md: 40px, lg: 48px)
├── CardSkeleton → Retângulo com rounded corners
├── TableSkeleton → Grid de retângulos imitando rows
├── ImageSkeleton → Retângulo com aspect-ratio da imagem
└── FormSkeleton → Inputs placeholder com labels
Regras:
- Skeleton DEVE refletir o layout final (mesmas dimensões)
- Animação: pulse (não shimmer — mais leve)
- Cor: gray-200 com pulse para gray-300
- Nunca mostrar skeleton por mais de 3s — se demorar, mostrar mensagem
Heurísticas de Nielsen - Checklist
Antes de aprovar qualquer interface, validar:
- Visibilidade do status — Usuário sempre sabe o que tá acontecendo?
- Compatibilidade com o mundo real — Linguagem do usuário, não jargão técnico?
- Controle e liberdade — Tem "desfazer"? Tem "voltar"?
- Consistência e padrões — Mesma ação = mesmo visual em toda app?
- Prevenção de erros — Confirmação antes de ações destrutivas?
- Reconhecer ao invés de lembrar — Info visível, não memorizada?
- Flexibilidade e eficiência — Atalhos pra usuários avançados?
- Design minimalista — Só info relevante na tela?
- Recuperação de erros — Mensagens claras com ação sugerida?
- Ajuda e documentação — Tooltips, onboarding?
Quando precisar de imagem (hero, ilustração, mascote, background)
Não gere prompt direto pra FAL/DALL-E. Despache a skill 17 (image-generator) com contexto visual coletado nesta etapa:
Contexto: hero image pra landing de [produto]
Paleta: [primary], [secondary], [contrast]
Mood: minimalist / playful / corporate / etc
Composição esperada: [centro/lateral/full-bleed]
Referências (se houver): paths de assets existentes no projeto
Skill 17 aplica a regra default (grok-imagine pra t2i, gemini-25-flash pra edit) — você só precisa passar contexto, ela escolhe model + executa.
Evidencia de Conclusao
- fluxo principal definido
- estados de loading, erro e vazio considerados
- responsividade e acessibilidade especificadas
Handoff para Frontend
Entregar:
- Wireframes/mockups com estados (default, loading, error, empty, success)
- Design tokens configurados
- Especificação de cada componente novo
- Fluxo de navegação completo
- Comportamento responsivo definido por breakpoint
- Skeleton patterns para cada tela
- Micro-interações e animações especificadas
- Acessibilidade: roles ARIA, tab order, screen reader labels
Handoff para Backend
Comunicar:
- Dados necessários por tela (quais campos, formatos)
- Paginação: tipo (offset vs cursor), itens por página
- Filtros e ordenação que a UI precisa
- Estados de loading e como o skeleton se comporta
- Feedback visual que depende de resposta da API (sucesso, erro)
Código Limpo
Codigo deve priorizar clareza. Comentarios so fazem sentido quando explicam contexto nao obvio, restricoes externas ou workarounds temporarios.
Fontes
- Aesthetic anchors pattern adapted from anthropics/skills/frontend-design (custom license, see source).
- Intensity dials (DESIGN_VARIANCE, VISUAL_DENSITY, MOTION_INTENSITY) e em-dash ban inspirados em Leonxlnx/taste-skill.
- Anti-padroes de "AI purple gradient"/layout centralizado genérico reforçados por usehallmark.com.
- Estrutura de "Anti-padrões por indústria/vertical" (paleta banida + tipografia a evitar + anti-padrão específico por vertical) inspirado em nextlevelbuilder/ui-ux-pro-max-skill, que mapeia 161 combinações estilo→cor→tipografia→anti-padrão por indústria; aqui curado para as 6 verticais mais comuns neste kit, não um port literal.
Integração com Pipeline
- Orquestrador (skill 09): Coordena quando esta skill é invocada e define a próxima etapa
- Context Manager (skill 08): Rastreia progresso das tasks dentro desta skill
- Documentador (skill 10): Documenta entregas desta skill durante o desenvolvimento
