Lista de verificación para la revisión de UI con IA: pruebe las interfaces generadas antes del lanzamiento

No comience haciendo clics al azar y recopilando impresiones. Primero defina qué puede demostrar esta revisión. Sin ese contrato, los revisores tienden a inventar requisitos, tratar el gusto personal como un defecto o aceptar una pantalla atractiva cuya tarea principal nunca se completa.

• Tarea del usuario: Indique el resultado en términos del usuario, como «invitar a un compañero y ver la confirmación», en lugar de «revisar la página de ajustes».
• Requisitos del producto: Enumere las acciones aprobadas, permisos, datos, reglas de validación, confirmaciones, comportamiento de cancelación y rutas de recuperación aplicables.
• Autoridad de diseño: Indique el DESIGN.md, el conjunto de design tokens, el archivo de tema, la guía de componentes, el kit de referencia o el diseño aprobado exacto que rige la interfaz.
• Artefactos de entrega: Registre cómo llegan esas decisiones al proyecto, como variables CSS, valores de tema de Tailwind, tokens DTCG, un elemento del registro de shadcn/ui o archivos generados.
• Plataformas y viewports: Incluya solo los navegadores, dispositivos, anchos de contenedor y modos de color que el producto soporte.
• Fixtures de contenido: Prepare ejemplos realistas cortos, típicos, largos, vacíos, inválidos y restringidos según corresponda.
• Estados requeridos: Nombre los estados de inactividad, carga, éxito, vacío, error, deshabilitado, foco, seleccionado, abierto y de permisos que la tarea puede alcanzar realmente.
• Exclusiones: Registre el trabajo que queda fuera de este lanzamiento para que su ausencia no se confunda con un defecto.

Una interfaz generada puede pasar un tipo de revisión y fallar en otro. Mantenga la evidencia separada para que un resultado visual sólido no oculte una tarea rota, y una tarea funcional no excuse una implementación inaccesible o frágil.

Comience desde el resultado del usuario y recorra cada rama requerida. Una prueba aprobada describe un comportamiento observable, no una impresión.

• La acción principal es visible o localizable en el punto donde el usuario la necesita.
• Las etiquetas describen la acción resultante en lugar de una intención vaga.
• La navegación preserva el contexto del usuario donde el requisito indica que debe hacerlo.
• La validación identifica el campo o acción afectada y ofrece al usuario un posible siguiente paso.
• El éxito produce la confirmación requerida o el cambio de estado.
• La cancelación deja los datos y la navegación en la condición esperada.
• Las restricciones de permisos impiden la acción y explican qué puede hacer el usuario a continuación.
• Los flujos de carga, estados vacíos, fallos, reintentos y recuperación funcionan cuando están dentro del alcance.
• La interacción por teclado puede alcanzar y operar los controles de la tarea donde el uso del teclado esté soportado.

Redacte los criterios de aceptación como observaciones. Por ejemplo: "Al enviar una invitación válida, se desactiva el envío duplicado, se muestra el progreso, se devuelve un mensaje de éxito con la dirección invitada y se añade el miembro pendiente a la lista". Esto se puede comprobar. "El flujo de invitación resulta intuitivo" no se puede comprobar.

Rastree las decisiones visibles hasta la autoridad declarada. Compruebe los colores semánticos, los roles tipográficos, el espaciado, el diseño, los motivos, el tratamiento de los componentes y el comportamiento del modo. Registre los valores no explicados, pero no asuma que cada diferencia es un error. Una excepción local puede ser intencionada, estar obsoleta o no figurar en el sistema.

• Roles semánticos: Los componentes utilizan roles como background, foreground, primary, border, ring, success, warning y destructive para sus significados previstos.
• Tipografía: Los roles de heading, body, label, data y mono utilizan las familias, pesos, tamaños, alturas de línea y reglas de mayúsculas/minúsculas declaradas.
• Espaciado: Los huecos repetidos siguen la escala documentada, a menos que exista una excepción aprobada.
• Diseño: El ancho de página, la cuadrícula, la alineación, la densidad y las transiciones adaptables coinciden con las reglas declaradas.
• Componentes: Los botones, inputs, tarjetas, tablas, navegación, superposiciones y tratamientos de feedback utilizan las variantes y estados previstos.
• Modos: Los valores claros y oscuros mantienen el mismo significado semántico, y las excepciones específicas del modo están documentadas.
• Motivos: Los tratamientos decorativos aparecen solo donde la autoridad lo permite y no interfieren con el significado o la interacción.
• Valores hardcoded: Los colores únicos, las declaraciones de fuentes, los radios, las sombras y los valores de espaciado tienen una razón documentada o se derivan para su corrección.

Sustituya el contenido provisional por datos de prueba que pongan a prueba el diseño real. Revise la misma tarea en los viewports y estados requeridos en lugar de juzgar capturas de pantalla independientes como composiciones aisladas.

• Utilice nombres, fechas, precios, estados, descripciones y densidad de datos realistas.
• Pruebe etiquetas largas y textos con longitudes traducidas sin cambiar el significado previsto.
• Compruebe los diseños estrechos y anchos en los tamaños de contenedor o viewport soportados.
• Verifique el ajuste de línea (wrapping), el truncamiento, el desbordamiento (overflow), las regiones fijas (sticky), las superposiciones y el comportamiento del scroll.
• Aumente el zoom o el espaciado de texto del usuario y registre recortes, solapamientos, pérdida de contenido o controles bloqueados.
• Utilice cada modo de color declarado y cualquier configuración de colores forzados soportada.
• Inspeccione los estados de focus, hover, active, selected, disabled, open, loading, empty, error y success que la tarea pueda alcanzar.
• Repita la tarea con datos lentos o fallidos donde el producto soporte esas condiciones.

El modo de colores forzados merece su propia observación cuando está soportado. Los navegadores pueden sustituir los colores definidos por una paleta seleccionada por el usuario, por lo que el significado que reside solo en un relleno, borde o sombra personalizados puede desaparecer. Registre lo que sigue siendo perceptible en lugar de asumir que el tema ordinario predice el resultado.

Utilice esta revisión para identificar problemas y recopilar evidencias, pero mantenga la afirmación delimitada. La inspección visual, la conformidad de los tokens, las comprobaciones automatizadas y la crítica de la IA pueden encontrar problemas. Ninguna de ellas por sí sola certifica la accesibilidad.

• Registre el orden del teclado, la visibilidad del foco, la operación de los controles y el comportamiento del foco en las superposiciones.
• Compruebe que los nombres de los controles, las etiquetas visibles, las instrucciones, los errores y los cambios de estado sean comprensibles en contexto.
• Verifique que la información no se transmita únicamente mediante el color o la posición visual.
• Observe el comportamiento de reflow, zoom y espaciado de texto del usuario en las superficies requeridas.
• Pruebe el contenido y los controles relevantes en configuraciones de alto contraste o colores forzados soportadas.
• Envíe el marcado semántico, el comportamiento de la tecnología asistiva, las mediciones de contraste y las preguntas formales de conformidad al canal de revisión basado en evidencias correspondiente.

Elija superficies del producto que esté revisando. Una landing page puede necesitar navegación, un formulario y feedback. Una aplicación también puede necesitar vistas de datos, vistas de detalle, superposiciones y estados de permisos. Omita las superficies que el producto no utilice.

1. 1

   Seleccione una tarea de usuario

   Defina un resultado y la condición de inicio exacta. Mantenga la tarea lo suficientemente acotada para poder repetirla.

2. 2

   Seleccione una superficie y un estado representativos

   Elija la navegación, el formulario, la vista de datos, la vista de detalle, la superposición o el estado de retroalimentación que tenga la mayor consecuencia o exponga una regla del sistema distintiva.

3. 3

   Aplique un entorno de prueba fijo

   Registre el viewport, el modo, el contenido, el estado de la cuenta o los permisos y la condición de los datos. Reutilice este entorno después de realizar cambios.

4. 4

   Escriba el resultado esperado antes de la inspección

   Cite el requisito o la regla de diseño y describa el resultado observable. Si no existe una autoridad, deténgase y derive la brecha.

5. 5

   Capture la observación y la evidencia

   Registre qué sucedió, dónde sucedió y la captura de pantalla, grabación, observación del DOM, salida de consola o resultado de prueba más pequeño necesario para reproducirlo.

6. 6

   Asigne severidad, responsable y disposición

   Elija entre aprobado, revisar o bloquear. Derive la causa a la capa correcta en lugar de asignar cada problema a la implementación generada.

Review ID: UI-REVIEW-____
Build or revision: ____
Reviewer: ____
Date: ____

User task: ____
Start condition: ____
Required outcome: ____
Surface: ____
Required state: ____
Viewport or container: ____
Color mode: ____
Input and content fixture: ____
Permission or account fixture: ____

Requirement authority: ____
Design-system authority: ____
Delivery artifact: ____
Expected rule or behavior: ____
Observed result: ____
Evidence reference: ____

Evidence track:
  - task completeness: pass | fail | not tested
  - design-system conformance: pass | fail | not tested
  - resilience: pass | fail | not tested
  - accessibility: pass | concern | not tested

Finding route: requirement | design system | delivery mapping | implementation | fixture
Severity: low | medium | high | release blocking
Owner of next decision: ____
Known limitation: ____
Disposition: pass | revise | block
Retest required: yes | no
Retest result: ____

Un defecto visible suele ser consecuencia de un punto anterior que necesita cambiar. Corregir la regla CSS más cercana puede hacer que una pantalla pase la prueba, pero mantiene el mismo fallo para la siguiente generación.

• Brecha de requisitos de producto: El comportamiento previsto, el permiso, la regla de contenido, la confirmación, la cancelación o la ruta de recuperación faltan o son contradictorios. Ejemplo: nadie ha decidido si eliminar un miembro requiere confirmación. Siguiente responsable: responsable de decisiones de producto.
• Brecha de origen del sistema de diseño: El requisito está claro, pero el sistema autoritativo carece de un rol o regla necesaria para expresarlo de manera coherente. Ejemplo: las acciones de advertencia y destructivas no tienen un tratamiento documentado distinto. Siguiente responsable: responsable del sistema de diseño.
• Brecha de entrega o mapeo: El origen contiene la decisión correcta, pero el token exportado, el mapeo del framework, el elemento del registro, el archivo de tema o el artefacto instalado la pierde o la asigna incorrectamente. Ejemplo: el origen define un rol de anillo de enfoque, pero el tema entregado mapea el componente a un rol de borde. Siguiente responsable: responsable del artefacto o de la integración.
• Defecto de implementación generada: Los requisitos y las reglas entregadas son suficientes, pero la interfaz generada los ignora, los anula o los implementa incorrectamente. Ejemplo: un botón tiene hardcodeado un color en lugar de usar el rol destructivo entregado. Siguiente responsable: responsable de la implementación u operador del agente de código.
• Entorno de revisión inválido: La expectativa utiliza datos no compatibles, una plataforma excluida, un estado de cuenta incorrecto, una compilación obsoleta o una superficie fuera del contrato de lanzamiento. Ejemplo: un revisor espera una acción de administrador mientras prueba una cuenta de solo lectura. Siguiente responsable: revisor o responsable de la prueba.

Si más de una capa contribuyó, nombre el fallo autoritativo más temprano como la ruta principal y enumere los defectos derivados por separado. Esto evita que un parche local oculte una decisión ausente.

La inspección muestra si la instantánea actual parece conectada a su sistema. Un cambio controlado prueba si esa conexión sigue funcionando. Cambie una decisión delimitada en la autoridad declarada, propáguela a través de la ruta de entrega normal y verifique tanto la actualización prevista como los valores no relacionados.

1. 1

   Elija una decisión semántica

   Use un rol reversible y estrictamente delimitado, como el fondo de advertencia, el anillo de enfoque, el peso del encabezado o el paso de espaciado compacto. No combine varias ediciones.

2. 2

   Registre el estado anterior

   Capture el valor autoritativo, el valor entregado, los consumidores previstos, el entorno representativo y algunos valores cercanos que deban permanecer sin cambios.

3. 3

   Cambie la autoridad declarada

   Realice el cambio donde el equipo indique que pertenece la decisión. Editar el componente renderizado directamente no prueba la propagación.

4. 4

   Ejecute la ruta de entrega normal

   Regenere, exporte, instale o aplique el artefacto de la misma manera en que el proyecto recibe normalmente las decisiones de diseño.

5. 5

   Verifique la cadena

   Confirme que la autoridad, el artefacto de entrega y el consumidor de la interfaz previsto contengan la nueva decisión.

6. 6

   Busque desviaciones no relacionadas

   Compare los roles vecinos registrados y las superficies representativas. Cualquier cambio no explicado hace que la prueba falle, incluso si el objetivo cambió correctamente.

7. 7

   Restaure o apruebe el valor de la prueba

   Trate el cambio como una prueba a menos que el responsable lo apruebe como la nueva decisión de diseño. Registre el estado final en la revisión.

• Aprobado: Cada tarea requerida y estado representativo cumple sus criterios observables; las diferencias de conformidad están explicadas; las comprobaciones de resiliencia requeridas tienen evidencia; las limitaciones de accesibilidad son explícitas; no queda ningún hallazgo no resuelto que bloquee el lanzamiento.
• Revisar: La autoridad está clara y el defecto está delimitado, es reproducible, tiene un responsable y es seguro volver a probarlo antes del lanzamiento. El registro indica el entorno de prueba fallido y el resultado esperado.
• Bloqueo: Una tarea obligatoria falla; una acción destructiva o irreversible se comporta de manera ambigua; los permisos son incorrectos; la recuperación no está disponible cuando es necesaria; el requisito rector o la autoridad de diseño no se han resuelto; falta evidencia para un estado crítico para el lanzamiento; o el cambio controlado revela una propagación rota o una deriva no relacionada.

La severidad debe describir la consecuencia, no la prominencia visual. Un error de permisos sutil puede bloquear el lanzamiento. Un desajuste de espaciado evidente puede tener una severidad baja si no perjudica la tarea y el responsable del diseño lo acepta.

Identity Forge puede proporcionar entradas declaradas para este proceso: design tokens semánticos de colores claros y oscuros, tipografía, guías de espaciado y diseño, motivos, reglas de uso, DESIGN.md y formatos de entrega como Tailwind, DTCG y artefactos orientados a shadcn/ui. Estas entradas reducen la ambigüedad al preguntar si la UI generada sigue el sistema elegido.

No proporcionan requisitos de producto, el comportamiento final de los componentes, una auditoría de UI completada ni pruebas de que una interfaz sea accesible o esté lista para producción. Tampoco deciden si una diferencia es una excepción aprobada. Ese juicio recae en las personas responsables del producto, el sistema de diseño, la implementación y el lanzamiento.

Si un proyecto no tiene una autoridad de diseño declarada, establezca una antes de reclamar la conformidad. Las guías relacionadas sobre sistemas de diseño para agentes de código de IA, DESIGN.md y design tokens semánticos de color explican las posibles entradas. El método de revisión en sí es independiente de la herramienta.

• La tarea del usuario revisada, la condición inicial y el resultado requerido están documentados.
• Las autoridades de requisitos y del sistema de diseño están nombradas y versionadas o son identificables de otro modo.
• Los artefactos de entrega y las plataformas compatibles están registrados.
• El contenido representativo, los permisos, los modos, los viewports y los estados requeridos están definidos.
• Las rutas principales, de cancelación, confirmación, error y recuperación funcionan donde es necesario.
• Los colores semánticos, la tipografía, el espaciado, el diseño, el tratamiento de los componentes, los motivos y los modos se rastrean hasta la autoridad declarada o una excepción aprobada.
• Existe evidencia de contenido extenso, diseños estrechos, zoom o espaciado de texto, operación por teclado y estados no predeterminados relevantes.
• Las preocupaciones de accesibilidad y las áreas no probadas son explícitas; ninguna revisión visual o de IA se presenta como una certificación.
• Cada hallazgo se deriva a los requisitos, la fuente del sistema de diseño, el mapeo de entrega, la implementación o la configuración.
• Un cambio autoritario controlado llega a su artefacto y consumidor previstos sin derivas no relacionadas.
• Cada problema no resuelto tiene una severidad, un responsable de la siguiente decisión y una condición de re-prueba.
• El registro de lanzamiento finaliza con aprobado, revisar o bloquear, en lugar de un comentario de aprobación vago.

Para la próxima revisión, elija una tarea crítica para el lanzamiento y complete el registro antes de inspeccionar el resto de la interfaz. Si no se puede nombrar el comportamiento esperado o la autoridad de diseño, deténgase ahí y gestione esa brecha. Más capturas de pantalla no resolverán la falta de una decisión.

• 7-point checklist to review any AI-generated UI: El artículo capturado explica que las pantallas generadas por IA con un acabado pulido pueden ocultar una lógica débil y decisiones de producto faltantes, por lo que el acabado visual no debe tratarse como preparación para el lanzamiento.
• AI Generated UI Quality Checklist: La lista de verificación recomienda revisar la jerarquía, la consistencia del sistema, el contenido real, el comportamiento responsivo, los diseños móviles y los estados no predeterminados antes de lanzar una UI generada.
• AI design review assistant for modern designers: Figma presenta la revisión de diseño como un flujo de trabajo de feedback contextual e iteración, incluyendo revisiones de frames, componentes y flujos seleccionados.
• A pre-ship design review checklist for AI-generated UI: El artículo capturado separa los problemas verificables mecánicamente de la revisión de diseño cualitativa y cubre la paleta, tipografía, diseño, espaciado, estados, foco y movimiento.
• forced-colors CSS media feature: MDN documenta que el modo forced-colors permite que el navegador imponga una paleta de colores seleccionada por el usuario y puede alterar varias propiedades de CSS relacionadas con el color.
• Identity Forge: Identity Forge proporciona kits de diseño con tokens semánticos, tipografía, reglas de diseño, guías de DESIGN.md y rutas de entrega para flujos de trabajo de agentes de código.
• Cómo generar un DESIGN.md (y qué es): Un DESIGN.md puede documentar la intención del diseño, los sistemas de color y tipografía, las reglas de diseño y espaciado, el tratamiento de los componentes, los motivos y las restricciones de uso explícitas para un agente de código.
• Explicación de los semantic color tokens: Los semantic color tokens nombran los colores según su función en la interfaz y permiten que los componentes hagan referencia a roles estables tanto en temas claros como oscuros.
• Generadores de sistemas de diseño de shadcn/ui: ¿necesita un tema, un sistema o un traspaso a un agente?: El artículo distingue un tema visual de un sistema de diseño más amplio y recomienda inspeccionar el significado de los tokens, el mapeo de componentes, la tipografía, las guías de diseño, las rutas de instalación y las carencias conocidas.

• 7-point checklist to review any AI-generated UI: El artículo analizado explica que unas pantallas generadas por IA con un acabado pulido pueden ocultar una lógica débil y la falta de decisiones de producto, por lo que el acabado visual no debe considerarse como un indicador de que el producto esté listo.
• AI Generated UI Quality Checklist: La lista de verificación recomienda revisar la jerarquía, la consistencia del sistema, el contenido real, el comportamiento responsivo, los diseños móviles y los estados no predeterminados antes de lanzar una UI generada.
• AI design review assistant for modern designers: Figma presenta la revisión de diseño como un flujo de trabajo de iteración y retroalimentación contextual, que incluye revisiones de frames, componentes y flujos seleccionados.
• A pre-ship design review checklist for AI-generated UI: El artículo analizado separa los problemas que pueden verificarse mecánicamente de la revisión de diseño cualitativa, y abarca la paleta, la tipografía, el diseño, el espaciado, los estados, el foco y el movimiento.
• forced-colors CSS media feature: MDN documenta que el modo forced-colors permite que el navegador imponga una paleta de colores seleccionada por el usuario y puede alterar varias propiedades de CSS relacionadas con el color.
• Identity Forge: Identity Forge proporciona kits de diseño con tokens semánticos, tipografía, reglas de diseño, guías de DESIGN.md y rutas de entrega para flujos de trabajo con agentes de código.
• How to generate a DESIGN.md (and what it is): Un DESIGN.md puede documentar la intención del diseño, los sistemas de color y tipografía, las reglas de diseño y espaciado, el tratamiento de los componentes, los motivos y las restricciones de uso explícitas para un agente de código.
• Semantic color tokens explained: Los semantic color tokens nombran los colores según su función en la interfaz y permiten que los componentes hagan referencia a roles estables tanto en temas claros como oscuros.
• Shadcn design system generators: do you need a theme, a system, or an agent handoff?: El artículo distingue un tema visual de un sistema de diseño más amplio y recomienda inspeccionar el significado de los tokens, el mapeo de componentes, la tipografía, las guías de diseño, las rutas de instalación y las carencias conocidas.