Guía Generar leads con un blog · 5 de 9
Microcopy en formularios: etiquetas, errores y botones claros
Cómo escribir microcopy en formularios de leads: etiquetas, ayudas, errores, botones y mensajes de éxito claros, con ejemplos de antes y después.
Puntos clave
- Escribe primero etiquetas visibles y claras.
- Haz que cada error diga cómo arreglarlo.
- Usa un botón que describa la acción real.
- Separa los mensajes de éxito y de solicitud pendiente.
El microcopy de un formulario son los textos breves que guían a la persona mientras lo completa: etiquetas, ayudas, errores, botones y el mensaje después del envío. Escríbelo a partir de la tarea y de lo que hace el sistema de verdad. Un buen microcopy deja claro el siguiente paso. No convierte una solicitud fallida en un éxito ni sustituye un arreglo técnico. Estos mensajes forman parte del camino para generar leads con un blog.
¿Qué es el microcopy y para qué sirve en un formulario?
En un formulario, el microcopy responde a tres preguntas: qué escribo aquí, qué hago si me equivoco y qué pasa ahora. Si alguna de esas respuestas falta, la persona duda, lo intenta otra vez o abandona. Por eso el microcopy es parte de la usabilidad, no un adorno de la marca.
Ordena los mensajes del recorrido
Empieza por un formulario y la oferta de la que viene. Lista lo que la persona necesita saber antes de escribir, al corregir un error y después de enviar. Lee los mensajes en ese orden. Una etiqueta clara no compensa un mensaje final que promete otro servicio.
Mantén un tono tranquilo y directo. Un formulario de solicitud no es lugar para un eslogan en cada campo. Usa palabras conocidas de la tarea y explica un término cuando el usuario quizá no lo conozca.
Principios de un buen microcopy
- Específico: nombra el dato o la acción concreta.
- Orientado a la acción: dice qué hacer, no solo qué pasó.
- Breve pero claro: corto, sin volverse ambiguo.
- Honesto: describe el proceso real, no el que se querría tener.
- Coherente: usa las mismas palabras que el artículo y la oferta.
Escribe primero las etiquetas
Nombra cada campo con una etiqueta visible y corta. “Correo de trabajo” es más claro que “¿Dónde podemos encontrar a tu yo profesional?”. La etiqueta debe seguir visible cuando el campo ya tiene un valor. El texto de ejemplo dentro del campo puede ayudar, pero no debe ser la única forma de entenderlo.
Marca los campos obligatorios u opcionales siempre igual. Si usas un símbolo, explícalo. Mantén la etiqueta conectada con su campo en el código del formulario, para que las tecnologías de apoyo sepan qué pregunta va con cada campo. Web.dev explica estas pautas en su guía de accesibilidad de formularios. Pide al desarrollador que revise la implementación, no solo el diseño.
Añade ayuda donde surge una duda real
Añade un texto de ayuda cuando el campo tiene una regla o un propósito que no es obvio. “Usa el correo donde quieres recibir la hoja” explica una decisión de entrega. Un párrafo comercial bajo el campo del correo no ayuda a completarlo. Pon la ayuda cerca del campo.
Indica las reglas de formato antes de que la persona falle. Si una fecha necesita un formato, muestra un ejemplo. Si la web es opcional, dilo. No uses la ayuda para justificar datos que el equipo no necesita; la guía para reducir la fricción en formularios trata esa decisión.
Mensajes de error que dicen cómo arreglarlo
Sustituye “Dato no válido” por un mensaje que nombre el campo y la acción necesaria. Por ejemplo: “Escribe un correo con este formato: nombre@ejemplo.com”. Usa una dirección de ejemplo, nunca la de un cliente real. Habla de la tarea, no de que la persona se equivocó.
Distingue un error del campo de un fallo del servicio. Si el servidor no acepta la solicitud, no pidas a la persona que cambie un correo válido. Explica qué pasó y qué puede intentar. Conserva los datos válidos para que no tenga que empezar de nuevo. Web.dev reúne recomendaciones sobre validación y mensajes de error.
Un texto del botón que coincida con la acción
Usa “Solicitar la demo” cuando el formulario envía una petición de demo para acordar una hora. Usa “Recibir la hoja” cuando un envío válido entrega el archivo prometido. “Reservar mi sesión” engaña si no se elige una hora ni se confirma la reserva. Comprueba qué hace el sistema antes de elegir las palabras.
Mantén el botón corto. Pon los límites o detalles del seguimiento cerca, no dentro del texto del botón. No prometas una entrega “inmediata” si el equipo revisa las solicitudes a mano. Si el formulario muestra un testimonio, su texto también necesita una fuente comprobada; lo explica la guía de prueba social.
Mensajes de éxito y de solicitud pendiente
Un mensaje de éxito debe decir qué se aceptó y qué viene después. Una solicitud pendiente puede decir que el equipo escribirá para acordar una hora, si ese es el proceso real. Da un plazo solo si el equipo puede cumplirlo. No inventes una fecha para tranquilizar.
Si el recurso está listo, ofrece un enlace claro. Si llegará un correo, indícalo sin mostrar más datos personales de los necesarios. Un “¡Gracias!” solo puede dejar dudas: ¿espero, reviso el correo o hago clic otra vez?
Ejemplos de microcopy: antes y después
Ejemplo ficticio. Un formulario ofrece una lista de mantenimiento como recurso del artículo.
| Elemento | Antes | Después |
|---|---|---|
| Etiqueta | Datos | Correo para recibir la lista |
| Botón | Ir | Enviar la lista a mi correo |
| Error | Dato no válido | Escribe un correo con el formato nombre@ejemplo.com |
| Éxito | Listo | Te enviamos la lista. Revisa tu correo en unos minutos. |
Son textos de ejemplo, no el resultado de una prueba con clientes. Antes de usarlos, comprueba que el sistema envía el archivo. Si muestra un enlace de descarga en pantalla, el texto debe decir eso. El microcopy describe el flujo que tienes.
Prueba los mensajes con tareas reales
Pide a una persona que solicite la oferta sin ayudarla. Observa si las etiquetas responden a sus dudas. Prueba un campo vacío, un valor válido con un formato poco común y un fallo del servicio. Cada estado debe tener un mensaje útil, no el mismo aviso genérico.
Lee los mensajes en una pantalla pequeña y siguiendo el teclado. Comprueba a dónde va el foco cuando aparece un error. Confirma el evento de éxito solo cuando el formulario acepta la solicitud; la guía para medir los leads del blog en GA4 explica cómo. Cuando los mensajes ya funcionan, un test A/B puede comparar dos textos con una hipótesis clara.
Errores comunes en el microcopy de formularios
- Usar el texto de ejemplo como única etiqueta.
- Poner “Enviar” en todos los botones, sin decir qué se envía.
- Mostrar el mismo error para cualquier problema.
- Prometer plazos o resultados que el equipo no puede cumplir.
- Usar palabras distintas de las del artículo y la oferta.
Mantén el texto del enlace y el del formulario alineados con la oferta; la guía de message match explica cómo. DEX conecta la investigación de búsquedas, la planificación de contenido, la redacción de artículos y la publicación en el sitio conectado. Eso no significa que gestione las etiquetas, los errores o la entrega del formulario. Asigna esos mensajes a quien se encarga de la herramienta de formularios.
Mantén una hoja de mensajes
Guarda la etiqueta, la ayuda, el error, el botón y el mensaje de éxito de cada campo o estado. Anota la condición que muestra cada uno. Así el desarrollador y el editor comparten una referencia cuando cambia el formulario. Después de cada cambio, revisa el recorrido publicado con los casos acordados.
Preguntas frecuentes
¿El texto de ejemplo puede sustituir a la etiqueta?
+
No. Mantén una etiqueta visible para que el campo siga claro mientras se escribe.
¿Todos los botones deben decir Enviar?
+
No. Nombra la acción cuando una etiqueta concreta aclara el siguiente paso.
¿Un buen texto arregla un formulario roto?
+
No. Corrige los fallos técnicos además de los mensajes poco claros.
Fuentes
- Help users enter the right data in forms · web.dev (Google)
- Accessibility · web.dev (Google)