Cuando llevo un rato trabajando en una interfaz, empiezo a usarla de memoria. Sé dónde está cada botón y qué tiene que pasar después. Ahí hay una trampa: puedo confundir que yo la entiendo con que resulta fácil de usar.
Para salir de esa costumbre me sirve revisar tareas concretas. En un portafolio, por ejemplo: encontrar un proyecto, entender qué hice y llegar al contacto. En un journal: elegir una lectura, seguirla y compartirla.
Estas son las estrategias que tomo como punto de partida para una revisión sencilla. También explico dónde puede ayudarme la IA a organizarla. Es una pauta de trabajo, no un informe de pruebas con usuarios.
Empezar por una tarea y definir cuándo termina
«Revisar el sitio» es demasiado amplio. Prefiero algo como «abrir una publicación y copiar su enlace». Tiene un inicio, una acción y un resultado que puedo comprobar.
Para ese recorrido anoto tres cosas: qué necesita encontrar la persona, qué respuesta debería recibir y cómo puede continuar si algo falla. Así la revisión baja a comportamientos observables.
Por ejemplo, pulsar un icono de compartir no basta para dar la tarea por terminada. Si se copia el enlace, necesito una confirmación. Si el navegador no permite copiarlo, necesito una alternativa que deje recuperar la URL.
Hacer visibles los estados de la interfaz
Una petición puede estar pendiente, terminar sin resultados o fallar. Si esos estados se ven iguales, obligo a quien usa la página a adivinar qué pasó.
En código conviene representarlos explícitamente. Un estado como idle | loading | success | empty | error puede ser más claro que varias variables booleanas que permiten combinaciones contradictorias. No todas las interacciones necesitan los cinco: el modelo debe corresponder a lo que realmente ocurre.
Después reviso qué muestra cada estado. Un error debería explicar qué falló y ofrecer una acción útil, como reintentar. En una operación asíncrona puedo anunciar una confirmación mediante una región role="status", sin mover el foco de forma inesperada. Esa respuesta también necesita una comprobación manual.
Reducir lo que hay que recordar
Una navegación consistente, etiquetas claras y una sección activa ayudan a orientarse. Son detalles pequeños hasta que desaparecen y hay que reconstruir el recorrido de memoria.
En el journal, el índice activo puede indicar qué parte del artículo estoy leyendo. En un listado, conservar los filtros al volver desde un detalle evita tener que configurarlos otra vez. Este segundo caso es un ejemplo de diseño, no una función que esté afirmando que ya tiene mi portafolio.
Tomo como referencia las heurísticas de Nielsen, especialmente visibilidad del estado, consistencia y reconocimiento antes que recuerdo. Me sirven para formular preguntas concretas sobre una pantalla.
Diseñar también la vuelta y el error
Abrir un modal es solo una parte del recorrido. También reviso cómo cerrarlo, dónde queda el foco después y si puedo continuar donde estaba. Un botón de cancelar debería tener un efecto predecible.
En formularios, una revisión útil es provocar un error: enviar un campo vacío o un formato incorrecto. Quiero ver una explicación junto al campo, conservar lo que ya escribí y saber cómo corregirlo. Son casos para probar, no resultados medidos de este sitio.
Empiezo por los problemas que bloquean la tarea. Después atiendo los que generan dudas o esfuerzo adicional. Un ajuste visual puede esperar si antes hay una acción que no se puede completar.
Pedir a la IA una revisión con límites claros
Aquí puedo apoyarme en una skill de revisión de UI o accesibilidad. Una skill aporta instrucciones y criterios para guiar al asistente; el alcance real depende de las herramientas y la información a las que tenga acceso.
Le daría una tarea concreta, la ruta y el contexto. Por ejemplo:
Revisa el recorrido para abrir una entrada y copiar su enlace, en móvil y escritorio. Por cada posible problema indica el paso, la evidencia observable, a quién afecta y una corrección pequeña. Separa lo comprobado de las hipótesis. Si solo puedes leer el código, acláralo.
Con ese encargo puedo pedirle que organice hallazgos o proponga casos de prueba. Si señala un problema, necesito reproducirlo. Una revisión del código puede sugerir un riesgo, pero no equivale a observar la interacción en el navegador.
Combinar herramientas y volver a recorrer la tarea
Lighthouse genera informes sobre aspectos como rendimiento y accesibilidad. axe DevTools ayuda a detectar problemas de accesibilidad y a guiar su revisión. Uso sus resultados como pistas técnicas; una puntuación no describe por sí sola lo fácil que resulta completar una tarea.
Para una primera pasada propondría elegir un recorrido, ejecutar las comprobaciones disponibles y repetirlo manualmente en una pantalla estrecha y con teclado. Después guardaría cada hallazgo con su ruta, pasos, resultado esperado y resultado observado.
La IA puede ayudarme a ordenar esas notas y preparar una corrección. La comprobación final sigue siendo volver al mismo recorrido y ver qué cambió. Si necesito saber cómo lo entiende otra persona, el siguiente paso es observar a alguien intentando completar la tarea.
UNA IDEA PARA COMPARTIR
