Diseño de interacción (UI)
El diseño de formularios web se decide en detalles pequeños: una etiqueta que permanece visible, una duda resuelta a tiempo o un error que explica cómo seguir.
Un formulario puede parecer limpio y resultar difícil de usar. Quitar información reduce lo que se ve, pero también puede aumentar lo que una persona necesita recordar.
Tomemos una consulta ficticia por una pieza de cerámica. Bastan un nombre, un correo para responder y un mensaje que identifique la pieza. Cada campo añadido necesita una razón.
Una etiqueta que no desaparezca
El placeholder es el texto de ejemplo que aparece dentro de un campo vacío. Cuando se empieza a escribir, normalmente desaparece. Por eso no conviene usarlo como única identificación visible del dato.
«Correo electrónico» puede permanecer encima del campo. Dentro, un ejemplo como «nombre@ejemplo.com» ayuda a reconocer el formato.
La etiqueta también debe estar asociada al control en el código. W3C explica esa relación en su guía para etiquetar campos de formulario. Dibujar un texto cerca no garantiza la asociación.
Ejemplo ficticio: la etiqueta permanece visible al escribir y el error indica cómo corregir el dato. Toca para ampliar.
Antes y después: corregir una consulta sin perderla
Imagina que una persona escribe para encargar una pieza de cerámica. Completa su nombre y mensaje, pero deja «ana@» en el correo. Comparamos dos respuestas al mismo error; el objetivo es permitir que lo corrija sin reconstruir la consulta.
Mismo correo incompleto y misma consulta. Cambian la claridad del error y la conservación de los datos. Toca para ampliar.
La primera versión solo dice «Dato inválido». La segunda mantiene «Correo electrónico» visible, sitúa el aviso junto al campo y pide completar la dirección con un ejemplo de formato. El nombre y el mensaje válidos se conservan. La diferencia no está en añadir más rojo, sino en explicar la corrección y mantener el trabajo hecho.
- Dibuja ambos estados con el mismo correo incompleto, nombre y mensaje.
- En una copia de prueba, intenta continuar con el correo incompleto y localiza el aviso.
- Corrige el correo y comprueba que el mensaje de error desaparezca en el momento previsto, sin borrar los demás campos.
El resultado esperado es que se pueda identificar y corregir el dato sin adivinar. Usa también un correo largo y recorre los campos con teclado. Es una revisión de interfaz; para probar un envío real hay que verificar el destino autorizado y su recepción. Puedes continuar con la guía de navegación con teclado.
Diferenciar la pregunta de la ayuda
La etiqueta dice qué se pide. La ayuda aclara algo que podría generar una duda. «Lo usaremos para responder a tu consulta» explica la función del correo en este ejemplo, siempre que sea cierto.
No conviertas cada campo en un párrafo. Una ayuda extensa puede indicar que estás formulando una pregunta demasiado compleja o solicitando datos que no corresponden a ese momento.
Identifica también los datos obligatorios. Si empleas un asterisco, explica su significado; no presupongas que cualquier símbolo se entiende por sí solo.
Corregir sin obligar a empezar de nuevo
Un error debe identificar el problema y orientar la corrección. «Introduce un correo con un formato como nombre@ejemplo.com» resulta más útil que «Dato inválido».
Conserva los campos válidos cuando falla otro. Borrar todo el formulario después de un error obliga a repetir trabajo.
Piensa también cuándo aparecen los mensajes. Señalar un error en cada pulsación puede interrumpir antes de que la persona termine de escribir. Revisa el comportamiento con una tarea real, no solo el aspecto del estado rojo.
Una base HTML que se pueda leer
Este fragmento muestra una etiqueta asociada y una ayuda vinculada al campo. No incluye envío ni un sistema de recepción.
<label for="consulta-email">
Correo electrónico (obligatorio)
</label>
<p id="consulta-ayuda">
Lo usaremos para responder a tu consulta.
</p>
<input id="consulta-email" name="email"
type="email" required
aria-describedby="consulta-ayuda">El tipo email y required permiten ciertas comprobaciones del navegador. No confirman que el buzón exista ni sustituyen la validación y protección del servidor. MDN explica esta diferencia en su guía de validación de formularios.
Si necesitas repasar las capas, puedes empezar por HTML y CSS para diseñadores.
Mini tutorial: revisar una consulta ficticia
En una copia de prueba, recorre el formulario sin ratón y comprueba si sabes qué dato espera cada campo. Escribe, borra y vuelve atrás. Prueba un correo sin arroba y deja vacío un dato obligatorio.
Después revisa tres cuestiones:
- ¿Se mantienen las etiquetas mientras escribes?
- ¿Cada error permite identificar el campo y corregirlo?
- ¿La confirmación describe lo que realmente ha ocurrido?
Para comprobar una entrega real hace falta revisar el destino y los registros de recepción con autorización. Una ventana de éxito no es suficiente.
En móvil, revisa además que el teclado no oculte la acción y que los campos se lean sin ampliar. Hay más criterios en diseñar para móvil.
Un formulario claro pide lo necesario y acompaña a la persona hasta que sabe qué ha pasado con su consulta.
