Form Blocks

Block Group is not an input field, but it is essential for organising the form. It groups related fields, creates columns, controls spacing and applies visual context.

• It should be used to group fields that belong to the same logic, such as personal data, address or company information.
• It allows clearer visual sections, especially in forms with more than five fields.
• It helps control density, avoiding long columns of inputs without breathing space.

Field intended for short and objective information, such as name, company, city, role or internal reference.

• Machine name: technical field identifier. It should be unique, stable and coherent with the global form convention.
• Required: marks the field as mandatory.
• Placeholder: support text inside the field.
• Read only: displays the value without allowing editing.
• Min length / Max length: validations to limit errors and normalise data.

Common mistakes include generic labels, inconsistent machine names and using placeholders as the main instruction.

Field designed for long texts, such as messages, descriptions, detailed requests or additional information.

• It should be reserved for situations where an open response adds real value.
• Textareas that are too large can be intimidating; too small can compress writing.
• Max length helps control the length and readability of responses.

Avoid using it when the information can be collected in a more structured way.

Specific field for collecting email addresses, with automatic format validation.

• It is often used as the main contact point.
• It can be associated with automatic notifications sent to the user.
• It should be clearly identified and, when required, justified by the form’s objective.

The machine name should reflect this function, such as email or contact_email.

Numeric field used for quantities, values, short identifiers or other exclusively numeric data.

• It is useful when the response should not accept free text.
• It can be problematic for phone numbers if the project requires international formats or symbols.
• When used for quantities or estimates, it must have a very clear label.

Differentiate truly numeric fields from those that only seem numeric but require more flexible formats.

Field for date selection, which may also support time or range when needed.

• It is suitable for appointments, event dates, availability or desired deadlines.
• It reduces filling errors compared with free text.
• It should be tested on mobile to ensure usability.

If the date is optional, the label should clearly indicate whether filling it in is mandatory or only recommended.

Dropdown useful for segmentation, categories, request types or country selection.

• Items: each option usually has a visible label and a technical value.
• Multiple select: allows more than one option to be selected, but increases cognitive complexity.
• Placeholder can help guide the choice.

Avoid using it when there are only a few visible options; in that case, radio buttons are more suitable.

Set of options where only one alternative can be selected.

• It is particularly useful when there are two to five options and the decision should be quick.
• It can be presented horizontally or vertically.
• The immediate visibility of the options reduces effort compared with a dropdown.

Prefer it over select when the visibility of options is relevant.

Component used for independent multiple choices or confirmations, such as acceptance of terms.

• It can be used in groups of options or as a single consent item.
• In legal contexts, consent should be explicit and should not come pre-selected.
• When it represents multiple choice, the visual organisation of the options becomes crucial.

Checkboxes with poor labelling generate ambiguity and can compromise user experience and compliance.

Field that allows files to be attached to the submission.

• Mime types and extensions define which file types are accepted.
• Max file size avoids excessively heavy submissions.
• Allow only one file controls whether multiple attachments are allowed.

This field has a greater technical impact than the others and should be accompanied by clear instructions.

Some fields are specific to internal lists or system logic, such as domain, status or other project structures.

• They should only be used when there is a clear functional need.
• They are usually associated with taxonomies, system-managed lists or internal categorisation rules.
• Functional documentation should always explain the purpose of the field within the process.

Invisible field used for tracking, technical context, prefill or transport of URL values.

• It is especially useful in campaigns, automation and segmentation.
• It can collect values from query parameters.
• It should be used carefully so as not to introduce opaque logic that is difficult to maintain.

Although invisible, this field can be essential for reporting.

Some forms include support blocks or messages for instructions, warnings or contextualisation.

• They are useful for dividing sections and reducing ambiguity.
• They should be used sparingly so they do not compete with the fields.
• They make more sense in long forms or in forms with sensitive validation.

These blocks have a support role and should not replace a clear form architecture.

Button responsible for the final submission of the form.

• The button text influences perception and conversion.
• Labels such as “Send request”, “Request proposal” or “Register” tend to be more effective than generic terms.
• It can have styles and alignments defined in the block settings.

The button should be aligned with the objective of the form and the user’s state of readiness.