revisión

ultrahand: revisión

Revisa un diseño de UI como lo haría un inspector experto. Recorre cada flujo, interacción y control contrastándolo con los principios de la plataforma, las 10 heurísticas de Nielsen y WCAG 2.2 AA, y luego verifica que el diseño se sostenga en otros tamaños. El resultado es una lista de hallazgos ordenados por severidad. Cada hallazgo nombra el elemento, el principio y su fuente, y ofrece una corrección concreta.

Cada verificación está en references/checklist.md, y cada verificación cita references/sources.md. Para las reglas de la plataforma en profundidad, usa los principios de las skills de diseño: móvil, tablet y escritorio. Para un proyecto con un tema, revísalo con la skill theme-review: uso de tokens, reutilización de componentes y consistencia entre pantallas es su trabajo, no de esta.

1. Obtén el diseño y conoce lo que puede mostrar

Usa la evidencia más rica que el usuario pueda dar. Indica cuál tienes, porque limita lo que puedes confirmar.

• Artefacto canvas de ultrahand (un enlace de artefacto de claude.ai): lee su HTML. Contiene el marcado, las etiquetas, los colores y cada pantalla y estado. Si hay una herramienta de navegador disponible, abre el artefacto. Configura cada vista mediante window.ultrahandCanvas (consulta el README del canvas en shared/canvas/): usePreset(id), setSize(w, h), setScheme('dark'), setTextScale(2), setState('error'), navigate(id). Activa mostrar objetivos táctiles y lee su resultado (#uh-targets-result), que cuenta los objetivos que están por debajo del mínimo de la plataforma. Llama a refresh() después de abrir una hoja o menú para que el recuento lo incluya. El README del canvas enumera los ids de elementos de la barra de herramientas. Los stubs de un prototipo (sin red real, sin teclado en pantalla) van debajo de No verificado, no en los hallazgos. El teclado físico es real: conduce cada flujo con él.
• Compilación local del canvas (un index.html de build.mjs) o cualquier página que puedas abrir: trátala como el artefacto y úsala con el controlador de entrada (paso 4).
• Código (HTML, SwiftUI, Compose, Flutter, etc.): puedes verificar etiquetas, roles, orden de foco, colores y puntos de ruptura, pero no cómo se ve a menos que puedas ejecutarlo.
• Captura de pantalla o maqueta: puedes juzgar diseño, jerarquía, redacción y contraste y tamaños aproximados. No puedes confirmar etiquetas, orden de foco ni comportamiento; marca esos hallazgos como Probable o ponlos bajo No verificado.

Marca la evidencia de cada hallazgo: Confirmado (visto en código o medido en el canvas) o Probable (inferido de una imagen). Nunca presentes una suposición sobre comportamiento oculto como un hecho.

2. Establece el contexto

Escribe esto antes de juzgar cualquier cosa; un hallazgo solo tiene sentido en su contexto.

• Plataforma: iOS, iPadOS, Android, macOS, Windows o la web. Lée la del canvas (size.platform), el código o el estilo visual. Si no está claro, pregunta una vez.
• Tamaño actual: ancho × alto, y la clase de tamaño de ancho: compacto < 600, mediano 600–839, expandido 840–1199, grande 1200–1599, extra grande 1600+. Alto compacto < 480, mediano 480–899, expandido 900+. Anota la orientación y si hay división en paneles.
• Entradas: táctil, puntero, teclado o una mezcla. Una tableta o un portátil táctil pueden tener los tres.
• Usuarios y tarea principal: quién usa cada pantalla y para qué sirve. Pregunta si no puedes inferirlo; una revisión sin tarea se convierte en una lista de opiniones.
• Producto o herramienta: un diseño para usuarios finales, o una herramienta construida para el propietario (el canvas mismo, un editor, un visor). Una herramienta es una aplicación de escritorio que se usa en una ventana del navegador de cualquier tamaño: revísala con las reglas de escritorio y pasa el paso 8. Su interfaz recibe las comprobaciones del paso 7 que enumera el paso 8 (tamaños de ventana, zoom del navegador, sus propios temas), no los preajustes del diseño, y la composición como cualquier pantalla.

Elige las reglas de plataforma según la clase de tamaño de ventana y la entrada, no por el nombre del dispositivo: táctil compacto → principios móviles; mediano y expandido con táctil, o cualquier división en paneles → tablet; ventana con puntero y teclado → escritorio. Un diseño responsivo recibe todos los conjuntos que cubren sus tamaños.

3. Inventaría el diseño

Enumera cada pantalla y estado, cada flujo entre pantallas, las secciones de cada pantalla (barras de herramientas y sus grupos, paneles, encabezados de panel, grupos de formularios, tarjetas, listas, barras), y cada control interactivo en cada sección (botones, enlaces, campos, conmutadores, pestañas, menús, gestos, objetivos de arrastre). El inventario es la cobertura de la revisión: una sección o control que no enumeraste es uno que no verificaste.

Revisa en tres niveles: la pantalla completa, cada sección y cada componente. Una pantalla cuyos controles pasan todos aún puede estar desordenada, desordenada y confusa; eso es un hallazgo en sí mismo, no un detalle de pulido.

4. Inspecciona en pasadas

Trabaja a través de las pasadas en references/checklist.md en orden. Recorre el diseño dos veces: una para aprenderlo, otra para encontrar problemas.

Usa cada control con entrada real, en varios tamaños. Leer el marcado, o llamar a el.click(), dispatchEvent o un setter, salta la prueba de impacto, el foco, las acciones predeterminadas y el encadenamiento de desplazamiento, por lo que un botón cubierto o una rueda atrapada aún se ven bien. Usa la página como lo haría una persona: eventos confiables de mouse, rueda, teclado y táctil desde node "${CLAUDE_PLUGIN_ROOT}/shared/input/drive.mjs" (su README tiene los pasos y recetas), o clics y teclas reales de una herramienta de navegador. El script es solo para configurar una vista y leer el estado después.

• Hazlo en tres tamaños o más: el más grande, uno intermedio y el más pequeño compatible (para un diseño, sus preajustes; para una herramienta, ventanas del navegador como 1440×900, 1024×700 y 640×480).
• En cada tamaño, enumera los controles (controls), luego usa cada uno como se debe usar según su tipo: haz clic o toca, escribe, arrastra y cancela con Escape, haz clic derecho, abre y cierra con el teclado, y desplázate con rueda o deslizamiento sobre cada área de desplazamiento más allá de su final.
• Algunos controles nativos no se pueden manejar con entrada confiable sin cabeza: el menú desplegable de un select, los selectores de archivos y los selectores de color y fecha. Elige la opción de un select con el paso choose del controlador, y enumera el resto bajo No verificado.
• Lee cada resultado: un control que está cubierto, fuera de vista sin forma de alcanzarlo, o que falta en un tamaño; un scrolled que muestra la rueda atrapada; foco perdido en body; errores de página. Cada uno es un hallazgo en ese tamaño.

1. Recorrido de tareas: para cada flujo, haz las cuatro preguntas del recorrido cognitivo en cada paso.
2. Composición: cada pantalla como un todo, luego cada sección, contra las reglas de composición (shared/composition/principles.md). Ejecuta su auditoría en el tamaño más grande y el más pequeño y lee primero la captura de pantalla desenfocada, antes de mirar cualquier control. Al revisar una revisión, compárala también con la versión anterior: qué agregó la ronda, y ¿la pantalla está más recargada por eso?
3. Control por control: cada control del inventario contra las comprobaciones de controles.
4. Heurísticas: cada pantalla contra las 10 de Nielsen.
5. Accesibilidad: WCAG 2.2 AA. Calcula el contraste; no lo calcules a ojo.
6. Plataforma: las reglas para la plataforma y clase de tamaño del paso 2.
7. Redimensionamiento y variantes: cada preajuste, los anchos de división, reflujo a 320, texto al 200%, modo oscuro, cada estado de datos, y en dispositivos táctiles ambas orientaciones y el teclado levantado (las ventanas de escritorio no rotan: verifica la ventana mínima, máxima y corta en su lugar).
8. Herramientas: para una herramienta construida para el propietario, el trabajo permanece visible en cada tamaño de ventana, el escenario se desplaza más allá de sus bordes, el zoom tiene límites, y los atajos y arrastres se comportan.

Registra un problema en el momento que lo veas, con dónde lo viste (pantalla › elemento, más el tamaño, esquema y estado). Un problema que aparece en varios lugares es un hallazgo con varias ubicaciones.

5. Califica la severidad

Usa la escala 0–4 de Nielsen. Pondera cuántos usuarios encuentran el problema, qué tan mal los afecta y si sigue afectando una vez que lo conocen. Consulta la guía de severidad del checklist.

Calificación	Significado
4 Catástrofe	Impide que las personas completen una tarea o pierde sus datos. Arreglar antes del lanzamiento.
3 Grave	Ralentiza o confunde a muchas personas, o falla WCAG AA en un flujo principal. Arreglar pronto.
2 Menor	Ralentiza a algunas personas, o hay una solución alternativa obvia.
1 Cosmético	Pulido. Arreglar si hay tiempo.

No reportes 0. Un fallo de WCAG AA nunca es menor de 2.

6. Reporta

Empieza con un veredicto de un párrafo: la plataforma, los tamaños revisados, la evidencia que tenías, la primera impresión (lo que muestra la pantalla desenfocada, y si la pantalla se lee como organizada o desordenada), los recuentos por severidad y el problema principal. Pondera una superficie primaria desorganizada contra errores en igualdad de términos: ralentiza cada uso, no solo un camino. Luego enumera los hallazgos, primero los de mayor severidad y en orden de flujo dentro de una severidad, usando la plantilla del checklist:

• ID y severidad, p.ej. R3 · 3 Grave
• Elemento: pantalla › sección › elemento (o pantalla › sección, o la pantalla completa, para un hallazgo de composición), y el tamaño, esquema o estado donde se muestra
• Evidencia: Confirmado o Probable
• Problema: qué sale mal para el usuario, en una o dos oraciones
• Principio: la regla que viola, con su clave de fuente (WCAG 1.4.3, NNG-H4, tablet:AND-T2)
• Corrección: un cambio concreto con valores ("sube la etiqueta a #595959 para 7.0:1", no "mejora el contraste")

Cierra con lo que funciona bien (mantenlo breve), lo que no pudiste verificar y por qué (salida del lector de pantalla, dispositivos reales, movimiento), y una nota de que un revisor pasa por alto problemas que otros detectan, por lo que vale la pena un segundo revisor o una prueba de usabilidad.

Si el informe va dirigido a otra persona, ofrécete a publicarlo como un artefacto. Ofrécete a aplicar las correcciones con la skill de diseño ultrahand correspondiente.