Usabilidad: claridad, consistencia y retroalimentación

Una interfaz puede tener buen diseño visual, colores atractivos y código que no produce errores. Pero si el usuario no entiende qué debe hacer, si cada pantalla parece hablar un idioma distinto o si el sistema no responde cuando algo ocurre, la experiencia se rompe.

Por eso la usabilidad es una de las primeras ideas que debemos trabajar en Desarrollo de Interfaces. No se trata de hacer pantallas “bonitas”, sino de construir caminos comprensibles para que una persona pueda lograr una tarea sin adivinar, sin miedo y sin perder tiempo.

Qué aprenderás hoy

Hoy vamos a trabajar tres pilares sencillos, pero poderosos:

• Claridad: que el usuario entienda dónde está, qué puede hacer y qué significa cada elemento.
• Consistencia: que patrones, botones, textos y estados se comporten de forma predecible.
• Retroalimentación: que el sistema confirme acciones, errores, cargas y resultados.

Claridad: que la pantalla no obligue a adivinar

La claridad empieza con una pregunta muy concreta: ¿qué necesita entender el usuario en este momento? No todo debe competir por atención. Una pantalla clara ordena prioridades, separa acciones principales de acciones secundarias y usa palabras que el usuario reconoce.

Un error común es usar textos genéricos: “Aceptar”, “Enviar”, “Continuar”, sin explicar qué ocurrirá. También ocurre cuando una pantalla muestra demasiadas opciones al mismo nivel, como si todo fuera urgente. La claridad no aparece por casualidad: se diseña.

Nielsen Norman Group incluye la relación entre el sistema y el mundo real como una de sus heurísticas: la interfaz debe hablar el lenguaje del usuario, no solamente el lenguaje interno del programador. En una aplicación educativa, por ejemplo, “Guardar avance” comunica mejor que “Procesar registro”.

Consistencia: que el usuario pueda aprender una vez y reutilizar

La consistencia permite que una persona aprenda un patrón y lo aplique en otras partes. Si un botón rojo elimina en una pantalla, no debería guardar en otra. Si una alerta de error aparece debajo del campo en un formulario, conviene mantener ese patrón en los demás formularios.

La consistencia también facilita el mantenimiento. Cuando el equipo define estilos, nombres y componentes repetibles, el código se vuelve más fácil de revisar. No es solo un tema de diseño: también es arquitectura de interfaz.

:root {
  --color-primary: #26394d;
  --color-danger: #ff4f4f;
  --color-success: #2aaa78;
  --space-sm: 8px;
  --space-md: 16px;
}

.button {
  border: 0;
  border-radius: 6px;
  padding: var(--space-sm) var(--space-md);
  font-weight: 700;
}

.button-primary {
  color: white;
  background: var(--color-primary);
}

.button-danger {
  color: white;
  background: var(--color-danger);
}

Este ejemplo no resuelve todo, pero marca una dirección: si repetimos decisiones importantes en variables y clases claras, reducimos improvisación.

Retroalimentación: el sistema debe responder

Una interfaz silenciosa produce incertidumbre. Si el usuario presiona un botón y no pasa nada visible, puede pensar que falló, hacer clic muchas veces o abandonar la tarea. La retroalimentación responde a una necesidad humana: saber si la acción fue recibida.

W3C/WAI presta especial atención a errores, instrucciones y mensajes de estado. Una interfaz accesible no solo cambia de color; también comunica el resultado de forma comprensible para distintas personas y tecnologías de asistencia.

Ejemplo básico: un formulario poco usable

  OK
  

El formulario puede parecer suficiente, pero deja varios vacíos: no hay etiqueta, el botón no explica la acción, el mensaje de error no está conectado con el campo y no existe una región clara para informar el estado.

Ejemplo mejorado: claridad y respuesta

  Correo para recibir el material
  Usaremos este correo solo para enviarte el recurso.
  

Esta versión comunica mejor. La etiqueta permanece visible, el texto de ayuda reduce incertidumbre, el error tiene un lugar específico y el estado del formulario puede ser anunciado sin interrumpir la navegación.

const form = document.querySelector('.subscribe-form');
const email = document.querySelector('#email');
const error = document.querySelector('#email-error');
const status = document.querySelector('#form-status');

form.addEventListener('submit', function (event) {
  event.preventDefault();
  error.textContent = '';
  status.textContent = '';

  if (!email.validity.valid) {
    error.textContent = 'Escribe un correo valido antes de enviar el material.';
    email.focus();
    return;
  }

  status.textContent = 'Listo. Te enviaremos el material en unos minutos.';
});

La mejora no consiste en escribir más código porque sí. Consiste en reducir ambigüedad. El usuario sabe qué debe ingresar, por qué se pide, qué falló y qué ocurrió al final.

Buenas prácticas para revisar una pantalla

• Usa verbos concretos en botones: guardar cambios, enviar mensaje, descargar archivo.
• Mantén el mismo estilo para acciones equivalentes.
• Define estados para carga, error, éxito y vacío.
• No ocultes instrucciones importantes dentro del placeholder.
• Comprueba si la tarea puede completarse usando teclado.

Reto práctico

Conclusión

La usabilidad no es una etapa final que se agrega cuando la aplicación ya está terminada. Es una forma de tomar decisiones desde el inicio. Una pantalla clara reduce dudas. Una pantalla consistente permite aprender. Una pantalla con retroalimentación genera confianza.

Si el primer capítulo nos recordó que una interfaz es un puente, este segundo capítulo nos dice cómo hacerlo transitable. En el próximo paso hablaremos de UX para estudiantes de desarrollo: cómo pasar del usuario al flujo antes de llenar la pantalla de componentes.

Fuentes consultadas

• Nielsen Norman Group: 10 heurísticas de usabilidad para diseño de interfaces
• W3C WAI: How to Meet WCAG 2.2
• MDN Web Docs: validación de formularios
• MDN Web Docs: aria-live