Qué es una interfaz y por qué no basta con que funcione
Serie: Desarrollo de Interfaces
Curso: Desarrollo de Interfaces 1
Capítulo 01: Fundamentos de interfaz, usabilidad y experiencia de usuario
Cuando empezamos a programar, es normal celebrar que algo “funcione”. Hicimos clic y apareció un mensaje. Llenamos un formulario y los datos llegaron. Presionamos un botón y la página cambió. Ese momento tiene algo hermoso: por primera vez sentimos que el código responde.
Pero en Desarrollo de Interfaces aparece una pregunta más exigente: ¿funcionar para quién? Una interfaz no es solo una pantalla con botones, colores y campos. Es el punto de encuentro entre una persona que quiere lograr algo y un sistema que debe ayudarla a conseguirlo con claridad, confianza y el menor esfuerzo posible.
Por eso este primer capítulo parte de una idea sencilla: una interfaz que “funciona” técnicamente todavía puede fallar como experiencia. Puede confundir, esconder información, no responder a tiempo, pedir datos sin explicar por qué o dejar fuera a personas que navegan con teclado, lector de pantalla o desde un celular pequeño.
Qué aprenderás hoy
En este capítulo vamos a ordenar tres ideas base:
- Qué entendemos por interfaz en una aplicación web.
- Por qué la usabilidad y la accesibilidad no son adornos finales.
- Cómo una misma pantalla puede mejorar usando HTML semántico, etiquetas claras y retroalimentación visible.
Una interfaz no se evalúa solamente por lo que el sistema puede hacer, sino por lo que el usuario puede entender, decidir y completar sin sentirse perdido.
La interfaz como puente
Podemos imaginar una interfaz como un puente. De un lado está la intención del usuario: comprar, registrarse, buscar, publicar, aprender, editar, guardar. Del otro lado está la lógica del sistema: rutas, validaciones, base de datos, APIs, reglas de negocio. La interfaz permite que ambos mundos se entiendan.
Si ese puente está mal construido, el usuario no ve la complejidad interna: simplemente siente fricción. No sabe si el botón hizo algo. No entiende qué campo está mal. No sabe cómo volver. O peor: piensa que el error fue suyo.
Las heurísticas de Nielsen Norman Group siguen siendo útiles porque nos recuerdan principios muy humanos: mostrar el estado del sistema, hablar el lenguaje del usuario, mantener consistencia, prevenir errores y ofrecer salidas claras. No son reglas antiguas para decorar diapositivas; son criterios prácticos para revisar si una pantalla ayuda o estorba.
Cuando “funciona” no alcanza
Observa este ejemplo. Técnicamente puede enviar datos, pero como interfaz deja varias dudas:
<div>
<input placeholder="Nombre">
<input placeholder="Correo">
<button>Enviar</button>
</div>¿Qué ocurre si el usuario navega con lector de pantalla? ¿Qué pasa si el placeholder desaparece al escribir? ¿Qué tipo de correo se espera? ¿El botón enviará un formulario, guardará un borrador o abrirá otra pantalla? El código puede verse pequeño y limpio, pero todavía no comunica suficiente.
MDN insiste en el valor del HTML semántico: usar el elemento correcto para el propósito correcto ayuda al navegador, a las herramientas de asistencia y al propio mantenimiento del proyecto. Una interfaz empieza a mejorar cuando el código describe mejor la intención.
Una primera mejora con HTML semántico
Ahora veamos una versión más clara:
<form class="contact-form" action="/contacto" method="post">
<div class="form-field">
<label for="nombre">Nombre completo</label>
<input id="nombre" name="nombre" type="text" autocomplete="name" required>
</div>
<div class="form-field">
<label for="correo">Correo electronico</label>
<input id="correo" name="correo" type="email" autocomplete="email" required>
</div>
<button type="submit">Enviar mensaje</button>
</form>Esta versión no es mucho más larga, pero sí es más expresiva. Usa un formulario real, asocia cada campo con una etiqueta, define tipos de entrada y aclara la acción del botón. Esa diferencia importa para usuarios, navegadores, validaciones y accesibilidad.
No uses un placeholder como reemplazo de una etiqueta. El placeholder puede servir como ayuda adicional, pero el nombre del campo debe permanecer visible y estar asociado al control.
La retroalimentación también es interfaz
Una pantalla no solo debe recibir acciones. También debe responder. Si el usuario hace clic en “Enviar mensaje”, necesita saber qué está pasando: si el formulario se está procesando, si hubo un error o si todo salió bien.
Podemos agregar una respuesta sencilla con JavaScript:
const form = document.querySelector('.contact-form');
const statusMessage = document.querySelector('#form-status');
form.addEventListener('submit', function (event) {
event.preventDefault();
statusMessage.textContent = 'Estamos enviando tu mensaje...';
statusMessage.className = 'status status-loading';
setTimeout(function () {
statusMessage.textContent = 'Mensaje enviado correctamente.';
statusMessage.className = 'status status-success';
}, 900);
});Este ejemplo es simple, pero enseña una idea fundamental: el sistema debe hacer visible su estado. Cuando no hay retroalimentación, el usuario puede repetir la acción, abandonar la página o desconfiar del resultado.
Creer que la interfaz termina cuando el botón ejecuta una función. En realidad, también debemos diseñar los estados: vacío, cargando, error, éxito, edición, confirmación y recuperación.
Usabilidad y accesibilidad desde el inicio
W3C organiza la accesibilidad alrededor de principios como perceptible, operable, comprensible y robusto. En palabras sencillas: la información debe poder percibirse, la interfaz debe poder usarse, el contenido debe entenderse y el código debe resistir distintos navegadores y tecnologías de apoyo.
Esto no significa que cada estudiante deba dominar todas las normas desde el primer día. Significa que debemos adoptar una forma de pensar: cada decisión visual y técnica puede abrir o cerrar puertas. Un contraste pobre, un botón sin foco visible o un mensaje de error confuso no son detalles menores; afectan directamente la posibilidad de completar una tarea.
Tres niveles para mejorar una interfaz
- Básico: usa etiquetas, botones reales, textos claros y estructura semántica.
- Intermedio: agrega estados visibles, validaciones comprensibles y navegación por teclado.
- Profesional: mide errores, prueba con usuarios, documenta componentes y mantiene consistencia.
La diferencia entre estos niveles no está en usar una librería famosa. Está en comprender mejor el problema. React, Vue, Bootstrap o cualquier framework pueden ayudar, pero no sustituyen el criterio de interfaz. Un mal formulario en HTML también puede convertirse en un mal formulario en React, solo que con más archivos.
Reto práctico
Toma un formulario sencillo que hayas hecho antes y mejóralo en tres pasos: agrega etiquetas reales, define estados de error y éxito, y revisa si puede usarse con teclado. Luego escribe qué cambió en la experiencia, no solo en el código.
Conclusión
Desarrollar interfaces no consiste únicamente en poner elementos en una pantalla. Consiste en diseñar una conversación entre persona y sistema. Cada etiqueta, cada botón, cada mensaje y cada estado comunica algo. A veces comunica claridad. A veces comunica abandono.
Por eso, antes de preguntar si una interfaz funciona, conviene preguntar si orienta, si responde, si previene errores y si permite avanzar. Ese cambio de mirada será la base de toda la serie.
En el próximo capítulo trabajaremos usabilidad con más detalle: claridad, consistencia y retroalimentación como criterios para evaluar una pantalla antes de escribir más código.