Una checklist UI/UX útil no revisa solo pantallas: comprueba que una persona puede terminar su tarea, entender qué ocurre y recuperarse de un error. En esta revisión incluyo accesibilidad, rendimiento, contenido y supervisión de la IA. El diseño no termina cuando el prototipo queda bonito.
La pantalla está terminada. ¿Y la tarea?
Yo no daría el visto bueno a un producto por una colección de pantallas sin errores visuales. Querría ver un recorrido completo: qué necesita hacer la persona, con qué información llega y cómo sabe que ha terminado. Esa diferencia importa. Un formulario puede estar muy bien compuesto y seguir pidiendo datos que nadie entiende para un trámite que no explica su resultado.
Mi propuesta es usar esta checklist como una conversación entre producto, diseño y desarrollo. Cada respuesta debe dejar una prueba, una decisión o un riesgo reconocido. Un sí sin evidencia sirve de poco. Y un no no tiene por qué parar todo: hay que distinguir una mejora estética de un problema que impide pagar, acceder o recuperar información.
El contexto actual añade otra dificultad: generar variantes de interfaz con IA es más fácil que comprobarlas. No me preocupa que salgan muchas propuestas. Me preocupa que su acabado haga pasar una hipótesis por una solución validada. Por eso empezaría por estas nueve decisiones, no por elegir la herramienta de moda.
1. Definir qué significa terminar
Antes de revisar componentes, escribiría la tarea principal en una frase: solicitar una cita, comparar dos planes o recuperar una contraseña. Después añadiría el resultado esperado. En un cambio de suscripción, por ejemplo, no basta con llegar a una pantalla de confirmación: hay que explicar qué plan queda activo, desde cuándo y con qué coste.
La prueba que pediría es sencilla: una persona del público objetivo intenta resolver esa tarea sin recibir instrucciones sobre dónde pulsar. Anotaría dónde duda, qué interpreta mal y si termina. No usaría una revisión experta como sustituto de observar uso real. Son métodos distintos, y Nielsen Norman Group explica por qué una inspección no equivale a una prueba de usabilidad.
2. Diseñar también cuando las cosas van mal
Una checklist UI/UX necesita estados vacíos, carga, error y éxito, además de la pantalla ideal. Añadiría permisos denegados, conexión lenta y sesiones caducadas cuando afecten al recorrido. No para dibujar cada combinación posible, sino para acordar qué conserva el sistema y qué debe hacer la persona.
Pensemos en una solicitud que tarda demasiado. ¿Se puede pulsar dos veces? ¿Se crearían dos solicitudes? ¿El mensaje indica si se ha enviado o solo si se está procesando? Mi criterio sería que la interfaz no obligue a adivinar el estado ni a repetir una acción con consecuencias. Ese comportamiento necesita coordinación con desarrollo, no solo un componente de aviso.
3. Dejar de tratar la accesibilidad como remate
Usaría WCAG 2.2 como referencia técnica y revisaría el nivel exigible al servicio concreto, sin confundir una checklist con una certificación. Entre las incorporaciones de WCAG 2.2 están el foco no totalmente oculto en nivel AA, alternativas a movimientos de arrastre y autenticación accesible. No son detalles que se arreglen cambiando el color al final.
El criterio de tamaño de objetivo de nivel AA parte de 24 por 24 píxeles CSS, con excepciones, incluidas las de separación. No significa que todos los controles deban medir exactamente eso ni que cualquier botón pequeño incumpla automáticamente. En el diseño prefiero dar margen para dedos, movimientos imprecisos y pantallas pequeñas.
Probaría navegación por teclado, foco visible, orden de lectura, etiquetas y mensajes de error. También ampliación del texto y reflujo. Y comprobaría la implementación real: que un prototipo parezca accesible no demuestra que el HTML, los nombres accesibles o la gestión del foco lo sean.
4. Checklist UI/UX del contenido: leer sin mirar el diseño
Quitaría un momento el color y las imágenes. ¿Se entiende la propuesta? ¿Los botones describen su acción? ¿La confirmación cuenta qué va a pasar? Si el texto solo funciona cuando alguien lo explica en una reunión, todavía no está listo.
En español e inglés revisaría significado y longitud, no solo traducción literal. Un título que cabe en una captura puede romperse con una cadena más larga, un nombre real o un ajuste de tamaño de fuente. Las etiquetas y las fechas necesitan contexto. La solución no debería ser recortar información necesaria con puntos suspensivos.
5. Medir respuesta, no solo velocidad de carga
La experiencia también se juega después de que la página aparezca. Interaction to Next Paint, INP, mide capacidad de respuesta a interacciones. La documentación de web.dev considera bueno un INP de 200 milisegundos o menos, evaluado en el percentil 75 de las visitas. Es un criterio técnico, no una garantía de que el producto sea fácil de usar.
Mi revisión incluiría un móvil con recursos limitados, una conexión imperfecta y una tarea completa. Si al abrir un selector la interfaz parece congelada, la portada rápida no compensa esa fricción. Separaría las pruebas de laboratorio de los datos de usuarios reales y dejaría escrito qué falta por medir.
6. Checklist UI/UX del sistema de diseño: reutilizar reglas
Un sistema de diseño debería reducir decisiones repetidas, no convertir cualquier patrón existente en intocable. Revisaría componentes, espaciado, tipografía, contraste y comportamiento. Pero preguntaría también si el componente sigue resolviendo el problema para el que se usa.
El resultado que buscaría es un acuerdo pequeño y utilizable: qué se reutiliza, qué variante hace falta y quién la mantiene. Si una excepción mejora una tarea, se documenta. Si solo añade una preferencia personal, no tiene por qué convertirse en otra variante permanente.
7. Decidir dónde la IA necesita una salida
Cuando hay IA en el producto, distinguiría una sugerencia de una acción ejecutada. Mostrar una propuesta de texto no tiene las mismas consecuencias que enviarla, borrar un archivo o confirmar una compra. La persona debe entender qué se ha hecho y qué sigue pendiente de su decisión.
Pediría mecanismos proporcionales al riesgo: revisar antes de enviar, corregir entradas, conocer límites y volver atrás cuando sea posible. No pondría un aviso genérico como sustituto de ese diseño. Y si la salida puede ser incorrecta, el recorrido debe permitir detectar y corregir el error sin exigir conocimientos que el público no tiene.
8. Elegir qué señal justificaría el lanzamiento
No mediría el éxito solo por clics. Para una tarea concreta observaría finalización, errores, abandonos y solicitudes de ayuda, según lo que se pueda recoger de forma adecuada. Una subida de clics puede significar interés o confusión. Hace falta interpretar el recorrido.
Antes de publicar, definiría qué cambio esperamos ver y qué señal nos haría revisar la decisión. No prometería porcentajes sin datos. Una hipótesis explícita y una medición razonable valen más que un objetivo preciso inventado para completar una presentación.
9. Cerrar la checklist UI/UX con responsables
La última decisión no es visual: quién acepta cada riesgo y quién comprobará el resultado. Dejaría una lista corta con problema, gravedad, evidencia, responsable y siguiente paso. Los bloqueos críticos se corrigen; lo que se pospone tiene una razón y un momento de revisión.
La checklist UI/UX debe ayudar a decidir, no dar una falsa sensación de control. Una casilla marcada no hace que un producto sea accesible, rápido o comprensible. La prueba está en lo que una persona puede hacer con él. Para mí, ese es el cierre de diseño que merece la pena defender.
Preguntas que conviene resolver antes de salir
¿Basta con una auditoría visual? No. Puede detectar problemas, pero no sustituye las pruebas funcionales, la revisión de accesibilidad ni la observación de tareas con usuarios.
¿Hay que cumplir todas las recomendaciones para lanzar? Hay que cumplir los requisitos aplicables y no ocultar riesgos. Las mejoras se priorizan; los fallos que impiden tareas esenciales o causan daño no se justifican con una buena media.
¿Puede la IA hacer esta revisión? Puede ayudar a preparar casos y detectar incoherencias. No tomaría su respuesta como prueba de uso real ni como verificación automática de conformidad.
Fuentes
- W3C: novedades de WCAG 2.2
- W3C: WCAG 2.2
- web.dev: Interaction to Next Paint
- Nielsen Norman Group: UX Expert Reviews (2018)
Esta checklist UI/UX conecta con mi enfoque de diseño de producto: revisar la tarea, la interacción y la forma de medir el resultado.
