Direção de Design de Frontend

Use esta habilidade quando o trabalho não for apenas fazer a UI funcionar, mas torná-la proposital, polida e apropriada ao domínio do produto.

Fonte: recuperado do PR comunitário obsoleto #1659 por linus707.

Nota: O ECC intencionalmente não reempacota a habilidade canônica da Anthropic frontend-design. Instale-a a partir de anthropics/skills quando quiser a habilidade oficial upstream. Esta habilidade é o resgate de direção de design específico do ECC das orientações locais úteis do #1659.

Quando Usar

• O usuário pede para construir uma página web, aplicativo, dashboard, artefato, componente ou UI.
• O usuário pede para tornar uma interface mais polida, distinta, bonita ou menos genérica.
• A implementação precisa de escolhas de hierarquia visual, tipografia, cor, movimento, layout e interação.
• A UI atual funciona, mas parece plana, genérica, baseada em modelo ou inadequada para o público.

Direção de Design

Antes de codificar, escolha uma direção específica:

1. Propósito: qual tarefa a interface realiza?
2. Público: quem repete este fluxo de trabalho e o que eles precisam escanear primeiro?
3. Tom: utilitário, editorial, lúdico, industrial, refinado, técnico, maximalista, minimalista, denso, calmo, ou outra direção explícita.
4. Detalhe memorável: uma ideia de design que faz o resultado parecer intencional.
5. Restrições: framework, acessibilidade, desempenho, responsividade e sistema de design existente.

Combine a direção com o domínio. Uma ferramenta de operações SaaS geralmente deve ser densa, discreta e escaneável. Um portfólio, página de lançamento, jogo ou peça editorial pode ser mais expressivo. Não force uma composição de página de destino em uma ferramenta que necessita de uso diário repetido.

Orientações de Implementação

Contrato de evidência e estados de conteúdo

Antes da implementação, registre a superfície do produto, a tarefa do usuário, a ação primária, a hierarquia, os viewports de destino e a observação de referência por trás de cada escolha importante. Torne essas restrições verificáveis; uma paleta sozinha não é evidência. Use referências de produto locais quando a pesquisa externa for desnecessária ou indisponível.

Para cada estado relevante, registre seu gatilho, feedback visível e ação segura seguinte:

Registre um motivo quando um estado não se aplicar. Acesso de teste indisponível é um estado não testado, não um motivo para marcá-lo como não aplicável.

Construa a partir do contrato

• Construa a experiência utilizável real como a primeira tela, a menos que o usuário peça explicitamente por cópia de marketing.
• Use componentes de projeto existentes, tokens, bibliotecas de ícones e padrões de roteamento antes de introduzir um novo sistema visual.
• Use ativos visuais reais ou gerados quando a interface depender de imagens, produtos, lugares, pessoas, jogabilidade, gráficos ou mídia inspecionável.
• Prefira tipografia e espaçamento contextuais em vez de texto de herói genérico e superdimensionado.
• Mantenha as paletas multidimensionais: evite uma UI dominada por uma única família de tons.
• Use variáveis CSS ou tokens de design existentes para que a direção permaneça coerente entre os estados.
• Projete restrições responsivas explicitamente: grades, proporções, tamanhos mínimos/máximos, barras de ferramentas estáveis e controles de formato fixo não devem mudar quando rótulos ou estados de hover aparecerem.
• Use movimento com moderação, mas deliberadamente. Prefira transições de alto sinal que esclareçam o estado em vez de animação decorativa.
• Verifique o ajuste do texto no celular e no desktop. Rótulos longos devem quebrar ou redimensionar de forma limpa em vez de transbordar.

Antí-padrões

• Não use padrões gerados comuns por padrão: gradientes roxos, blobs decorativos, cards superdimensionados, cópia de herói vaga ou mídia atmosférica semelhante a estoque.
• Não adicione cards de UI dentro de outros cards.
• Não use um único estilo decorativo em todos os lugares quando o domínio exigir contenção.
• Não oculte o produto, ferramenta, objeto ou fluxo de trabalho principal atrás de seções genéricas de marketing.
• Não adicione uma nova dependência para um floreio de design, a menos que ele claramente se pague.
• Não descreva os recursos da UI dentro da UI quando os controles puderem falar por si mesmos.

Lista de Verificação de Revisão

• O primeiro viewport comunica imediatamente o produto, fluxo de trabalho ou objeto.

…