Diseño UI de campos de formulario: etiquetas, ayudas, foco y errores

Hay una prueba que hacemos en el estudio antes de dar por bueno un formulario: lo rellenamos con el móvil en una mano, de pie, con prisa y con datos reales, incluidos un apellido compuesto, un correo largo y una dirección con escalera y puerta. En cinco minutos aparecen cosas que en la pantalla de diseño eran invisibles: una etiqueta que desaparece al escribir, un teclado que no es el adecuado, un mensaje de error que llega antes de terminar de teclear, un desplegable con 200 países donde España está en la posición 68.

Cada uno de esos detalles vive en el diseño de un solo campo. En nuestra guía sobre formularios web que convierten hablamos de cuántos campos pedir y de cómo generar confianza en el conjunto. Aquí bajamos un nivel: la anatomía de cada campo, sus medidas, el control adecuado para cada dato, sus estados y el código que lo sostiene. Es la parte más artesanal del diseño de interfaces, y la que más se agradece al usarla.

01Anatomía de un campo bien resuelto

Un campo de formulario completo tiene más piezas de las que parece. Estas son las que diseñamos, de arriba abajo:

1. 01Etiqueta. El nombre del dato, siempre visible, encima del campo. Corta y concreta: «Teléfono», «Fecha de llegada».
2. 02Indicador de opcional u obligatorio. Pegado a la etiqueta: «Empresa (opcional)».
3. 03Texto de ayuda previo, si la duda surge antes de escribir: «Lo usaremos solo para confirmar la cita».
4. 04Contenedor del campo. La caja donde se escribe, con su borde, fondo y radio.
5. 05Placeholder, si aporta un ejemplo de formato: «600 000 000». Opcional.
6. 06Iconos o afijos dentro del campo: un símbolo de euro, un botón para mostrar la contraseña, un icono de calendario.
7. 07Mensaje de error o de validación, debajo del campo, cuando corresponde.
8. 08Contador de caracteres, si hay un límite.

No todos los campos necesitan todas las piezas, pero conviene que el sistema de diseño las tenga previstas, con su tipografía, su color y sus espacios, para que cada formulario nuevo se construya sin improvisar.

Clave: la etiqueta es la única pieza que nunca se negocia. Todo lo demás se añade según el dato; la etiqueta está siempre, visible y conectada al campo en el código.

Por qué la etiqueta va siempre visible

El patrón de usar solo el placeholder como etiqueta (el texto gris dentro de la caja) sigue siendo muy común porque deja formularios limpios en la maqueta. En uso real tiene tres problemas: desaparece al escribir, así que al revisar ya no se sabe qué era cada campo; su gris claro casi nunca alcanza el contraste de 4,5:1 que pide WCAG 2.2 para el texto, y muchas personas confunden un campo con placeholder con un campo ya relleno. El Nielsen Norman Group lleva años documentándolo en sus estudios de usabilidad.

Las etiquetas flotantes (que empiezan dentro del campo y suben al enfocarlo) son un término medio aceptable si se hacen bien: tamaño legible en su posición superior, buen contraste y espacio suficiente para que no se monten sobre el texto. Aun así, en nuestros proyectos preferimos la etiqueta fija encima: es más sencilla de construir, más robusta con textos largos y no depende de animaciones.

02Medidas que funcionan

Estas son las medidas de partida que usamos, coherentes con un sistema de espaciado de 8 puntos:

El ancho dice qué se espera

El ancho de un campo es una pista silenciosa. Un código postal en un campo de ancho completo parece pedir algo largo; uno de 5 o 6 caracteres de ancho se entiende al instante. En escritorio, ajustar el ancho al dato esperado (código postal, CVV, año) ayuda a rellenar más rápido. En móvil, la mayoría de campos van a ancho completo por comodidad, salvo pares cortos que se pueden poner en línea, como mes y año de caducidad.

Una columna

Los formularios de una sola columna se recorren de arriba abajo sin dudas sobre el orden. Las excepciones razonables son pares que forman una unidad mental: nombre y apellidos, código postal y ciudad, fecha de llegada y de salida.

03El control adecuado para cada dato

Diseñar un campo también es elegir qué tipo de control usar. La regla general: cuantas menos acciones necesite la persona para dar el dato correcto, mejor.

Dos matices. Primero, la diferencia entre casilla e interruptor: la casilla se usa en formularios que se envían con un botón; el interruptor, en ajustes que se aplican en el acto, como activar notificaciones. Segundo, la fecha de nacimiento: abrir un calendario y retroceder 40 años mes a mes es una de las experiencias más frustrantes de la web. Tres campos (día, mes, año) o uno de texto con formato claro funcionan mucho mejor.

04Los estados de un campo

Igual que un botón, un campo cambia según lo que pasa. Diseñamos siempre estos estados:

• →Vacío (reposo). Borde visible, fondo neutro, etiqueta clara.
• →Hover. Un leve oscurecimiento del borde en escritorio. Opcional.
• →Foco. El más importante. Indica dónde va a aparecer lo que se escribe. Lo resolvemos con un borde de 2 px en el color de acción más un anillo exterior suave, con un contraste de al menos 3:1.
• →Relleno. El texto escrito en el color principal de texto, claramente distinto del placeholder.
• →Error. Borde en color de error, un icono y un mensaje debajo. El color solo no basta: WCAG pide que la información no dependa únicamente del color, así que el icono y el texto son necesarios.
• →Validado. Opcional y con mesura: una marca verde discreta en campos donde confirmar ayuda (un correo disponible, un código postal reconocido).
• →Desactivado. Fondo gris claro y texto atenuado. Si un campo no se puede editar pero su contenido importa, mejor el estado de solo lectura, que se puede seleccionar y copiar.
• →Solo lectura. Sin borde o con borde muy suave, texto en color normal.

05Validación y mensajes de error en el campo

El momento de validar cambia mucho la experiencia. Lo que mejor funciona en la mayoría de formularios es:

1. 01Validar al salir del campo (evento blur), cuando la persona ya ha terminado de escribir.
2. 02Quitar el error en cuanto se corrige, mientras escribe, para dar una sensación inmediata de progreso.
3. 03Validar todo de nuevo al enviar, llevar el foco al primer campo con error y, en formularios largos, mostrar un resumen arriba con enlaces a cada campo.
4. 04Mostrar en tiempo real solo lo que ayuda a construir el dato, como los requisitos de una contraseña, marcándolos en positivo a medida que se cumplen.

El texto del error es tan importante como su posición. Un buen mensaje dice qué ha pasado y cómo arreglarlo, en el idioma de quien lo lee: «Escribe el correo con el formato nombre@dominio.com» funciona mucho mejor que «Formato inválido». La redacción de estos mensajes tiene su propia guía, mensajes de error que ayudan.

Y un detalle que se olvida a menudo: si el formulario falla al enviarse, los datos se conservan. Volver a escribir todo es la forma más rápida de que alguien lo deje para otro día.

06El HTML que hace que el diseño funcione

Un campo bien dibujado necesita un código bien escrito para comportarse como se espera: que el teclado del móvil sea el adecuado, que el navegador autocomplete, que el lector de pantalla anuncie la etiqueta, la ayuda y el error. Este es el patrón que usamos:

<div class="field">
  <label for="tel">Teléfono</label>
  <p id="tel-help" class="field-help">Te llamaremos solo para confirmar la reserva.</p>
  <input
    id="tel"
    name="tel"
    type="tel"
    inputmode="tel"
    autocomplete="tel"
    required
    aria-describedby="tel-help tel-error"
    aria-invalid="true">
  <p id="tel-error" class="field-error">Escribe un teléfono de 9 cifras, por ejemplo 600 000 000.</p>
</div>

Lo que aporta cada pieza:

• →`label` con `for`: conecta la etiqueta con el campo. Además, al tocar la etiqueta se enfoca el campo, que es un área de toque extra muy útil en casillas y botones de opción.
• →`type` e `inputmode`: muestran el teclado adecuado en móvil (numérico para teléfonos, con arroba para correos, decimal para importes).
• →`autocomplete`: permite que el navegador rellene nombre, correo, dirección o tarjeta de un toque. Los valores están estandarizados en la especificación HTML (name, email, postal-code, cc-number…), y WCAG 2.2 los recoge en el criterio 1.3.5.
• →`aria-describedby`: hace que el lector de pantalla lea la ayuda y el error después de la etiqueta.
• →`aria-invalid`: comunica que el campo tiene un error. Se añade solo cuando lo hay.

Para agrupar botones de opción o casillas relacionadas se usa fieldset con su legend, que hace de etiqueta del grupo: «¿Cómo prefieres que te contactemos?».

07Ejemplo resuelto: el formulario de reserva de un restaurante

Un restaurante de Marbella con el que trabajamos pedía, para reservar, nombre, correo, teléfono, fecha, hora, número de personas y comentarios. Así quedó el diseño campo a campo:

1. 01Fecha: control segmentado con «Hoy», «Mañana» y «Otra fecha», que abre un calendario solo si hace falta. La mayoría de reservas son para los dos primeros días.
2. 02Hora: botones con los huecos disponibles en lugar de un desplegable. Se ve de un vistazo qué queda libre.
3. 03Personas: campo numérico con botones − y + de 48 px, valor inicial 2.
4. 04Nombre: un solo campo, autocomplete="name".
5. 05Teléfono: type="tel", ayuda previa explicando para qué se usa.
6. 06Correo: type="email" y autocomplete="email", validación al salir del campo.
7. 07Comentarios (opcional): área de texto de tres líneas con un ejemplo en la ayuda: «Alergias, trona, celebración…».
8. 08Botón: «Reservar mesa para 2», que actualiza el número al cambiar las personas.

El orden también se pensó: primero lo que define la reserva (cuándo y cuántos) y después los datos personales, cuando la persona ya ha visto que hay sitio. Rellenarlo en el móvil lleva menos de un minuto.

Un formulario bien diseñado se nota en lo que no pasa: nadie se queda dudando, nadie vuelve a escribir lo que ya escribió, nadie abandona en el tercer campo. Lo trabajamos así, campo a campo y hasta el código, en cada proyecto de diseño web y experiencia digital de SIMA. Si tu web tiene un formulario que sientes que podría rendir más, escríbenos y lo revisamos contigo.