CommunityImagengithub.com

julien-bloch/ux-review

Realiza críticas independientes, auditorías y pruebas de sitios web, aplicaciones, pantallas, capturas, maquetas HTML, prototipos o implementaciones frontend existentes. Para revisiones de UI/UX, problemas de usabilidad, bugs de interacción, auditorías de jerarquía visual y diseño, comprobaciones de accesibilidad y responsive, recomendaciones priorizadas y comparación de revisiones de diseño.

¿Qué es ux-review?

Esta skill permite a un agente de IA realizar una revisión de experiencia de usuario (UX) independiente y basada en evidencia. Analiza interfaces existentes (screenshots, HTML, aplicaciones funcionales) para identificar obstáculos concretos entre el usuario y su objetivo, no solo desviaciones de preferencias estilísticas. El agente evalúa la claridad de la tarea, la navegación, la jerarquía visual, la accesibilidad, el comportamiento responsive y más, distinguiendo siempre entre evidencia visible, comportamiento probado en navegador, riesgos inferidos y desconocidos. La skill ofrece un flujo de trabajo estructurado que prioriza hallazgos (Crítico, Alto, Medio, Bajo) y recomienda cambios accionables. Compatible con diferentes modos de revisión: estático (screenshot/código) o funcional (aplicación en vivo con herramientas de automatización), incluye reglas estrictas para no alucinar investigación de usuarios ni afirmar resultados sin medición. Es ideal para desarrolladores, diseñadores y equipos de producto que buscan una auditoría UX rigurosa y objetiva.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/julien-bloch/simple-agent-skills/tree/HEAD/skills/ux-review

Installed? Explore more Imagen skills: steipete/songsee, affaan-m/frontend-design, mattpocock/improve-codebase-architecture · View all 6 →

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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

  1. Veredicto: Un párrafo que describe la idoneidad para la tarea indicada; incluye lo que funciona.
  2. Hallazgos prioritarios: Ordenados por gravedad e impacto en el usuario; cada hallazgo sigue ubicación -> etiqueta de evidencia -> consecuencia -> corrección -> verificación.
  3. Conservar: Fortalezas importantes que no deben retroceder accidentalmente.
  4. Desconocidos / pruebas: Separa las decisiones de producto inciertas de los problemas demostrables visualmente.
  5. 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.

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

Skills relacionados