¿Cómo utilizar Formularios de contacto en el Editor de bloques de Waclis?
La sección Formularios de contacto del Editor de bloques de Waclis permite crear y personalizar estructuras para que los visitantes puedan ingresar información dentro de tu Página web.
Puedes utilizar formularios para recibir o solicitar datos como:
nombre;
empresa;
correo electrónico;
teléfono;
producto o servicio de interés;
asunto;
mensaje;
tipo de consulta;
selección entre diferentes opciones;
aceptación de determinadas condiciones cuando corresponda.
Dentro del Editor de bloques encontrarás diseños prediseñados en:
Secciones → Formularios de contacto
Además, dentro de Componentes encontrarás elementos específicos para construir formularios personalizados, como:
Form;
Input;
Text Area;
Select Input;
Checkbox;
Radio Button;
Html Button.
Esto permite partir de una estructura ya diseñada o construir un formulario desde cero.
Antes de comenzar: diseño y funcionamiento no son lo mismo
Esta es la aclaración más importante de este tutorial.
Un formulario puede verse perfectamente dentro de la Página web:
Nombre
[________________________]
[________________________]
Mensaje
[________________________]
[________________________]
[ ENVIAR ]
pero eso no significa automáticamente que al presionar:
ENVIAR
los datos:
lleguen a un correo;
se guarden;
generen una consulta;
se envíen a un sistema externo;
sean procesados correctamente.
¿Por qué?
Porque un formulario tiene al menos dos partes conceptuales:
Parte visual
Es lo que ve el visitante:
campos
labels
botón
colores
espacios
Parte funcional
Es lo que ocurre con los datos cuando se envían.
Por ejemplo:
Visitante completa formulario
↓
presiona Enviar
↓
¿A dónde viaja la información?
↓
¿Quién la procesa?
↓
¿Qué respuesta recibe el visitante?
El Editor de bloques permite trabajar sobre la estructura y presentación, pero antes de considerar terminado un formulario debes comprobar también su funcionamiento real mediante Ver página.
No publiques un formulario únicamente porque visualmente se ve correcto
Después de terminarlo realiza siempre una prueba real.
Por ejemplo:
Nombre:
Prueba Waclis
Correo:
correo de prueba
Mensaje:
Esta es una prueba del formulario.
Envía la consulta y verifica que ocurra exactamente lo esperado.
¿Qué es un Formulario de contacto?
Es una estructura destinada a recopilar información proporcionada voluntariamente por el visitante.
Por ejemplo:
CONTACTA CON NOSOTROS
Nombre
[________________________]
Correo electrónico
[________________________]
Teléfono
[________________________]
Mensaje
[________________________]
[________________________]
[ ENVIAR CONSULTA ]
¿Cuándo conviene utilizar un formulario?
Puede ser apropiado cuando necesitas que el visitante envíe información estructurada.
Por ejemplo:
Solicitar información
Solicitar presupuesto
Consultar por un servicio
Enviar una consulta general
Solicitar asesoramiento
Formulario vs botón de contacto
No siempre necesitas un formulario.
Si el único objetivo es:
Hablar con nuestro equipo
puede ser suficiente utilizar un CTA:
¿NECESITAS AYUDA?
[ CONTACTAR ]
que lleve al canal correspondiente.
Utiliza formulario cuando necesitas información antes de responder
Por ejemplo:
Nombre
Empresa
Servicio de interés
Mensaje
permite que el equipo reciba contexto previo.
No pidas información que no necesitas
Este es uno de los principios más importantes.
Un formulario como:
Nombre
Apellido
Empresa
Cargo
Dirección
Ciudad
País
Código postal
Teléfono
Celular
Sitio web
Cantidad de empleados
Sector
Mensaje
puede resultar excesivo para una simple consulta.
Para contacto general puede bastar
Por ejemplo:
Nombre
Correo electrónico
Mensaje
Para una consulta comercial
Podrías necesitar:
Nombre
Empresa
Correo electrónico
Teléfono
Producto o servicio de interés
Mensaje
Para solicitar presupuesto
Puede tener sentido solicitar:
Nombre
Empresa
Correo electrónico
Teléfono
Producto / servicio
Cantidad o alcance
Mensaje
si esos datos realmente ayudan a elaborar una respuesta.
Cada campo adicional tiene un costo para el visitante
Cuanto más extenso sea el formulario:
más esfuerzo requiere completarlo.
Por eso cada campo debería responder:
¿Realmente necesito este dato en esta etapa?
Formularios de contacto vs Newsletter
Una sección de Newsletter tiene un objetivo más específico:
suscripción
y suele solicitar pocos datos.
Por ejemplo:
[ SUSCRIBIRME ]
La veremos en el siguiente tutorial.
Formularios de contacto vs CTA
CTA
invita a realizar una acción.
Formulario
recopila información.
Puedes combinarlos.
Por ejemplo:
¿QUIERES SOLICITAR INFORMACIÓN?
Completa tus datos.
↓
[ FORMULARIO ]
¿Cómo agregar un Formulario de contacto?
Ingresa al Editor de bloques de la página o área editable donde quieras incorporarlo.
Después abre:
Secciones
y selecciona:
Formularios de contacto
Paso 1: elige una composición
Waclis mostrará las alternativas prediseñadas disponibles.
Elige principalmente según:
cantidad de campos;
distribución;
presencia de título;
existencia de información de contacto adicional;
ancho del formulario;
composición en una o dos columnas.
No necesitas conservar los textos ni campos de ejemplo si no son adecuados para tu necesidad.
Paso 2: agrega la sección
Selecciona el diseño.
Después podrás personalizar individualmente sus componentes.
Paso 3: utiliza Navigator para comprender la estructura
Un formulario puede tener una jerarquía conceptual como:
Section
└── Container
├── Heading
├── Paragraph
└── Form
├── Input
├── Input
├── Text Area
└── Html Button
O una estructura más compleja:
Section
└── Container
└── Grid Row
├── Grid Column
│ ├── Heading
│ └── información
│
└── Grid Column
└── Form
├── Input
├── Select Input
├── Text Area
└── Html Button
La estructura exacta dependerá del diseño utilizado.
¿Qué representa cada componente?
Form
Es el contenedor general de los campos.
Conceptualmente:
FORM
├── campo
├── campo
├── campo
└── botón
Input
Permite crear campos de entrada.
Puede utilizarse para información como:
Nombre
Correo electrónico
Teléfono
Empresa
dependiendo de cómo esté configurado.
Text Area
Se utiliza para contenidos más extensos.
Por ejemplo:
Cuéntanos qué necesitas
Mensaje
Descripción del proyecto
Select Input
Permite presentar una selección entre diferentes alternativas.
Conceptualmente:
Servicio de interés
[ Selecciona una opción ▼ ]
Puede ser útil cuando quieres clasificar la consulta.
Checkbox
Permite seleccionar o aceptar una opción.
Conceptualmente:
☐ Quiero recibir novedades
o una confirmación cuando corresponda.
Radio Button
Permite presentar opciones cuando quieres que el visitante seleccione entre alternativas.
Conceptualmente:
Tipo de cliente
○ Empresa
○ Particular
○ Distribuidor
cuando esa clasificación realmente sea necesaria.
Html Button
Puede utilizarse como botón dentro de la estructura.
En su configuración de Contenido puedes encontrar propiedades como:
Text;
Name;
Type;
Autofocus;
Disabled;
Id;
Class.
Importante con el Button
El hecho de colocar:
Text = Enviar
no define por sí solo qué ocurrirá con el formulario.
La lógica de procesamiento debe existir y comprobarse.
No reconstruyas la funcionalidad si el formulario ya funciona
Si partiste de una estructura que ya procesa correctamente la información:
conserva su estructura funcional.
Puedes modificar:
textos;
colores;
distribución;
Padding;
Typography;
sin eliminar arbitrariamente:
atributos;
Classes;
identificadores;
estructura del Form.
Paso 4: define el objetivo del formulario
Antes de editar campos decide:
¿Para qué quiero que el visitante complete este formulario?
Ejemplo: consulta general
Objetivo:
Enviar una consulta
Campos:
Nombre
Mensaje
Ejemplo: presupuesto
Objetivo:
Solicitar presupuesto
Campos:
Nombre
Empresa
Teléfono
Servicio
Mensaje
Ejemplo: asesoramiento
Objetivo:
Solicitar asesoramiento comercial
Campos:
Nombre
Empresa
Teléfono
Tema de interés
No mezcles varios objetivos innecesariamente
Por ejemplo:
Contáctanos / Suscríbete / Solicita presupuesto / Postúlate para trabajar
dentro del mismo Form puede resultar confuso.
Si existen objetivos muy diferentes
Puede ser mejor utilizar:
varios formularios;
distintas páginas;
un Select inicial;
diferentes CTA.
Paso 5: utiliza un Heading claro
Por ejemplo:
Contáctanos
Solicita información
Solicita tu presupuesto
Cuéntanos sobre tu proyecto
El título debería anticipar el objetivo
Evita:
Formulario
si puedes utilizar:
Solicita asesoramiento
Paso 6: agrega una introducción breve
Por ejemplo:
Completa tus datos y cuéntanos qué necesitas.
Otro ejemplo
Envíanos tu consulta y nuestro equipo podrá analizar tu solicitud.
Evita prometer tiempos si no son reales
Por ejemplo:
Te responderemos en 5 minutos.
si eso no puede garantizarse.
Puedes indicar qué información conviene incluir
Por ejemplo:
Para ayudarte mejor, indica el producto, cantidad aproximada y fecha requerida.
Esto puede mejorar la calidad de las consultas.
Paso 7: configura los campos
Analiza cada campo por separado.
Nombre
Generalmente es útil para personalizar la respuesta.
Por ejemplo:
Nombre
No siempre es necesario separar:
Nombre
Apellido
si puedes utilizar simplemente:
Nombre y apellido
y eso satisface tu necesidad.
Empresa
Puede ser relevante en formularios B2B.
Por ejemplo:
Empresa
No lo hagas obligatorio si también atiendes particulares y no es necesario para procesar la consulta.
Correo electrónico
Puede ser fundamental si la respuesta se realizará por email.
Utiliza una denominación clara:
Correo electrónico
Teléfono
Solicítalo cuando realmente sea útil.
Por ejemplo, si la consulta comercial normalmente necesita contacto telefónico.
No solicites teléfono y celular por separado si no existe una razón
Puede bastar:
Teléfono
Asunto
Puede ser útil en formularios generales.
Por ejemplo:
Asunto
Pero si ya tienes un Select de tipo de consulta, puede ser redundante.
Servicio o producto de interés
Puede utilizarse:
Servicio de interés
con Select Input.
Por ejemplo:
Selecciona una opción:
Diseño
Implementación
Soporte
Otro
cuando esas alternativas sean reales.
Mensaje
Utiliza Text Area.
Por ejemplo:
Cuéntanos qué necesitas
puede resultar más orientativo que:
Mensaje
Placeholder vs información permanente
Si utilizas textos de ayuda dentro de un campo, recuerda que el visitante puede dejar de verlos cuando comienza a escribir.
Cuando una indicación sea importante, es preferible que también exista como texto visible o etiqueta clara.
No dependas únicamente del placeholder para explicar qué debe completarse
Por ejemplo, en lugar de tener solamente:
[ Escribe tu correo aquí... ]
puede resultar más claro:
Correo electrónico
[ Escribe tu correo aquí... ]
Etiquetas claras
Cada campo debería poder comprenderse sin adivinar.
Ejemplo:
Nombre
[________________]
Evita
Dato 1
[________________]
Campos obligatorios
Solo marca como obligatorio aquello que realmente necesitas para procesar la solicitud.
Por ejemplo:
Nombre
Mensaje
pueden ser suficientes.
No hagas todos los campos obligatorios por costumbre
Esto puede aumentar la fricción.
Ejemplo
Si tienes:
Empresa
pero puedes responder igualmente a una persona sin empresa, quizá no necesite ser obligatorio.
Diferencia entre importante y obligatorio
Un dato puede ser útil pero no indispensable.
Indica claramente cuáles son obligatorios
Puedes utilizar una convención coherente.
Por ejemplo:
Nombre *
si tu implementación utiliza ese criterio.
Evita mezclar criterios
Por ejemplo:
Nombre *
Email (obligatorio)
Teléfono
Empresa requerida
puede resultar inconsistente.
Selecciones
Utiliza Select Input cuando existen alternativas claras.
Por ejemplo:
Motivo de consulta
[ Selecciona... ]
No utilices Select con 50 opciones si no es necesario
Una lista demasiado larga puede ser incómoda.
Si solo tienes dos alternativas
Quizá:
Radio Button
sea más claro.
Por ejemplo:
Tipo de proyecto
○ Nuevo
○ Existente
Checkbox
Puede utilizarse para una selección independiente.
Por ejemplo:
☐ Quiero recibir novedades
si corresponde y está correctamente implementado.
Consentimiento y políticas
Dependiendo del tipo de formulario, de los datos solicitados y de la normativa aplicable a tu actividad, puede ser necesario informar al visitante sobre:
tratamiento de datos;
política de privacidad;
comunicaciones comerciales;
condiciones aplicables.
La forma exacta dependerá del contexto legal y comercial de cada Página web.
No utilices una aceptación genérica sin saber qué significa
Por ejemplo:
☐ Acepto todo
es poco informativo.
Si necesitas una aceptación, el visitante debería poder comprender qué está aceptando.
Puedes enlazar una política
Cuando corresponda, puede utilizarse un texto como:
He leído la Política de privacidad
con el Link apropiado.
Suscripción comercial y consulta no son necesariamente lo mismo
Enviar una consulta no debería confundirse automáticamente con aceptar comunicaciones promocionales.
Si necesitas una suscripción adicional, puede representarse como una opción separada cuando corresponda.
Paso 8: configura el texto del Button
El Button debería describir la acción.
Consulta general
Enviar consulta
Presupuesto
Solicitar presupuesto
Contacto
Enviar mensaje
Asesoramiento
Solicitar asesoramiento
Evita
Aceptar
si no queda claro qué se acepta.
Evita
Continuar
si realmente se está enviando la información.
“Enviar” puede ser suficiente
Pero:
Enviar consulta
ofrece más contexto.
No cambies Type sin necesidad
En Html Button existe una propiedad:
Type
Si el formulario ya funciona correctamente, no modifiques propiedades funcionales únicamente para cambiar su apariencia.
Para cambiar visualmente el botón utiliza:
Estilo;
Classes;
CSS cuando corresponda.
Paso 9: distribuye los campos
Puedes utilizar una sola columna.
Por ejemplo:
Nombre
[_______________________]
[_______________________]
Teléfono
[_______________________]
Mensaje
[_______________________]
[_______________________]
[ ENVIAR ]
Es una estructura simple y clara
Especialmente en celular.
Dos columnas
En desktop puedes utilizar:
Nombre Empresa
[____________] [____________]
Email Teléfono
[____________] [____________]
Mensaje
[______________________________]
[______________________________]
[ ENVIAR ]
No pongas campos largos en columnas demasiado estrechas
Por ejemplo:
Descripción detallada del proyecto
funciona mejor con ancho completo.
Campos cortos pueden compartir fila
Por ejemplo:
Nombre | Teléfono
según el diseño.
Utiliza Grid Row si la composición depende de columnas
No acomodes los Inputs mediante márgenes manuales.
Responsive
Una estructura desktop:
[ Nombre ] [ Empresa ]
[ Email ] [ Teléfono ]
puede convertirse en móvil en:
[ Nombre ]
[ Empresa ]
[ Email ]
[ Teléfono ]
No mantengas dos campos demasiado estrechos en celular
Especialmente:
email;
nombres largos;
Select.
El ancho debe permitir ingresar información cómodamente
Formulario e información de contacto en dos columnas
Una composición habitual:
┌─────────────────────┬─────────────────────────┐
│ │ │
│ HABLEMOS │ Nombre │
│ │ [_______________] │
│ Email │ │
│ Teléfono │ Email │
│ Horarios │ [_______________] │
│ │ │
│ │ Mensaje │
│ │ [_______________] │
│ │ │
│ │ [ ENVIAR ] │
└─────────────────────┴─────────────────────────┘
Mobile
Puede transformarse en:
HABLEMOS
Datos de contacto
↓
Formulario
o al revés.
Decide qué información debe aparecer primero
En una página Contacto puede ser útil mostrar:
Formulario
primero si esa es la acción principal.
O información primero
Si necesitas explicar:
horarios;
alcance;
canales;
antes de la consulta.
Mantén una sola prioridad clara
Evita una columna con:
Teléfono
Formulario
Mapa
todos compitiendo con el mismo protagonismo.
Formulario y Mapa
Puedes complementar una página de contacto con:
Mapas y localización
cuando la ubicación física sea relevante.
Por ejemplo:
FORMULARIO
↓
MAPA
No necesitas incrustar el mapa dentro del propio Form
Puede ser una sección independiente.
Formulario y CTA
También puedes utilizar:
¿PREFIERES HABLAR CON NUESTRO EQUIPO?
[ CONTACTAR ]
como acción complementaria.
Evita demasiadas alternativas antes de que el visitante complete el Form
La página necesita jerarquía.
Anchura del Form
Un formulario demasiado ancho puede generar líneas visuales extensas.
Por ejemplo:
Nombre
[----------------------------------------------------------------]
puede no necesitar ocupar toda una pantalla de escritorio.
Boxed
Puede ser apropiado para mantener un ancho controlado.
Max Width
En personalizaciones avanzadas puede utilizarse para limitar el formulario.
Ejemplo conceptual
┌────────────────────────────┐
│ Nombre │
│ [________________________] │
│ │
│ Email │
│ [________________________] │
└────────────────────────────┘
Padding
Debe existir suficiente espacio dentro de la composición.
Evita que los campos queden pegados:
entre sí;
a los bordes;
al Heading.
Separación entre campos
Mantén una lógica consistente.
Por ejemplo:
Label
Input
espacio
Label
Input
No utilices una separación diferente en cada campo
La regularidad mejora la lectura.
Altura de Input
Los campos deberían resultar cómodos de utilizar.
No los hagas excesivamente pequeños.
Text Area
Necesita suficiente altura para escribir un mensaje.
Por ejemplo:
┌────────────────────────┐
│ │
│ │
│ │
└────────────────────────┘
en lugar de un área de una sola línea.
Pero tampoco necesita ocupar media página por defecto
Adapta la altura al tipo de información esperada.
Select
Comprueba que:
texto;
flecha;
valor seleccionado;
sean visibles correctamente.
Especialmente sobre fondos personalizados.
Checkbox y Radio
Necesitan suficiente separación entre:
control;
texto.
No reduzcas demasiado los controles
Deben seguir siendo fáciles de utilizar en celular.
Diseño de Inputs
Puedes personalizar:
fondo;
borde;
Border radius;
texto;
espacios.
Mantén coherencia
Por ejemplo:
Input 1 → Border radius 8
Input 2 → Border radius 8
Text Area → Border radius 8
Evita mezclar estilos sin intención
Nombre → borde negro
Email → fondo gris
Teléfono → borde rosa
Mensaje → sin borde
puede parecer un error.
Estado de foco
Cuando el visitante entra en un campo, es útil que pueda identificar visualmente dónde está escribiendo.
Si personalizas estilos avanzados, no elimines de manera indiscriminada todas las señales visuales de foco.
Contraste
Comprueba:
texto;
Labels;
borde;
fondo;
Button.
Placeholder demasiado claro
Si apenas puede leerse, deja de ser útil.
Pero no hagas que placeholder y contenido real parezcan idénticos si eso genera confusión
Fondo oscuro
Un formulario puede utilizar fondo oscuro:
████████████████████████
CONTACTA CON NOSOTROS
Nombre
[____________]
[____________]
[ ENVIAR ]
████████████████████████
En ese caso revisa especialmente:
Labels;
Input background;
texto ingresado;
Border;
Button.
No compruebes solamente el campo vacío
Escribe realmente dentro.
Un Input puede verse bien vacío y mostrar el texto ingresado con poco contraste.
Esto es importante
Prueba:
Nombre:
María González
y comprueba que el valor escrito se lea.
Lo mismo para Select
Comprueba el valor elegido.
Lo mismo para Text Area
Escribe varias líneas.
No diseñes solo el estado inicial
El usuario interactuará con el formulario.
Formularios y Linked styles
Varios Inputs pueden compartir Classes.
Esto suele ser conveniente.
Por ejemplo:
contact-input
puede controlar:
Height;
Border;
Border radius;
Padding.
Si Waclis muestra Linked styles
puede ser exactamente el comportamiento esperado.
Todos los campos deberían mantener una apariencia coherente.
No agregues un ID único a cada Input solamente para evitar estilos compartidos
Utiliza Classes cuando quieras aplicar la misma apariencia.
Excepciones
Por ejemplo:
contact-input
para todos,
y:
contact-input campo-destacado
para una excepción concreta.
IDs
Si utilizas identificadores personalizados, deben ser únicos dentro de la página.
Especialmente al clonar
Revisa si la copia conserva:
Id;
Name;
otras configuraciones relevantes.
No modifiques valores funcionales sin comprender cómo se utiliza el formulario.
Name y funcionamiento
El componente Html Button muestra una propiedad Name, y los elementos de formularios pueden contener distintos atributos utilizados por la estructura.
Si el formulario ya envía correctamente:
evita renombrar atributos funcionales únicamente para hacerlos “más bonitos”.
Para textos visibles utiliza los componentes y Labels correspondientes.
Clonar un campo
Si necesitas agregar un nuevo Input:
utiliza Navigator;
identifica la unidad completa del campo;
utiliza Clonar elemento;
modifica su contenido y configuración correspondiente.
Unidad completa del campo
Dependiendo de la estructura puede ser:
Wrapper
├── Label
└── Input
Si clonas solamente Input podrías dejar:
Nombre
[ Input ]
[ Input ]
sin Label para el segundo.
Clona Label + Input cuando corresponda
Utiliza Navigator para seleccionar el contenedor adecuado.
Ejemplo
Quieres pasar de:
Nombre
Mensaje
a:
Nombre
Empresa
Mensaje
Clona una unidad completa y cambia:
Label → Empresa
y la configuración correspondiente del campo.
No copies un campo funcional sin revisar sus atributos
La copia puede conservar configuraciones del Input original.
Si estás modificando una estructura que ya procesa información, comprueba que el nuevo campo sea reconocido correctamente por el mecanismo de envío.
Esta validación no es solamente visual
Después de agregar un campo nuevo:
realiza una prueba real del formulario.
Comprueba que ese dato también sea recibido o procesado correctamente.
Eliminar un campo
Selecciona la unidad completa.
Por ejemplo:
Label
+
Input
si quieres quitar ese dato.
No elimines solamente Input
dejando:
Teléfono
sin ningún campo debajo.
No elimines solamente Label
dejando un Input que el visitante no entiende.
Recuerda
Waclis no solicita confirmación antes de eliminar.
Utiliza:
Deshacer
si te equivocas.
Reorganizar campos
Puedes mover unidades completas.
Por ejemplo:
Antes:
Teléfono
Nombre
Mensaje
Después:
Nombre
Teléfono
Mensaje
Orden natural
Generalmente conviene comenzar por información simple.
Por ejemplo:
Nombre
↓
Contacto
↓
Clasificación
↓
Mensaje
No comiences con el campo más difícil
Por ejemplo:
Describe detalladamente tu proyecto
antes de pedir siquiera un nombre puede hacer que el formulario parezca más demandante.
Solicita información progresivamente
Un orden lógico puede facilitar completarlo.
Formularios largos
Si realmente necesitas muchos datos, puedes organizarlos mediante:
secciones;
títulos;
grupos visuales.
Ejemplo
DATOS DE CONTACTO
Nombre
Empresa
Teléfono
SOBRE TU PROYECTO
Servicio
Cantidad
Fecha estimada
Mensaje
No mezcles 12 campos sin agrupación
El visitante necesita entender la estructura.
Pero tampoco agregues demasiados títulos a un formulario corto
Para cuatro campos no necesitas cinco subtítulos.
Mensajes orientativos
Puedes agregar pequeñas ayudas.
Por ejemplo:
Cantidad aproximada
Indica una estimación. No necesita ser definitiva.
Esto puede reducir dudas
Especialmente en formularios técnicos o comerciales.
Evita explicaciones largas bajo cada campo
Si todos necesitan un párrafo, el formulario puede convertirse en un documento.
Campos opcionales
Puedes identificarlos cuando sea útil.
Por ejemplo:
Teléfono (opcional)
Esto puede reducir la sensación de obligación.
No necesitas marcar “opcional” en todos
Puede bastar con definir claramente los obligatorios.
Mantén una convención coherente.
Errores de validación
Si el formulario tiene validaciones funcionales, comprueba cómo se presentan.
Por ejemplo:
Correo electrónico inválido
debería ser visible y comprensible.
No diseñes solamente el estado exitoso
Prueba también:
campos vacíos;
email incorrecto;
opciones no seleccionadas;
cuando exista validación.
Importante
El comportamiento exacto de validación dependerá de cómo esté implementado el formulario.
No agregues mensajes visuales que no correspondan con una validación real.
Por ejemplo
No coloques permanentemente:
✓ Email correcto
si no existe una lógica que realmente compruebe ese dato.
Mensaje después del envío
También debes comprobar qué ocurre después de enviar.
El visitante necesita entender si la acción se completó.
Conceptualmente podría ser:
Consulta enviada correctamente.
o alguna respuesta equivalente definida por la implementación.
No inventes un mensaje de éxito solo mediante HTML estático
Si siempre aparece:
¡Tu mensaje fue enviado!
aunque el usuario todavía no haya hecho nada, generará confusión.
El mensaje debería formar parte del comportamiento real del formulario.
Prueba el flujo completo
No solo el Button.
Haz:
1. Completar.
2. Enviar.
3. Ver qué ocurre.
4. Verificar recepción.
¿Dónde llega la consulta?
Esto depende de la configuración funcional utilizada.
Antes de publicar debes saber:
quién recibe los datos;
dónde se reciben;
cómo se revisan;
si existe un sistema conectado.
No asumas que llegará a tu correo
Compruébalo.
Tampoco asumas que se guarda en Waclis
Comprueba el mecanismo real utilizado por ese formulario.
Si no sabes qué ocurre al enviar
No consideres finalizado el formulario.
Realiza una prueba o consulta la configuración correspondiente antes de publicarlo.
Formularios creados desde cero
Si utilizas:
Componentes → Form
y agregas Inputs manualmente, estás creando la estructura visual y HTML del formulario.
Eso no significa por sí solo que hayas definido un receptor o procesamiento de los datos.
Este punto debe quedar muy claro
Conceptualmente:
FORM VISUAL
≠
FORMULARIO FUNCIONAL AUTOMÁTICAMENTE
Puedes construir
Form
├── Input
├── Input
├── Text Area
└── Button
pero aún debes comprobar:
¿qué sucede al enviarlo?
Si necesitas una integración o procesamiento adicional
deberá existir una solución funcional adecuada al destino de esos datos.
No agregues código externo o JavaScript al azar únicamente para intentar “hacer funcionar” el formulario.
Si un formulario ya funciona, evita romperlo
Antes de modificar HTML avanzado guarda una referencia del estado original.
Especialmente no elimines
Classes que no reconoces;
atributos;
contenedores;
elementos funcionales;
sin entender su propósito.
Editar HTML
Puedes utilizar:
Editar código HTML <>
para una estructura seleccionada cuando realmente necesites una modificación avanzada.
Pero los formularios pueden depender de detalles funcionales.
No necesitas HTML para
cambiar texto;
colores;
Padding;
Border radius;
orden visual básico.
Utiliza primero las herramientas visuales.
Code editor general
Tampoco necesitas utilizar el Code editor global para personalizaciones habituales.
No modifiques scripts o recursos relacionados con formularios si no tienes una necesidad concreta.
JavaScript
No agregues JavaScript solamente para:
cambiar color;
agregar Border;
aumentar Padding.
Utiliza CSS.
Si necesitas comportamiento funcional
primero identifica exactamente:
qué debe ocurrir;
qué mecanismo ya existe;
qué información se necesita procesar.
Formularios y seguridad
No agregues campos para solicitar información sensible que no sea necesaria para la finalidad del formulario.
Por ejemplo, evita pedir datos excesivos simplemente porque puedes crear un Input.
Un formulario de contacto debería pedir información proporcional a su objetivo
Nunca utilices un formulario común para solicitar credenciales
No pidas al visitante:
contraseñas
códigos de acceso
tokens
mediante un formulario general de contacto salvo que exista un flujo específicamente diseñado y seguro para ello.
Cuanto menos dato innecesario recojas, más simple es también la experiencia
Formulario en Home
Puede utilizarse cerca del final.
Por ejemplo:
Servicios
↓
Testimonios
↓
FAQ
↓
Formulario
Pero una Home no necesita necesariamente un formulario completo
Puede utilizar:
[ CONTACTAR ]
y dirigir a una página específica.
Formulario en Contacto
Es uno de los usos más naturales.
Por ejemplo:
CONTACTO
Información
+
Formulario
+
Mapa
Formulario en Servicios
Puede utilizarse al final:
Servicio
↓
Beneficios
↓
Proceso
↓
Formulario de consulta
Formulario en una landing page
Puede representar la conversión principal.
Por ejemplo:
Propuesta
↓
Beneficios
↓
Testimonios
↓
FAQ
↓
SOLICITA INFORMACIÓN
[ FORMULARIO ]
En ese caso reduce distracciones
Si la acción principal es completar el Form, evita colocar junto a él cinco CTA alternativos.
Formulario de presupuesto
Ejemplo:
SOLICITA TU PRESUPUESTO
Nombre
[________________]
Empresa
[________________]
Correo electrónico
[________________]
Teléfono
[________________]
Producto o servicio
[ Selecciona ▼ ]
Cuéntanos qué necesitas
[________________________]
[________________________]
[ SOLICITAR PRESUPUESTO ]
No prometas que el formulario calcula un presupuesto automáticamente
si en realidad solo envía una solicitud.
Utiliza:
Solicitar presupuesto
en lugar de:
Obtener presupuesto instantáneo
si eso no ocurre realmente.
Formulario de contacto simple
CONTACTA CON NOSOTROS
Nombre
[________________]
[________________]
Mensaje
[________________]
[________________]
[ ENVIAR CONSULTA ]
Puede ser suficiente para muchos casos.
Formulario B2B
HABLEMOS DE TU PROYECTO
Nombre
Empresa
Cargo
Teléfono
Servicio
Mensaje
Pero revisa si realmente necesitas:
Cargo
antes de mantenerlo.
Formulario de soporte
Si se utiliza una estructura de formulario para asistencia, puede ser útil pedir:
Nombre
Tema
Descripción
pero no intentes reemplazar un sistema de soporte completo con un Form visual si existen procesos específicos para atención.
Upload de archivos
No afirmes que un formulario puede recibir archivos únicamente porque necesitas esa funcionalidad.
Si la composición no contiene un componente y procesamiento específico para archivos, no inventes un Input de carga esperando que funcione automáticamente.
El funcionamiento debe existir realmente
Diseño responsive
Los formularios son especialmente importantes en móvil.
Muchas consultas se realizarán desde pantallas pequeñas.
Comprueba el Form escribiendo desde una vista móvil
No basta con observarlo.
Prueba:
Input;
Select;
Checkbox;
Radio;
Text Area;
Button.
Evita formularios demasiado anchos
En celular deben ocupar un ancho cómodo sin salirse del viewport.
Evita Padding lateral excesivo
Por ejemplo:
pantalla 360 px
-
80 px izquierda
-
80 px derecha
dejaría muy poco espacio para los Inputs.
Ajusta espacios responsive
Button móvil
Debe ser cómodo de pulsar.
En algunos diseños puede resultar apropiado que utilice todo o gran parte del ancho.
Ejemplo
[ ENVIAR CONSULTA ]
No es obligatorio ancho completo
pero evita un control demasiado pequeño.
Select móvil
Comprueba que la opción completa pueda leerse.
Labels largos
Por ejemplo:
¿Sobre cuál de nuestros servicios te gustaría recibir más información?
puede ocupar varias líneas.
Esto es válido, pero necesita suficiente separación.
Text Area móvil
Debe permitir escribir cómodamente varias líneas.
Checkbox móvil
Asegúrate de que el texto no quede comprimido en una columna muy estrecha al lado del cuadro.
Dos columnas deben convertirse cuando corresponda
Desktop:
[ Nombre ] [ Empresa ]
Mobile:
[ Nombre ]
[ Empresa ]
No reduzcas el Font size de Inputs solo para mantener dos columnas
Reorganiza la estructura.
Formulario Full vs Boxed
Generalmente un Form contenido dentro de:
Boxed
puede ofrecer una lectura cómoda.
Full puede ser útil para el fondo
Por ejemplo:
████████████████████████████████████
CONTACTA CON NOSOTROS
[ FORM ]
████████████████████████████████████
mientras el Form permanece dentro de un ancho controlado.
Fondo de Section
Puedes utilizar:
blanco;
gris;
color de marca;
imagen.
Fondo con imagen
Si colocas Form sobre una fotografía:
revisa especialmente la legibilidad.
Puede resultar necesario:
Card de fondo sólido;
Overlay;
contraste.
Ejemplo
[ FOTO DE FONDO ]
┌──────────────────────────────┐
│ FORMULARIO CON FONDO │
│ │
│ Nombre │
│ [____________________] │
└──────────────────────────────┘
Esto puede facilitar la lectura.
No coloques Inputs transparentes sobre una fotografía compleja sin comprobar su legibilidad
Border radius
Puedes aplicar una lógica consistente a:
Inputs;
Select;
Text Area;
Button;
Card.
Por ejemplo
Inputs → 8 px
Button → 8 px
No es obligatorio que todo tenga exactamente el mismo radius
pero debería existir coherencia visual.
CSS personalizado
En personalizaciones avanzadas puedes utilizar Classes como:
contacto-section
contacto-form
contacto-field
contacto-input
contacto-textarea
contacto-button
Ejemplo
.contacto-section .contacto-input,
.contacto-section .contacto-textarea {
width: 100%;
border-radius: 8px;
}
Espaciado
.contacto-section .contacto-field {
margin-bottom: 16px;
}
cuando realmente sea necesario.
Evita
input {
border-radius: 8px;
}
si solo quieres modificar el formulario de esta sección.
Puede afectar:
buscadores;
login;
otros formularios;
otros Inputs de la Página web.
Utiliza scope
Por ejemplo:
.contacto-section input {
}
es más localizado.
Pero aún mejor
utiliza una Class específica cuando tengas control sobre ella.
No alteres propiedades funcionales mediante CSS
CSS debe utilizarse principalmente para la presentación.
Hover del Button
Puedes configurarlo.
Por ejemplo:
.contacto-section .contacto-button {
transition: transform .2s ease;
}
.contacto-section .contacto-button:hover {
transform: translateY(-2px);
}
si el efecto corresponde al diseño.
No necesitas Hover sobre cada Input
El estado más importante para campos es que el usuario comprenda:
cuál está activo;
qué debe escribir.
Animaciones
Puedes utilizar:
Avanzado → Animate on scroll
sobre:
Section;
formulario completo.
Evita animar cada Input individualmente
Un Form de seis campos no necesita seis animaciones diferentes.
La interacción ya requiere suficiente atención
Mantén la interfaz estable.
Validación real después de modificar estilos
Después de cambiar CSS prueba nuevamente:
escribir;
seleccionar;
enviar.
Un cambio visual puede afectar accidentalmente
visibilidad;
tamaño;
Button;
controles.
¿Qué hacer si un Input se ve diferente a los demás?
Comprueba:
Class;
Type;
Estilo;
Linked styles.
Si debería compartir diseño
añade o conserva la Class correspondiente.
¿Qué hacer si cambio un Input y cambian todos?
Probablemente comparten estilo.
Puede ser exactamente lo que quieres.
¿Qué hacer si quiero destacar un único campo?
Utiliza una Class adicional.
Por ejemplo:
contacto-input campo-principal
si realmente existe una razón.
¿Qué hacer si el formulario no envía?
No empieces modificando colores o CSS.
Primero determina:
¿el Form tenía funcionalidad anteriormente?
¿dejaste la estructura intacta?
¿modificaste HTML?
¿modificaste atributos o Classes?
¿el Button está configurado correctamente dentro de la estructura?
¿existe realmente un mecanismo de procesamiento?
¿la consulta llega al destino esperado?
Si nunca funcionó
Puede tratarse de una estructura visual sin procesamiento configurado.
No asumas que agregar JavaScript al azar resolverá el problema.
Si funcionaba y dejó de hacerlo
Utiliza:
Deshacer
si el cambio fue reciente.
Después compara la estructura con el estado anterior.
¿Qué hacer si el Button no hace nada?
Comprueba:
que estés probando mediante Ver página;
estructura del Form;
tipo y ubicación del Button;
configuración funcional existente;
cambios HTML realizados.
No concluyas que el problema es el Button únicamente por verlo correctamente
¿Qué hacer si la consulta se envía pero no llega al destino esperado?
Eso pertenece a la parte funcional del flujo.
Debes revisar la configuración del receptor o procesamiento utilizado por ese formulario.
No intentes resolver un destino de datos mediante CSS.
¿Qué hacer si el nuevo campo no aparece en la información recibida?
Esto es muy importante.
Aunque visualmente:
Empresa
[ Empresa Ejemplo ]
aparezca en el formulario, el mecanismo que procesa los datos debe contemplar ese campo.
Revisa la integración funcional antes de publicar el nuevo campo.
¿Qué hacer si el campo se ve pero no permite escribir?
Revisa:
Disabled;
estructura;
elemento seleccionado;
estilos que puedan bloquear interacción.
En Html Button existe una opción Disabled; distintos componentes también pueden contener configuraciones que afectan su comportamiento.
No actives estados de deshabilitado sin intención.
¿Qué hacer si el Button aparece deshabilitado?
Selecciona el elemento y revisa sus propiedades.
Comprueba también si existe lógica funcional que lo controla.
¿Qué hacer si los campos se salen de la pantalla?
Revisa:
Width;
Min Width;
columnas;
Padding;
Margin.
No ocultes el overflow para esconder los Inputs.
¿Qué hacer si el formulario genera scroll horizontal?
Identifica el campo que desborda.
Puede deberse a:
Width fijo;
Grid;
Margin;
Select;
Button largo.
Evita la solución global
body {
overflow-x: hidden;
}
sin determinar la causa.
¿Qué hacer si el Text Area es demasiado pequeño?
Ajusta:
Height;
Min Height;
según la cantidad de texto esperada.
¿Qué hacer si el Text Area es enorme?
Reduce su altura inicial, siempre que siga siendo cómodo.
¿Qué hacer si el Button queda muy lejos del último campo?
Revisa:
Margin;
Padding;
wrappers vacíos;
elementos eliminados incorrectamente.
¿Qué hacer si eliminas un campo y queda un hueco?
Revisa su contenedor.
Tal vez eliminaste solamente:
Input;
y no:
Grid Column;
wrapper;
Label.
Utiliza Navigator.
¿Qué hacer si quieres pasar de dos columnas a una?
Selecciona Grid Row y ajusta las columnas.
No necesitas reconstruir todo el Form.
¿Qué hacer si móvil sigue en dos columnas?
Comprueba los tamaños responsive reales de Grid Row.
La vista móvil del toolbar solamente previsualiza.
¿Qué hacer si el Button ocupa todo el ancho y no quieres?
Revisa:
Width;
Display;
Classes.
¿Qué hacer si quieres ancho completo solo en móvil?
Puedes utilizar una configuración responsive o CSS localizado cuando sea necesario.
IA para diseñar la estructura de un Form
ChatGPT, Claude o Gemini pueden ayudarte a decidir qué campos necesitas.
Por ejemplo:
Necesito un formulario de contacto para una empresa que ofrece [servicio].
Objetivo:
recibir solicitudes de presupuesto.
Actualmente pensamos pedir:
- Nombre.
- Apellido.
- Empresa.
- Cargo.
- Email.
- Teléfono.
- Ciudad.
- Servicio.
- Presupuesto estimado.
- Fecha.
- Mensaje.
Analiza cuáles datos son realmente necesarios para una primera consulta y cuáles podrían eliminarse para reducir fricción.
No inventes procesos internos.
No escribas código.
IA para organizar campos
Necesito organizar estos campos en un formulario:
[lista]
Propón:
- orden;
- cuáles pueden compartir fila en desktop;
- cuáles deberían ocupar todo el ancho;
- cómo apilarlos en celular.
El formulario se construirá con Grid Row y Grid Columns en Waclis.
No generes CSS todavía.
IA para redactar Labels
Tengo estos campos:
[lista]
Redacta Labels claros en español neutro.
Evita términos técnicos internos.
Para los campos que lo necesiten, agrega una ayuda breve de máximo 12 palabras.
No inventes información.
IA para reducir campos
Puedes pedir:
Este formulario tiene 12 campos.
El objetivo es únicamente conseguir una primera consulta comercial.
Indícame cuáles pueden ser opcionales o eliminarse y explica brevemente el motivo.
No cambies el objetivo del formulario.
IA para revisar un formulario
Revisa este formulario:
Título:
[texto]
Campos:
[lista]
Botón:
[texto]
Objetivo:
[objetivo]
Identifica:
- campos redundantes;
- Labels poco claros;
- información que falta;
- CTA ambiguo.
No inventes requisitos.
IA para CSS visual
Estoy personalizando visualmente un formulario dentro de Waclis.
El formulario YA FUNCIONA correctamente y no quiero modificar su lógica.
La sección utiliza:
.contacto-section
Los campos utilizan:
.contacto-input
El Text Area:
.contacto-textarea
El Button:
.contacto-button
Necesito:
- Inputs al 100 % del ancho disponible;
- altura de 48 px;
- Border radius de 8 px;
- separación vertical de 16 px;
- Text Area con Min Height de 140 px;
- Button cómodo en celular.
No modifiques HTML.
No cambies atributos del Form.
No agregues JavaScript.
No elimines Classes existentes.
Devuélveme solamente CSS visual y limitado a .contacto-section.
Esta aclaración es muy útil al trabajar con IA
Indica:
El formulario ya funciona. No modifiques la lógica de envío.
Así reduces el riesgo de que la herramienta intente reconstruir algo que ya está funcionando.
IA para revisar HTML
Si necesitas ayuda avanzada:
Este es el HTML de un formulario que ya funciona:
[pegar solo la estructura necesaria]
Quiero agregar visualmente un campo Empresa.
Analiza primero la estructura.
No elimines ni renombres Classes, IDs, Name u otros atributos existentes.
No escribas una solución hasta indicarme qué parte corresponde al wrapper completo de un campo.
No envíes todo el Code editor innecesariamente
Comparte solamente:
Form;
campo relevante;
estructura necesaria.
Esto reduce el riesgo de modificaciones ajenas al objetivo.
Buenas prácticas para Formularios de contacto
Recomendamos:
definir el objetivo antes de agregar campos;
pedir únicamente la información necesaria;
utilizar Labels claros;
diferenciar campos obligatorios y opcionales;
utilizar Text Area para mensajes largos;
utilizar Select o Radio cuando realmente faciliten elegir;
mantener una estructura visual consistente;
utilizar Grid para distribuir campos;
apilar correctamente en móvil;
conservar la estructura funcional de formularios que ya funcionan;
no modificar atributos o Classes sin comprender su función;
probar la interacción real;
verificar qué sucede con los datos enviados;
comprobar recepción;
mostrar políticas o consentimientos cuando corresponda;
limitar CSS a la sección;
utilizar Navigator antes de clonar o eliminar;
realizar siempre una prueba mediante Ver página.
Errores frecuentes
Crear un Form visual y asumir que automáticamente recibe consultas
Diseño y procesamiento son partes diferentes.
Publicar sin hacer una prueba real
Completa y envía el formulario.
No saber dónde llegan los datos
Confirma el flujo antes de publicarlo.
Agregar demasiados campos
Pide solamente los necesarios.
Hacer todo obligatorio
Define qué es indispensable.
Utilizar Labels ambiguos
Sé claro.
Utilizar solo placeholders y ningún contexto
Las indicaciones importantes deberían seguir visibles.
Pedir datos sensibles innecesarios
Limita la información solicitada.
Mezclar varios objetivos en un único Form
Mantén una finalidad clara.
Utilizar un Button con texto “Continuar”
Indica la acción real.
Cambiar el texto del Button y asumir que modificaste la lógica
Son conceptos diferentes.
Clonar solamente Input y olvidar Label
Clona la unidad completa.
Clonar un campo funcional sin revisar sus atributos
Comprueba posteriormente el envío.
Agregar un campo visual que no llega en los datos recibidos
La parte funcional debe contemplarlo.
Eliminar solo Input y dejar Label
Selecciona correctamente el contenedor.
Eliminar Classes o atributos que no reconoces
Puedes afectar el funcionamiento.
Modificar JavaScript para cambiar diseño
Utiliza CSS.
Crear dos columnas demasiado estrechas en celular
Apila los campos.
Utilizar Inputs demasiado pequeños
Deben ser cómodos.
Utilizar Text Area de una sola línea
Adapta su altura al contenido esperado.
No probar Select, Checkbox o Radio
Comprueba su interacción.
No comprobar el texto ingresado sobre fondos personalizados
Prueba campos completos, no solamente vacíos.
No revisar mensajes de error
Cuando existan validaciones, comprueba su presentación.
Mostrar un mensaje de éxito estático
Debe corresponder al envío real.
Aplicar CSS global a input
Puede afectar muchos elementos de la Página web.
Ocultar overflow para tapar un problema responsive
Encuentra el elemento que desborda.
No probar celular
Los formularios requieren especial atención en pantallas táctiles.
Flujo recomendado
1. DEFINIR OBJETIVO
↓
2. DEFINIR DATOS REALMENTE NECESARIOS
↓
3. ELEGIR DISEÑO
↓
4. AGREGAR FORMULARIO
↓
5. REVISAR NAVIGATOR
↓
6. MODIFICAR HEADING E INTRODUCCIÓN
↓
7. CONFIGURAR CAMPOS
↓
8. REVISAR LABELS
↓
9. DEFINIR OBLIGATORIOS / OPCIONALES
↓
10. CONFIGURAR SELECT / CHECKBOX / RADIO SI CORRESPONDE
↓
11. CONFIGURAR BUTTON
↓
12. ADAPTAR GRID
↓
13. REVISAR RESPONSIVE
↓
14. GUARDAR CAMBIOS
↓
15. VER PÁGINA
↓
16. COMPLETAR EL FORMULARIO
↓
17. ENVIAR
↓
18. COMPROBAR QUÉ OCURRE
↓
19. VERIFICAR RECEPCIÓN / PROCESAMIENTO
Checklist antes de publicar un Formulario de contacto
El formulario tiene un objetivo claro.
Sé qué debe ocurrir después de enviarlo.
Sé dónde se reciben o procesan los datos.
Realicé una prueba real.
Confirmé que el envío funciona.
Confirmé que los campos recibidos son correctos.
No asumí que el Form visual funciona automáticamente.
Solicito solamente datos necesarios.
Los campos obligatorios son realmente necesarios.
Los Labels son claros.
Los campos opcionales son comprensibles.
El Email se identifica correctamente.
El teléfono se solicita solamente si es útil.
Text Area tiene un tamaño cómodo.
Select contiene opciones válidas.
Checkbox se utiliza con una finalidad clara.
Radio Buttons representan alternativas comprensibles.
Las condiciones o políticas necesarias están correctamente comunicadas cuando corresponde.
El Button describe la acción.
No quedan textos de ejemplo.
No quedan campos de ejemplo innecesarios.
Los campos se encuentran en un orden lógico.
Las agrupaciones tienen sentido.
Revisé Navigator.
Al clonar seleccioné la unidad completa del campo.
Revisé atributos de campos clonados cuando corresponde.
No eliminé Classes funcionales.
No modifiqué atributos que no comprendo.
Los IDs personalizados son únicos.
Linked styles tiene el alcance esperado.
Desktop funciona correctamente.
Tablet funciona correctamente.
Celular funciona correctamente.
Los campos se apilan correctamente.
Ningún Input se sale de la pantalla.
No existe scroll horizontal inesperado.
El texto ingresado tiene buen contraste.
Select funciona.
Checkbox funciona.
Radio funciona.
Text Area permite escribir cómodamente.
Button puede utilizarse en móvil.
Probé errores o campos incompletos cuando existe validación.
Probé el comportamiento posterior al envío.
El CSS personalizado está limitado al formulario.
No agregué JavaScript innecesario.
Guardé los cambios.
Realicé la validación final mediante Ver página.
En resumen
La sección Formularios de contacto permite construir y personalizar estructuras destinadas a recopilar información del visitante.
Dentro del Editor de bloques puedes trabajar con componentes como:
Form
Input
Text Area
Select Input
Checkbox
Radio Button
Html Button
Una estructura básica puede ser:
Form
├── Nombre
├── Mensaje
└── Enviar
Pero recuerda el principio más importante:
un formulario visual no es necesariamente un formulario funcional.
Ver:
Nombre
Mensaje
[ ENVIAR ]
en la Página web no garantiza por sí solo que:
los datos se reciban;
se almacenen;
lleguen a un correo;
se procesen.
Después de cualquier modificación debes comprobar:
COMPLETAR
↓
ENVIAR
↓
COMPROBAR RESPUESTA
↓
VERIFICAR RECEPCIÓN
También evita solicitar información innecesaria.
Un formulario más largo no siempre es mejor.
Para una consulta simple puede bastar:
Nombre
Mensaje
Mientras que un presupuesto puede necesitar:
Nombre
Empresa
Teléfono
Servicio
Mensaje
según la información real que necesite tu equipo.
Al modificar formularios existentes:
conserva la estructura funcional si ya funciona correctamente.
No elimines arbitrariamente:
Classes;
atributos;
identificadores;
contenedores.
Para cambios visuales utiliza primero:
Contenido → Estilo → Grid → CSS localizado
antes de intervenir sobre HTML o JavaScript.
En responsive:
Desktop
[ Nombre ] [ Empresa ]
[ Email ] [ Teléfono ]
puede convertirse en:
Mobile
[ Nombre ]
[ Empresa ]
[ Email ]
[ Teléfono ]
para que cada campo siga siendo cómodo de completar.
Finalmente, nunca consideres terminado un formulario únicamente porque se ve bien.
La validación final es:
Guardar Cambios → Ver página → completar todos los campos → enviar → comprobar que la información llega correctamente.
Un buen Formulario de contacto debe ser al mismo tiempo:
claro;
breve;
fácil de completar;
responsive;
visualmente coherente;
y realmente funcional.
¿Necesitas más ayuda?
Si este artículo no resolvió tu consulta, nuestro equipo puede ayudarte personalmente.
Soporte por WhatsApp