Formulario de contacto web: cómo diseñarlo para convertir

¿Qué campos debe tener un formulario de contacto?

Un formulario de contacto debe pedir la información necesaria para identificar a la persona, responderle y entender el motivo de su consulta. Para muchas empresas basta con nombre, correo electrónico y mensaje; añade teléfono, empresa o tipo de servicio solo si te ayudan a gestionar mejor esa petición.

Empieza por pensar qué necesita saber quien responderá. Si ofreces varios servicios, un selector como «¿En qué podemos ayudarte?» puede orientar la consulta sin obligar a la persona a redactar una explicación larga. Para un formulario web para pedir presupuesto, quizá también necesites conocer el alcance aproximado o el plazo deseado. No preguntes por esos datos si todavía no puedes utilizarlos.

Una estructura sencilla podría incluir:

• Nombre: para personalizar la respuesta. Si no es necesario conocer los apellidos, no los pidas.
• Correo electrónico: si es el canal que usarás para responder.
• Motivo de la consulta: mediante opciones comprensibles o un campo de texto, según la variedad de casos.
• Mensaje: para que la persona explique lo que necesita.

El teléfono no es obligatorio por defecto. Inclúyelo si realmente vas a llamar o si el tipo de servicio requiere una conversación telefónica. Del mismo modo, una empresa puede necesitar el nombre del negocio para preparar una propuesta, pero un profesional autónomo quizá no necesite ese dato.

La pregunta «qué poner en un formulario de contacto» se resuelve revisando cada campo: ¿qué decisión o acción permite tomar al equipo? Si no hay una respuesta concreta, probablemente sobra. Para ordenar estas decisiones dentro de un proyecto de web corporativa, puedes consultar nuestros servicios de diseño web personalizado.

¿Cuántos campos debería tener un formulario de contacto?

No hay una cantidad ideal para todos los formularios. Debería tener los campos mínimos que permitan tramitar la consulta, y su número dependerá de lo que necesites saber antes de responder. Si solo quieres iniciar una conversación, bastan pocos datos; si la solicitud requiere una valoración, puedes pedir algún detalle adicional y explicar para qué sirve.

Para decidir si un campo es necesario, imagina que lo eliminas. ¿Podrías contestar igualmente? ¿Podrías pedir esa información más adelante, cuando ya exista una conversación? Si ambas respuestas son sí, quitarlo puede hacer el primer paso más sencillo.

También importa el esfuerzo que exige cada campo. Un selector con opciones claras puede ser más fácil que una pregunta abierta, pero solo si las opciones representan situaciones reales. Un campo de texto largo puede ser útil para explicar un proyecto complejo; en cambio, pedir que la persona describa en detalle una necesidad sencilla añade trabajo sin aportar demasiado.

Evita juntar varias preguntas en un solo campo, como «nombre, empresa y cargo». Aunque parezca que reduce el número de casillas, obliga a entender cómo separar la respuesta y puede complicar su revisión. Tampoco conviertas el formulario en un briefing completo: el primer contacto sirve para saber si tiene sentido continuar, no para reunir todos los detalles del proyecto.

Si recibes consultas poco concretas, no añadas campos automáticamente. A veces basta con cambiar la etiqueta, añadir una instrucción o mostrar opciones más claras. Para saber qué esfuerzo requiere una web y qué incluye, puedes revisar los precios orientativos de BePand; el alcance final dependerá de las necesidades del proyecto.

¿Cómo deben ser las etiquetas de un formulario web?

Las etiquetas deben identificar con claridad qué información va en cada campo. Es mejor escribir «Correo electrónico» que «Datos de contacto», y «Cuéntanos qué necesitas» que «Información». Una etiqueta visible junto al campo ayuda a entender la tarea incluso cuando se empieza a escribir o se vuelve a revisar el formulario.

Escribe etiquetas breves, concretas y con palabras habituales para tus clientes. En vez de usar términos internos del equipo, plantea la pregunta desde la perspectiva de quien rellena el formulario. Si un dato puede interpretarse de varias maneras, añade una instrucción breve: por ejemplo, qué tipo de proyecto describir o qué formato de teléfono se acepta.

El texto de ejemplo dentro de una casilla, llamado marcador de posición, puede servir para mostrar un formato, como «[email protected]». No debe sustituir a la etiqueta: desaparece al escribir y la persona podría olvidar qué le pedían. La etiqueta debe permanecer visible.

La recomendación técnica también cuenta. El W3C indica que todos los controles del formulario necesitan una etiqueta y que esta debe estar asociada con el control; cuando sea posible, aconseja hacerlo explícitamente mediante <label> y una correspondencia entre los atributos for e id. Puedes consultar su guía de etiquetas para controles de formulario.

En cuanto al diseño, el sistema GOV.UK recomienda que las etiquetas de las entradas de texto sean visibles, breves y directas, y que se coloquen encima del campo en la mayoría de los casos. También desaconseja utilizar el marcador de posición como sustituto de una etiqueta. La guía de entradas de texto de GOV.UK desarrolla estas recomendaciones.

Una etiqueta bien escrita reduce las dudas antes de enviar. Si quieres profundizar en cómo se relaciona la estructura de la página con las tareas de quien la visita, puedes leer nuestra guía de diseño UX/UI.

¿Es mejor marcar los campos obligatorios o los opcionales?

Deja claro qué campos son obligatorios y cuáles puede dejar en blanco. Si casi todos los campos son necesarios, puedes indicarlo una vez de forma visible y marcar de manera explícita las excepciones opcionales; si hay bastantes campos prescindibles, es más claro señalar cada campo obligatorio. El criterio importante es que nadie tenga que adivinarlo.

Evita depender solo del color, de un asterisco sin explicación o de una leyenda escondida al final. Puedes acompañar la etiqueta con «Obligatorio» u «Opcional», o explicar al inicio cómo se indican los campos requeridos. Mantén el mismo criterio en todo el formulario.

La elección depende de la proporción y del contexto. Si solo hay un campo opcional, marcarlo como tal puede simplificar la lectura. Si cada pregunta es opcional salvo el correo, señálalo claramente para que la persona no pruebe a enviar datos que el sistema necesita para tramitar la consulta.

Se recomienda señalar los campos obligatorios y explicar los requisitos de formato. Esa validación puede ayudar a detectar un problema antes de enviar, pero no sustituye a una indicación clara junto al campo. Consulta la guía de validación de formularios en MDN.

Sobre todo, no marques como obligatorio un dato que no necesitas. Si quieres llamar a quien consulta, dilo y explica por qué solicitas el teléfono. Si la respuesta puede llegar por correo, no obligues a facilitar otro canal solo porque el formulario lo incluía en una versión anterior.

¿Cómo escribir mensajes de error claros en un formulario?

Un mensaje de error útil explica qué ha ocurrido y qué debe hacer la persona para corregirlo. En lugar de mostrar «Hay un error», indica «Escribe tu correo electrónico para que podamos responder» o «Revisa el formato del correo». El mensaje debe aparecer cerca del campo afectado y permitir continuar sin tener que empezar de nuevo.

Evita frases que culpan a la persona o que no dicen cómo arreglar el problema. «Campo inválido» no explica si falta información o si el formato no es correcto. «Completa este campo» es más concreto, pero aún puede mejorar si nombra el dato: «Escribe tu nombre».

Adapta el texto al problema real. Si el campo está vacío, pide el dato; si el contenido es demasiado largo, explica que debe acortarse; si hay caracteres no permitidos, indica cuáles; si el formato es incorrecto, incluye un ejemplo cuando ayude. No muestres una lista genérica de errores que no corresponda a lo que ha pasado.

GOV.UK recomienda que los mensajes de error sean específicos y expliquen qué ha ocurrido y cómo corregirlo. También desaconseja mensajes genéricos como «Ha ocurrido un error» o «Este campo es obligatorio» sin más contexto; puedes ver sus recomendaciones para mensajes de error.

El momento importa: si el formulario detecta el problema al enviar, conserva los datos que la persona ya había escrito y destaca el campo que necesita atención. Comprueba también que el mensaje se entienda en móvil y que no dependa únicamente de un cambio de color. Así los errores en formularios web dejan de ser un obstáculo y se convierten en una indicación para terminar la tarea.

¿Cómo hacer un formulario de contacto cómodo en móvil y tras el envío?

Para que un formulario sea fácil de completar en móvil, usa campos legibles, etiquetas visibles y controles que se puedan pulsar sin precisión excesiva. Mantén cada campo claramente separado y evita que la persona tenga que desplazarse entre instrucciones lejanas y casillas. Después del envío, confirma si se ha recibido la consulta y explica qué puede esperar a continuación.

Revisa el formulario en una pantalla pequeña, no solo en el ordenador. Comprueba que los campos no se desbordan, que el botón de envío se distingue y que el teclado no tapa la casilla activa. Si hay un desplegable, verifica que las opciones se pueden leer y seleccionar con facilidad.

También puedes escoger un tipo de entrada adecuado al dato. El W3C señala que algunos campos HTML5 pueden mostrar teclados virtuales apropiados en dispositivos móviles, como un teclado numérico para una entrada de tipo numérico. Esto puede facilitar la introducción de datos, siempre que el tipo elegido corresponda realmente a la información solicitada.

El botón debe describir la acción: «Enviar consulta» o «Solicitar presupuesto» informa mejor que «Enviar» si el contexto no deja claro qué se va a enviar. Tras pulsarlo, muestra una confirmación visible y específica, por ejemplo: «Hemos recibido tu consulta. Te responderemos por correo». No prometas un plazo si no puedes cumplirlo de forma consistente.

Si el envío falla, informa de ello sin borrar el mensaje escrito y ofrece una forma de volver a intentarlo. Si se envía correctamente, evita dejar la pantalla sin cambios: la persona necesita saber que la acción ha terminado. En proyectos de diseño web y desarrollo, estas decisiones se trabajan junto con el resto de la experiencia; puedes conocer los servicios de BePand o hablar con nuestro equipo para revisar el formulario de tu web.

Por último, prueba el formulario con alguien que no conozca cómo está construido. Pídele que envíe una consulta realista y observa dónde duda, qué interpreta mal y si entiende la confirmación. Una revisión breve puede revelar problemas que no aparecen cuando quienes prueban el formulario ya conocen el negocio.