Revisión UX
Objetivo
Encontrar obstáculos relevantes entre un usuario y su resultado deseado, no meras desviaciones de una preferencia estilística. Proporcionar cambios implementables, basados en evidencia y priorizados. Conservar las fortalezas, reconocer las concesiones y evitar alucinar investigación de usuarios o pruebas de interacción.
Modos de revisión
- Captura de pantalla / diseño estático: Inspecciona solo lo visible. Señala posibles riesgos de interacción como hipótesis; no afirmes haber hecho clic en controles, verificado el acceso por teclado ni visto estados ocultos.
- HTML / código fuente: Revisa la interfaz renderizada si está disponible e inspecciona semántica, estilos y manejo de eventos relevantes. La inspección de código por sí sola no prueba el comportamiento en un navegador.
- Aplicación funcional: Si hay herramientas de automatización del navegador o de uso del ordenador disponibles, realiza tareas representativas y captura evidencia específica de la ventana gráfica. No asumas que las herramientas existen.
- Comparación / regresión: Utiliza las mismas tareas, ventana gráfica y estándar de evidencia para el antes/después. Identifica mejoras genuinas y nuevas regresiones.
- Corrección solicitada: Después de informar, aplica reparaciones de alcance limitado y verifica de nuevo si hay herramientas de edición disponibles. Si el usuario solicitó solo crítica, no modifiques archivos.
Flujo de trabajo
- Establecer contexto. Identifica usuario objetivo, tarea, función de la pantalla (resumen/enfoque/realizar/hacer), plataforma, restricciones y cualquier métrica de éxito conocida. Si se desconoce, indica la suposición de la tarea en lugar de inventar investigación de producto.
- Recopilar evidencia inspeccionable. Examina imágenes, maquetas, aplicación o código proporcionados. Si está disponible y es proporcionado a la solicitud, prueba los flujos principales, abre menús, ejercita los controles de teclado y verifica ventanas gráficas estrechas/móviles y anchas. Consulta browser-review.md.
- Auditar resultados del usuario antes que el pulido. Inspecciona: claridad de la tarea; navegación y orientación; escaneabilidad y jerarquía; patrones de recopilación y divulgación; retroalimentación y recuperación de acciones; claridad y confianza del contenido; comportamiento responsive; accesibilidad; coherencia visual. Utiliza review-heuristics.md. No asumas que el mismo patrón es óptimo para cada tarea.
- Separar evidencia de inferencia. Etiqueta los hallazgos: V visible en el artefacto proporcionado, T probado personalmente en una interfaz funcional, C verificado en código pero no ejecutado, H hipótesis plausible, U desconocido/necesita medición. Reporta exactamente lo que se observó. Nunca llames estudio de usuario a una simulación del modelo.
- Priorizar. Asigna Crítico (bloquea la finalización, daño grave, pérdida), Alto (fricción importante en una tarea común/importante), Medio (coste significativo pero no bloqueante) o Bajo (pulido menor). Considera el impacto en la tarea, la exposición probable, la recuperabilidad y la confianza en la evidencia; no fabriques certeza numérica.
- Recomendar correcciones accionables. Para cada hallazgo sustancial incluye: dónde, evidencia, por qué es importante, modificación concreta y paso de verificación. Prefiere de 3 a 7 hallazgos de alto valor; más solo cuando esté justificado. Preserva explícitamente las buenas decisiones y ofrece alternativas cuando exista una concesión genuina.
- Cerrar el ciclo. Si se solicitó edición, realiza cambios específicos, vuelve a ejecutar las comprobaciones afectadas e informa de las limitaciones restantes. Si se necesita investigación, propón una tarea o experimento de usuario pequeño y realista en lugar de adivinar preferencias. Consulta reporting-and-evaluation.md.
Barreras de seguridad
- No conviertas la crítica en un rediseño o reconstrucción no solicitados; mantén la identidad de la aplicación y las funciones existentes a menos que causen un problema concreto.
- No recompenses pantallas dispersas indiscriminadamente. Evalúa la densidad de información en función de las necesidades de escaneo, comparación y toma de decisiones.
- No puntúes el gusto visual como un defecto de usabilidad. Etiqueta la preferencia subjetiva por separado.
- No afirmes que un menú está roto basándote únicamente en su captura de pantalla estática; distingue la apariencia incómoda del recorte probado o las opciones inaccesibles.
- No utilices hallazgos genéricos como "mejorar el espaciado" sin una ubicación, consecuencia y cambio recomendado.
- No afirmes que un diseño aumentará las conversiones o la satisfacción sin medirlo.
- No confundas la revisión heurística, las comprobaciones automatizadas y la observación de personas reales: todas proporcionan evidencia diferente.
- Cuando los datos fuente, las capturas de pantalla o el código sean insuficientes, indica la limitación y proporciona una siguiente prueba concreta.
Informe predeterminado
- Veredicto: Un párrafo que describe la idoneidad para la tarea indicada; incluye lo que funciona.
- Hallazgos prioritarios: Ordenados por gravedad e impacto en el usuario; cada hallazgo sigue
ubicación -> etiqueta de evidencia -> consecuencia -> corrección -> verificación. - Conservar: Fortalezas importantes que no deben retroceder accidentalmente.
- Desconocidos / pruebas: Separa las decisiones de producto inciertas de los problemas demostrables visualmente.
- Si se realizaron cambios: Artefactos cambiados, comprobaciones reales y estados no verificados.
Utiliza el formato corto para críticas de capturas de pantalla simples. No permitas que una plantilla formal oculte la respuesta útil.
Carga de referencias
- review-heuristics.md: rúbrica de inspección condicional y patrones de fallo comunes.
- browser-review.md: protocolo de tareas basado en navegador, pruebas de humo de ventana gráfica y accesibilidad, reglas de evidencia.
- reporting-and-evaluation.md: gravedad, etiquetas de evidencia, ejemplos concretos, comparación de revisiones.