UX, UI y usabilidad: diferencias al diseñar con IA

Le pides a la IA «una pantalla para reservar citas médicas, moderna y limpia». En segundos te entrega algo que se ve listo: un calendario, una lista de horarios y un botón para continuar. Pero que se vea bien no significa que funcione.

Para llenar los vacíos del pedido, la IA tuvo que suponer tres cosas: para quién es la pantalla, cómo responde cada elemento y si alguien puede terminar de reservar. Cada supuesto corresponde a un concepto que solemos mezclar: UX, UI y usabilidad.

En resumen:

• UX: todo lo que vive la persona antes, durante y después de usar la pantalla.

• UI: los elementos con los que interactúa y cómo responde cada uno.

• Usabilidad: si la persona logra su objetivo, con cuánto esfuerzo y cómo se siente al hacerlo.

Este artículo acompaña el primer episodio de Back to Basics, una serie sobre fundamentos de UX/UI para trabajar con IA. El caso es ficticio: una app de citas médicas construida como prototipo para ilustrar las ideas. No describe un proyecto ni resultados reales.

1. Lo que la IA supone cuando el pedido es general

Nielsen Norman Group analizó cómo funcionan las herramientas de IA para prototipar en contextos de diseño reales, en el artículo Good from Afar, But Far from Good. Una de sus conclusiones es que, con instrucciones generales, la IA hace suposiciones y los resultados varían mucho. No es un fallo puntual del modelo: es lo que pasa cuando el pedido deja decisiones abiertas.

En nuestro ejemplo, una respuesta posible muestra nueve horarios libres y un botón «Continuar» siempre activo. Se ve ordenada, pero esconde tres supuestos:

• UX, para quién es: la IA no sabe quién reserva, desde dónde ni qué necesita después.

• UI, cómo responde: todo aparece libre y el botón avanza aunque no hayas elegido una hora.

• Usabilidad, si se puede completar: nadie comprobó si una persona logra reservar.

Lo que no le dices, la IA lo supone. Los fundamentos sirven para llenar esos vacíos antes de generar y para revisar el resultado después.

2. UX: la experiencia va más allá de la pantalla

La norma ISO 9241-210 describe la experiencia de usuario como las percepciones y respuestas de una persona antes, durante y después de usar un producto o servicio. Don Norman y Jakob Nielsen piden distinguirla de la interfaz: la UX abarca toda la relación con el servicio, no solo lo que se ve en pantalla.

En una reserva de cita, el recorrido tiene tres tramos:

• Antes: la persona necesita una cita de medicina general y busca dónde pedirla.

• En la app: elige un horario, revisa fecha, hora, sede y precio, y confirma.

• Después: necesita saber qué sigue: si recibirá un recordatorio, cómo llegar y cómo cambiar o cancelar la cita.

Si la confirmación solo dice «Reserva exitosa», la experiencia falla aunque la interfaz sea impecable. La persona se queda con preguntas que la pantalla no responde: ¿me lo van a recordar?, ¿dónde es exactamente?, ¿qué hago si no puedo ir?

Una buena confirmación cierra el recorrido: repite lo que se reservó, permite añadirlo al calendario, explica cómo llegar y dice cómo cambiar o cancelar.

3. UI: cómo responde cada elemento

La UI es lo que permite interactuar: botones, campos, listas y mensajes. Diseñarla no es solo decidir cómo se ve cada elemento, sino cómo responde.

Un horario en un selector pasa por tres momentos:

• Antes de tocar: se ve qué horas están libres y cuáles no. Una hora ocupada aparece tachada y no se puede elegir.

• Al tocar: la ficha responde al instante, para confirmar que el toque llegó.

• Al soltar: la hora queda elegida, con un ícono de verificación y no solo con un cambio de color, y se activa «Continuar».

Si no defines esos estados, la IA los inventa o los omite. El botón activo sin una hora elegida es un problema de UI: un estado que nadie decidió.

Lo mismo pasa con los estados menos visibles: mientras carga, cuando no hay horarios o cuando una hora se ocupa justo al confirmar. Un pedido que no los menciona deja que la IA dibuje solo el camino en el que todo sale bien.

4. Usabilidad: ¿la persona logra lo que vino a hacer?

La norma ISO 9241-11, recogida por el NIST, define la usabilidad con tres medidas: eficacia, eficiencia y satisfacción, siempre para personas, objetivos y contextos concretos. En lenguaje claro: si la persona logra la tarea, con cuánto esfuerzo y cómo se siente al hacerlo.

Un ejemplo: para reservar, escribes un número de celular incompleto y tocas «Continuar». Hay dos formas de responder:

• Borrar todo: aparece un aviso de que faltan la fecha y la hora, y los campos quedan vacíos. Tienes que repetir trabajo que ya habías hecho.

• Conservar los datos: la fecha y lo que escribiste se mantienen, y solo el celular queda marcado con un mensaje concreto: «Faltan 2 dígitos».

El sistema de diseño de GOV.UK recomienda la segunda: decir qué falló y cómo corregirlo, y no borrar lo que la persona ya escribió.

Que una pantalla se vea bien no demuestra que sea fácil de usar. La usabilidad no se adivina mirando la pantalla: se comprueba viendo a personas usarla.

5. Convierte los fundamentos en un pedido

Con estos tres conceptos, el mismo pedido se escribe de otra forma. En lugar de «moderna y limpia», dile a la IA para quién es, qué estados debe tener, qué no puede inventar y cómo vas a saber que funciona.

Este es el pedido completo del caso, dividido en cuatro partes:

• Objetivo: una pantalla para reservar una cita médica desde el celular.

• Contexto: medicina general en la Sede Norte. Usa los botones y estilos que ya tiene el proyecto.

• Estados: qué pasa mientras carga, si no hay horarios, si una hora está ocupada o se ocupa al confirmar, si la persona se equivoca y, al confirmar, dónde es y cómo cambiarla o cancelarla.

• Restricciones: no inventes datos clínicos ni precios. Que se pueda usar solo con teclado.

Cada parte responde a un supuesto. El objetivo y el contexto cubren la UX, los estados cubren la UI y las restricciones ponen límites que puedes revisar. El resultado no es una pantalla terminada: es una pantalla lista para probar. Si además la IA forma parte del producto, en Diseñar productos con IA: control, confianza y recuperación explico cómo darle control a la persona.

6. Revisa la pantalla como lo haría la persona

Después de generar, recorre la interfaz. Revisar no es mirar la pantalla, es usarla. Repite el recorrido en el móvil, en el escritorio y solo con el teclado. Si la pantalla ya está en código, en Prototipos en código: qué validar antes de entregar una interfaz detallo qué más revisar.

Checklist antes de dar por buena una pantalla hecha con IA

• ¿Puedo completar la reserva en el móvil y en el escritorio?

• ¿Entiendo qué seleccioné y qué ocurrirá después?

• ¿Puedo corregir un error sin perder mis datos?

• ¿Llego a todo con la tecla Tab y siempre veo qué está seleccionado?

• ¿La confirmación coincide con lo que realmente ocurrió?

Si alguna respuesta es «no», la pantalla no está terminada. Y aunque todas sean «sí», esta revisión no reemplaza ver a personas reales intentando reservar. Esa sigue siendo la mejor evidencia.

Como resume Nielsen Norman Group en State of UX 2026: “The fundamentals of good UX won’t change.” La IA puede ayudarte a construir. Los fundamentos te ayudan a decidir qué construir y cómo evaluarlo.

¿Cuál de los tres conceptos se te escapa más cuando revisas una pantalla hecha con IA? Te leo en LinkedIn.

Fuentes

1. ISO (2019). ISO 9241-210:2019. Human-centred design for interactive systems. Norma internacional.

2. Norman y Nielsen. The Definition of User Experience (UX). Nielsen Norman Group.

3. ISO 9241-11:2018, recogida por NIST. Usability. Glosario del NIST Computer Security Resource Center.

4. GOV.UK Design System. Error message y Validation.

5. Wang y Brown (2025). Good from Afar, But Far from Good: AI Prototyping in Real Design Contexts. Nielsen Norman Group.

6. Moran, Budiu, Gibbons y otros (2026). State of UX 2026: Design Deeper to Differentiate. Nielsen Norman Group.