coastdigitalgroup/coastai-skills

Sistema de Design de Formulários

Propósito

A skill Sistema de Design de Formulários fornece uma metodologia para projetar a estrutura visual e espacial de formulários web. Enquanto a implementação técnica lida com o "como" e a otimização de crescimento lida com o "porquê", o sistema de design define o "o quê" e o "onde". Ela garante que os elementos do formulário — rótulos, campos de entrada, opções de escolha e ações — sejam organizados em uma interface previsível, acessível e de alta confiança, que reduz a carga cognitiva e previne erros do usuário.

Casos de Uso

• Projetar um kit de UI ou biblioteca de componentes de sistema de design para formulários.
• Estabelecer padrões visuais para interfaces complexas de entrada de dados em múltiplas etapas.
• Auditar formulários existentes em busca de inconsistência visual ou atrito espacial.
• Projetar layouts de formulários responsivos que mantenham a hierarquia em diferentes dispositivos.
• Padronizar padrões de visualização de erros e validação.

Quando NÃO Usar

• Barras de Pesquisa Genéricas: Campos de pesquisa simples e de entrada única raramente precisam do tratamento completo do sistema de design.
• Mídia Interativa Experimental: Onde a interação semelhante a um formulário é secundária a uma experiência narrativa ou artística.
• Microinterações de Baixo Risco: Como um "Curtir/Não Curtir" ou uma alternância simples sem entrada de dados acompanhante.

Entradas

1. Anatomia da Informação: Os pontos de dados específicos a serem coletados e seus relacionamentos.
2. Breakpoints de Dispositivo: Requisitos responsivos do responsive-grid-system.
3. Estilos da Marca: Escalas tipográficas, paletas de cores e tokens de espaçamento (do fluid-spacing-system).
4. Requisitos de Interação: Se o formulário requer validação em tempo real, uploads de arquivos ou seleções de escolha complexas.

Saídas

1. Especificação da Anatomia de Entrada: Definições visuais para rótulos, campos, texto de ajuda, ícones e mensagens de erro.
2. Blueprint de Layout: Regras espaciais para agrupamento de campos, alinhamento (superior vs. esquerdo) e posicionamento de ações.
3. Mapa de Componentes de Escolha: Definições de quando usar Botão de Rádio, Caixa de Seleção, Interruptor ou Seletor.
4. Matriz de Feedback e Estado: Tratamentos visuais para os estados de Hover, Foco, Desabilitado, Sucesso e Erro.

Fluxo de Trabalho

1. Definir a Anatomia do Componente

Estabelecer uma estrutura consistente para cada "Grupo de Campo". Um campo deve consistir em:

• O Rótulo: Texto claro e conciso identificando o campo.
• O Campo de Entrada: O contêiner interativo (texto, seletor, etc.).
• Texto de Ajuda/Instrucional: Orientação persistente (por exemplo, "A senha deve ter 8 caracteres").
• Mensagem de Erro: Feedback contextual que aparece apenas quando a validação falha.

2. Estabelecer Layout Espacial e Alinhamento

Determinar a relação entre rótulos e campos de entrada:

• Rótulos Alinhados ao Topo (Recomendado): Melhor para scannability e responsividade móvel.
• Rótulos Alinhados à Esquerda: Apenas para interfaces desktop com muitos dados, onde o espaço vertical é crítico.
• Agrupamento: Usar espaçamento lógico (por exemplo, --space-l) entre grupos e espaçamento menor (por exemplo, --space-s) dentro dos grupos.

3. Selecionar Padrões de Interação

Atribuir padrões de UI a tipos de dados:

• Escolhas Binárias: Usar Caixas de Seleção para "Sim/Não" ou seleção múltipla.
• Exclusividade Mútua: Usar Botões de Rádio para 2–5 opções; usar Seletor para 6+ opções.
• Alternâncias Imediatas: Usar Interruptores para configurações que entram em vigor imediatamente sem uma ação de "Enviar".

4. Projetar o Loop de Feedback

Criar uma hierarquia visual para validação:

• Estado de Foco: Usar um anel de alto contraste para indicar o campo ativo.
• Estado de Erro: Usar cor (geralmente vermelho), ícones e espessura de borda para sinalizar erros.
• Estado de Sucesso: Usar dicas sutis (como uma marca de verificação verde) para campos de alto risco (por exemplo, disponibilidade de nome de usuário).

5. Planejar Adaptações Responsivas

Mapear como o formulário se comporta em viewports menores:

• Empilhamento: Layouts de várias colunas em desktop devem ser empilhados em uma única coluna no celular.
• Alvos de Toque: Garantir que todas as zonas interativas (rádios, caixas de seleção, botões) tenham pelo menos 24x24px (mínimo WCAG 2.2 SC 2.5.8); 44x44px é preferido e deve ser o padrão para ações de envio primárias.

Regras de Decisão

• A Regra da Coluna Única: Usar um layout de coluna única para a maioria dos formulários para manter um caminho de varredura vertical claro e reduzir a fadiga de rastreamento ocular.
• Alinhamento de Rótulo: Padrão para rótulos alinhados ao topo. Eles reduzem o número de fixações oculares necessárias para processar o formulário.
• Placeholders vs. Rótulos: Nunca usar placeholders como rótulos. Os rótulos devem permanecer visíveis mesmo depois que o usuário começa a digitar.
• Hierarquia de Botões: A ação primária "Enviar" deve ser a mais visualmente proeminente. Ações secundárias (por exemplo, "Cancelar") devem ser links de texto ou botões de baixo contraste.
• Proximidade: Colocar texto de ajuda e mensagens de erro o mais próximo possível do campo de entrada (geralmente diretamente abaixo).

Restrições

• Acessibilidade: Os rótulos devem estar programaticamente vinculados aos campos de entrada (<label for> ou wrap). As taxas de contraste para texto e bordas devem atender ao WCAG AA (4.5:1 para texto, 3:1 para componentes de UI). As mensagens de erro devem estar programaticamente associadas ao seu campo de entrada via aria-describedby, e campos inválidos devem definir aria-invalid="true". Os indicadores de foco não devem estar ocultos atrás de cabeçalhos fixos, toasts ou sobreposições (WCAG 2.4.11 Foco Não Obscurecido).
• Responsividade: Os campos do formulário nunca devem transbordar seu contêiner ou ter larguras fixas que excedam viewports móveis.
• Hierarquia Visual: As mensagens de erro devem ser visualmente distintas do texto de ajuda para garantir que não sejam perdidas.

Padrões Comuns de Falha

• A Armadilha do "Placeholder como Rótulo": Usar placeholders em vez de rótulos, fazendo com que os usuários percam o contexto ao digitar.
• Colunas Esmagadoras: Usar layouts de várias colunas que confundem o caminho de varredura natural de cima para baixo do usuário.
• Erros Vagamente: Visualizar um erro apenas com cor (por exemplo, apenas tornar a borda vermelha) sem um ícone ou mensagem de texto.
• Alvos de Toque Pequenos: Projetar botões de rádio ou caixas de seleção muito pequenos para interação com o polegar em dispositivos móveis.
• O Foco "Invisível": Falhar em fornecer um anel de foco claro, tornando a navegação impossível para usuários de teclado.

Critérios de Validação

• Cada campo de entrada tem um rótulo persistente e visível.
• O formulário segue um caminho de varredura vertical lógico e de coluna única.
• Estados de erro usam uma combinação de cor, ícones e texto.
• Indicadores de foco são de alto contraste e claramente visíveis.
• Elementos interativos (campos de entrada, botões) atendem ao mínimo de alvo de toque de 24x24px do WCAG 2.2 (44x44px preferido).
• O layout transita suavemente para uma única coluna em viewports móveis.
• As ações primária, secundária e terciária têm uma hierarquia visual clara.