Blocos de Formulário

O Block Group não é um campo de input, mas é fundamental para organizar o formulário. Ele agrupa campos relacionados, cria colunas, controla espaçamento e aplica contexto visual.

• Deve ser usado para agrupar campos que pertencem à mesma lógica, como dados pessoais, morada ou informações da empresa.
• Permite criar secções com maior clareza visual, sobretudo em formulários com mais de cinco campos.
• Ajuda a controlar a densidade, evitando longas colunas de inputs sem respiração.

Campo indicado para informações curtas e objetivas, como nome, empresa, cidade, cargo ou referência interna.

• Machine name: identificador técnico do campo. Deve ser único, estável e coerente com a convenção global do formulário.
• Required: marca o campo como obrigatório.
• Placeholder: texto de apoio dentro do campo.
• Read only: apresenta o valor sem permitir edição.
• Min length / Max length: validações para limitar erros e normalizar dados.

Erros comuns incluem labels genéricas, machine names inconsistentes e uso de placeholders como instrução principal.

Campo projetado para textos longos, como mensagens, descrições, pedidos detalhados ou informações adicionais.

• Deve ser reservado a situações em que a resposta aberta acrescenta valor real.
• Textareas demasiado grandes podem intimidar; demasiado pequenas comprimem a escrita.
• Max length ajuda a controlar extensão e legibilidade das respostas.

Evite usá-lo quando a informação pode ser coletada de forma mais estruturada.

Campo específico para coleta de e-mail, com validação automática de formato.

• É frequentemente usado como ponto de contacto principal.
• Pode ser associado ao envio automático de notificações ao utilizador.
• Deve ser claramente identificado e, quando obrigatório, justificado pelo objetivo do formulário.

O machine name deve refletir esta função, como email ou contact_email.

Campo numérico utilizado para quantidades, valores, identificações curtas ou outros dados exclusivamente numéricos.

• É útil quando a resposta não deve aceitar texto livre.
• Pode ser problemático para telefones se o projeto exigir formatos internacionais ou símbolos.
• Quando usado para quantidades ou estimativas, deve ter label muito clara.

Diferencie campos realmente numéricos daqueles que apenas aparentam ser, mas exigem formatos mais flexíveis.

Campo para seleção de data, podendo também suportar hora ou intervalo, conforme necessário.

• É adequado para marcações, datas de evento, disponibilidade ou prazo pretendido.
• Reduz erro de preenchimento em comparação com texto livre.
• Deve ser testado em mobile para garantir usabilidade.

Se a data for opcional, a label deve indicar claramente se o preenchimento é obrigatório ou apenas recomendado.

Dropdown útil para segmentação, categorias, tipos de pedido ou seleção de país.

• Items: cada opção tem normalmente uma label visível e um value técnico.
• Multiple select: permite selecionar mais do que uma opção, mas aumenta a complexidade cognitiva.
• Placeholder inicial pode ajudar a orientar a escolha.

Evite seu uso quando houver poucas opções visíveis; nesse caso, radio buttons são mais adequados.

Conjunto de opções em que apenas uma alternativa pode ser selecionada.

• É particularmente útil quando existem duas a cinco opções e a decisão deve ser rápida.
• Pode ser apresentado na horizontal ou na vertical.
• A visibilidade imediata das opções reduz esforço comparado com um dropdown.

Prefira-o ao select quando a visibilidade das opções for relevante.

Componente utilizado para múltiplas escolhas independentes ou confirmações, como aceitação de termos.

• Pode ser usado em grupos de opções ou como item único de consentimento.
• Em contextos legais, o consentimento deve ser explícito e não deve vir pré-selecionado.
• Quando representa escolha múltipla, a organização visual das opções torna-se crucial.

Checkboxes com rotulagem inadequada geram ambiguidade e podem comprometer a experiência e a conformidade.

Campo que permite anexar arquivos à submissão.

• Mime types e extensões definem que tipos de ficheiro são aceites.
• Max file size evita submissões demasiado pesadas.
• Allow only one file controla se são permitidos múltiplos anexos.

Este campo tem impacto técnico maior que os demais e deve ser acompanhado de instruções claras.

Alguns campos são específicos para listas internas ou lógicas de sistema, como domínio, estado ou outras estruturas do projeto.

• Devem ser usados apenas quando existe uma necessidade funcional clara.
• Normalmente estão associados a taxonomias, listas geridas no sistema ou regras internas de categorização.
• A documentação funcional deve explicar sempre o objetivo do campo dentro do processo.

Campo invisível ao usuário, utilizado para tracking, contexto técnico, pré-preenchimento ou transporte de valores da URL.

• É especialmente útil em campanhas, automação e segmentação.
• Pode recolher valores de query parameters.
• Deve ser usado com cuidado para não introduzir lógica opaca difícil de manter.

Apesar de invisível, este campo pode ser essencial para reporting.

Alguns formulários incluem blocos de apoio ou mensagens para instruções, avisos ou contextualização.

• São úteis para dividir secções e reduzir ambiguidade.
• Devem ser usados com parcimónia para não competir com os campos.
• Fazem mais sentido em formulários longos ou com validação sensível.

Esses blocos têm função de suporte e não devem substituir uma arquitetura clara do formulário.

Botão responsável pelo envio final do formulário.

• O texto do botão influencia perceção e conversão.
• Labels como “Enviar pedido”, “Solicitar proposta” ou “Inscrever-se” tendem a ser mais eficazes do que termos genéricos.
• Pode ter estilos e alinhamentos definidos nas configurações do bloco.

O botão deve estar alinhado ao objetivo do formulário e ao estado de prontidão do usuário.