LFW

Blog · Formularios bien hechos

Mensajes de error que ayudan de verdad

Los mensajes de error de un formulario son la única conversación que tiene. Qué dice un error útil, dónde le corresponde estar en la página, cuándo debe hablar y quién tiene que poder percibirlo.

«Entrada no válida» es un encogimiento de hombros, no un mensaje

En algún lugar del código de su formulario acaba de ejecutarse una comprobación. Sabe qué campo falló, qué regla rompió y normalmente qué quiso decir el visitante. Entonces el formulario se vuelve hacia el visitante y resume todo ese conocimiento como «Entrada no válida». O un borde rojo sin ninguna palabra. O el clásico: «Se produjo un error».

El visitante se queda haciendo el diagnóstico por su cuenta: releyendo cada campo, adivinando reglas no dichas, quizá descubriendo por ensayo y error que el campo de teléfono rechaza en secreto los paréntesis. Cada ronda de ese juego de adivinanzas le cuesta un porcentaje de las personas que lo juegan. Y las que se rinden no presentan una queja sobre su validación. Simplemente se van, y la analítica del formulario registra otro envío abandonado sin explicación.

Lo frustrante es que el texto de los errores es casi gratis. No es un proyecto de ingeniería; es una tarea de redacción que la ingeniería ya hizo posible. El formulario sabe la respuesta. Alguien solo tiene que decidir que vale la pena decirla.

Un error útil responde tres preguntas

Qué campo. Qué está mal. Cómo se ve lo correcto. «Número de teléfono: necesita un código de área, como 555-012-3456». Cualquier cosa que responda las tres deja al visitante corregir el error en un solo movimiento, que es todo el trabajo. Cualquier cosa que responda menos de tres está delegando la parte que falta a la paciencia del visitante.

El tono también trabaja aquí. El visitante cometió un error en su formulario, que es distinto de haber hecho algo mal. «Por favor, introduzca una dirección de correo válida» se lee como una multa; «Necesitamos un correo como nombre@ejemplo.org para responderle» se explica solo y da una razón para cumplir. Los mejores mensajes de error apenas se registran como errores. Se leen como un colega señalando la línea que necesita otra mirada.

También hay una categoría de error que no es culpa del visitante en absoluto: el servidor falló, la conexión se cayó, algo de su lado se rompió. Esos mensajes necesitan el énfasis opuesto: «Algo salió mal de nuestro lado; su mensaje sigue aquí, inténtelo de nuevo». Lo peor que puede hacer un formulario es redactar su propio fallo como si fuera del visitante.

Ponga el error donde ya están los ojos

Un mensaje de error mostrado lejos de su campo es una búsqueda del tesoro. El lugar natural de cada mensaje es justo al lado del campo del que trata. Los ojos del visitante ya están ahí, y la corrección está a un palmo de la explicación. Un banner rojo en lo alto de la página que dice «hubo 3 errores» mientras los errores mismos se esconden más abajo consigue ser alarmante e inútil al mismo tiempo.

Los formularios largos merecen una segunda capa: un resumen arriba que liste cada problema, con cada elemento enlazando directamente a su campo. No es una contradicción de la regla de junto-al-campo. Es un añadido, y existe sobre todo para la situación en que un visitante envía desde el final de una página larga y los fallos están dispersos más arriba. El foco debe aterrizar en ese resumen cuando aparece, para que la siguiente acción del visitante sea leerlo, no buscarlo.

Y debajo de todo, sigue rigiendo la regla de antes en esta serie: un error nunca debe costarle al visitante su trabajo. Un formulario que responde a un error tipográfico en el campo de teléfono vaciando el campo de mensaje ha castigado el delito equivocado.

Cuándo hablar

El momento es una decisión propia. Un formulario que valida en cada pulsación de tecla regaña a la gente por frases que no ha terminado: la dirección de correo es «no válida» durante todo el tiempo que se está escribiendo, lo cual es técnicamente cierto y completamente inútil. La respuesta a medio formar del visitante todavía no está mal; está en curso.

El patrón tranquilo comprueba cuando el visitante abandona un campo (el momento en que se supone que su respuesta está completa) y otra vez al enviar, lo que atrapa cualquier cosa saltada. Y una vez que un campo se ha marcado como incorrecto, la cortesía se invierte: ahora revalide mientras escribe, para que el error se evapore en el instante en que aterriza la corrección en lugar de quedarse hasta el siguiente envío. Lento para acusar, rápido para perdonar.

Errores que todos puedan percibir

Una parte significativa de los visitantes nunca verá su rojo. Los visitantes daltónicos pueden ver el borde de error como un borde más; los usuarios de lectores de pantalla no lo ven en absoluto. El color puede enfatizar un error, pero no puede ser el error. Cada fallo necesita palabras, adjuntas al campo en el marcado, para que la tecnología de asistencia anuncie el problema cuando el campo recibe el foco. Un error que solo existe como un matiz de color es, para parte de su audiencia, un error que no existe.

Esto cae con más fuerza sobre la audiencia que esta serie mantiene a la vista: las instituciones públicas, cuyos formularios son a menudo la vía legalmente establecida para llegar a un servicio y cuyas obligaciones de accesibilidad no son aspiracionales. Pero el enfoque del cumplimiento se queda corto. El visitante que más necesita que el mensaje de error sea explícito es desproporcionadamente el visitante para el que existen los formularios del sector público: mayor, menos seguro en línea, con tecnología prestada, en un segundo idioma.

Lo siguiente en esta serie: el mismo cuidado pasa a pantallas más pequeñas. Áreas táctiles y teclados móviles, y por qué el teléfono en la mano de su visitante es el revisor más estricto al que su formulario se enfrentará jamás.

Siga leyendo

6 de septiembre de 2026 8 minutos

Los cuatro archivos que nadie enlaza

Todo sitio web tiene cuatro archivos de texto plano que ningún visitante ve: robots.txt, sitemap.xml, security.txt y llms.txt. Los buscadores, los escáneres de seguridad y los agentes de IA los leen en cada visita. Qué es cada uno, quién lo lee de verdad, qué poner en él y la única regla que los mantiene a todos seguros. Esta semana repasamos la lista en nuestro propio sitio y encontramos huecos, así que la auditoría gratuita ahora los comprueba.

6 de septiembre de 2026 6 minutos

Nuestra imagen principal desaparecía en iPhone. Un bloqueador de anuncios la escondía.

Durante semanas, la imagen principal de tres de nuestras propias páginas desaparecía un segundo y medio en iPhone, solo en la primera carga. Nada lo reproducía en el laboratorio. Un rastreo de campo de cincuenta líneas lo encontró en tres cargas de página: un bloqueador de anuncios escondía cualquier elemento cuya clase empezara por ad-.

Todos los artículos →

Prefer to write?

Tell us what needs to work better.

Slow, fragile, hard to edit, missing a workflow. Say it plainly, and you'll get a straight answer, not a ticket number.

You'll get a straight answer, usually the same day.