UX para estudiantes de desarrollo: del usuario al flujo

Cuando un estudiante empieza a desarrollar interfaces, suele mirar primero la pantalla: el boton, el formulario, el color, el menu, la tarjeta. Eso es normal. La pantalla es lo que vemos. Pero una interfaz no empieza realmente en la pantalla. Empieza antes: en una persona que quiere lograr algo.

La experiencia de usuario, o UX, nos ayuda a cambiar la pregunta. En lugar de pensar solamente que componentes voy a poner, empezamos preguntando: quien usa esto, que necesita hacer, que sabe, que espera y que podria impedirle avanzar. Ese cambio parece pequeno, pero transforma la forma de programar.

En los dos primeros capitulos vimos que una interfaz no basta con que funcione y que la usabilidad requiere claridad, consistencia y retroalimentacion. Hoy damos un paso mas: vamos a convertir una necesidad de usuario en un flujo. Es decir, en una secuencia de pasos que una persona puede seguir para completar una tarea sin perderse.

Que aprenderas hoy

• Diferenciar pantalla, tarea, usuario y flujo.
• Crear un flujo simple antes de escribir codigo.
• Representar estados: inicio, carga, exito, error y vacio.
• Mejorar un ejemplo basico con HTML, CSS y JavaScript.
• Detectar errores comunes cuando se programa sin pensar en UX.

Por que importa para quien programa

Un desarrollador que entiende UX toma mejores decisiones tecnicas. Nombra mejor sus variables, separa mejor sus componentes, anticipa estados y evita crear pantallas que solo funcionan cuando todo sale perfecto. En proyectos reales, los usuarios no siempre llegan con calma, no siempre leen todo, no siempre escriben bien los datos y no siempre tienen buena conexion.

Por eso, pensar en UX no es un lujo del area de diseno. Tambien es una habilidad de desarrollo. Si programas una pantalla de registro, no estas construyendo solamente un formulario; estas construyendo el camino para que alguien cree una cuenta. Si programas un carrito, no estas colocando solo botones y cantidades; estas acompanando una decision de compra.

Nielsen Norman Group suele explicar el journey map como una forma de visualizar lo que una persona atraviesa al intentar lograr un objetivo con un producto o servicio. Para empezar en clase no necesitamos una herramienta compleja. Basta con aprender a ordenar pasos, decisiones y emociones basicas.

Del usuario al flujo

Antes de abrir el editor de codigo, escribe cuatro respuestas:

• Usuario: quien va a usar la interfaz.
• Objetivo: que quiere conseguir.
• Contexto: desde donde, con que urgencia o limitacion.
• Resultado: como sabra que termino correctamente.

Por ejemplo, imaginemos una plataforma de cursos. Una estudiante quiere inscribirse a un taller de JavaScript. No necesita ver todos los talleres del mundo. Necesita encontrar el curso, revisar si le sirve, confirmar su inscripcion y recibir una senal clara de exito.

Un flujo simple podria verse asi:

Inicio
  -> Ver cursos disponibles
  -> Elegir "JavaScript para interfaces"
  -> Revisar datos del curso
  -> Confirmar inscripcion
  -> Ver mensaje de exito

Ese pequeno mapa ya nos ayuda a programar mejor. Podemos convertir cada paso en una seccion, un componente o una ruta. Tambien podemos preguntarnos que pasa si no hay cursos, si el usuario ya esta inscrito, si falla la conexion o si falta un dato.

Ejemplo basico: una pantalla pensada solo como formulario

Este primer ejemplo cumple una funcion minima: muestra un curso y permite presionar un boton. Pero todavia no expresa bien el flujo. No hay contexto, no hay estado, no hay confirmacion clara y no hay alternativa cuando algo falla.

<section class="course-card">
  <h2>JavaScript para interfaces</h2>
  <p>Curso introductorio para crear interacciones web.</p>
  <button>Inscribirme</button>
</section>

Funciona, si. Pero todavia deja muchas preguntas abiertas. Que pasara al hacer clic? La inscripcion es inmediata? Hay cupos? El usuario recibira una confirmacion? Puede cancelar? Esta pantalla no esta mal como punto de partida, pero aun no piensa como experiencia.

Ejemplo mejorado: una pantalla con flujo visible

Ahora agreguemos una estructura mas clara. La interfaz explica el paso actual, muestra informacion relevante y reserva un espacio para comunicar el resultado de la accion.

<section class="enrollment-flow" aria-labelledby="course-title">
  <p class="step-label">Paso 1 de 2: revisa el curso</p>

  <article class="course-card">
    <h2 id="course-title">JavaScript para interfaces</h2>
    <p>Aprende a crear interacciones, validar formularios y responder a eventos del usuario.</p>
    <ul>
      <li>Nivel: inicial</li>
      <li>Duracion: 4 semanas</li>
      <li>Modalidad: practica guiada</li>
    </ul>
  </article>

  <button class="button-primary" id="enroll-button">
    Confirmar inscripcion
  </button>

  <p id="flow-status" class="flow-status" aria-live="polite"></p>
</section>

Hay una diferencia importante: ahora el HTML no solo dibuja cosas. Tambien describe una tarea. El usuario entiende donde esta, que revisa y que accion realiza. Ademas, el estado de la operacion tiene un lugar especifico.

Variante profesional: pensar en estados

Un flujo real no tiene un solo final. Puede terminar bien, fallar o quedar pendiente. Por eso, conviene representar estados desde el inicio. En JavaScript podemos empezar con algo sencillo:

const button = document.querySelector('#enroll-button');
const statusBox = document.querySelector('#flow-status');

function setStatus(type, message) {
  statusBox.className = `flow-status flow-status-${type}`;
  statusBox.textContent = message;
}

button.addEventListener('click', function () {
  button.disabled = true;
  setStatus('loading', 'Estamos registrando tu inscripcion...');

  window.setTimeout(function () {
    const success = true;

    if (success) {
      setStatus('success', 'Listo. Tu inscripcion fue registrada correctamente.');
      button.textContent = 'Inscripcion confirmada';
      return;
    }

    button.disabled = false;
    setStatus('error', 'No pudimos registrar la inscripcion. Intentalo nuevamente.');
  }, 900);
});

Este ejemplo simula una operacion asincrona. En un proyecto real, el resultado podria venir de una API, de un servidor Express o de una consulta a base de datos. Lo importante es que el usuario no queda abandonado despues del clic. La interfaz responde.

.enrollment-flow {
  max-width: 720px;
  padding: 24px;
  border: 1px solid #e5e7eb;
  border-radius: 16px;
  background: #ffffff;
}

.step-label {
  color: #6b7280;
  font-size: 0.95rem;
  font-weight: 700;
  text-transform: uppercase;
}

.button-primary {
  border: 0;
  border-radius: 8px;
  padding: 12px 18px;
  background: #ff4f4f;
  color: #ffffff;
  font-weight: 700;
  cursor: pointer;
}

.button-primary:disabled {
  cursor: not-allowed;
  opacity: 0.75;
}

.flow-status {
  margin-top: 16px;
  font-weight: 700;
}

.flow-status-success {
  color: #157347;
}

.flow-status-error {
  color: #b42318;
}

.flow-status-loading {
  color: #26394d;
}

El flujo tambien debe funcionar con teclado

UX y accesibilidad se cruzan constantemente. Si una persona no puede recorrer la interfaz con teclado, el flujo esta roto. W3C/WAI insiste en criterios como orden de foco y foco visible porque la navegacion no ocurre solo con mouse o pantalla tactil.

En una pantalla simple, revisa al menos esto:

• El orden de tabulacion sigue la logica visual.
• Los botones y enlaces tienen nombres comprensibles.
• El foco visible no se elimina con CSS.
• Los mensajes importantes se comunican cerca de la accion.
• La persona puede recuperarse de un error.

El atributo aria-live="polite", por ejemplo, permite que ciertos cambios de estado sean anunciados por tecnologias de asistencia sin interrumpir agresivamente la experiencia. No reemplaza una buena estructura, pero ayuda cuando la interfaz cambia despues de una accion.

Errores comunes cuando se programa sin flujo

• Empezar por el layout: acomodar columnas antes de entender la tarea.
• Crear botones ambiguos: usar textos como "Aceptar" o "Enviar" sin contexto.
• Olvidar estados vacios: no disenar que pasa cuando no hay datos.
• No mostrar progreso: dejar al usuario sin saber si algo esta cargando.
• Tratar errores como excepciones raras: cuando en realidad forman parte del flujo.

Mini metodo para tus practicas

Antes de crear una pantalla en clase, prueba esta secuencia:

1. Escribe una frase: "El usuario quiere..."
2. Define el resultado esperado: "La tarea termina cuando..."
3. Dibuja entre tres y seis pasos.
4. Marca que podria fallar en cada paso.
5. Convierte cada paso en HTML semantico.
6. Agrega CSS para jerarquia visual.
7. Usa JavaScript solo donde haya interaccion real.

Este metodo evita que el codigo crezca sin direccion. Tambien facilita explicar el proyecto: no solo dices "hice una pagina", sino "disene un flujo para que el usuario complete esta tarea".

Reto practico

Conclusion

UX no significa decorar la interfaz al final. Significa comprender el camino que una persona necesita recorrer. Para estudiantes de desarrollo, esta idea es poderosa porque conecta teoria, codigo y criterio profesional. Una pantalla puede funcionar tecnicamente y aun asi fallar como experiencia si no guia, no responde o no considera el contexto del usuario.

La proxima vez que abras Visual Studio Code, no empieces preguntando que etiqueta usaras. Empieza preguntando quien necesita hacer que cosa y que camino debe seguir para lograrlo. Esa pregunta, sencilla y humana, puede mejorar todo tu codigo.

En el siguiente capitulo trabajaremos accesibilidad basica para interfaces web: estructura, foco, contraste, etiquetas y pequenas decisiones que hacen que una interfaz sea mas usable para mas personas.

Fuentes consultadas

• Nielsen Norman Group: Journey Mapping 101
• W3C WAI: How to Meet WCAG 2.2
• MDN Web Docs: EventTarget.addEventListener()
• MDN Web Docs: aria-live