106.9K+Descargar
Ir a la guía de uso
Design QA Checklistpor owl-listener

Design QA Checklist Skill.

Convierte una especificación de diseño en comprobaciones de implementación.

  • QA de diseño
  • Traspaso
Descargar OpenDesignVer la guía de uso
Revisión de la fuente · design-qa-checklistSKILL.md
Tarea Convierte una especificación de diseño en comprobaciones de implementación. Resultados Un checklist acotado derivado de la especificación de diseño. Antes de empezar El checklist necesita una referencia de diseño; una intención vaga no establece coincidencia exacta.
Resumen editorial · fuente revisada el 2026-11-02 · no es un ejemplo generado

01 Qué hace

Convierte una especificación de diseño en comprobaciones de implementación

Crea un checklist de QA de diseño que cubra precisión visual, composición, interacciones, contenido, accesibilidad y plataformas requeridas.

Flujo de trabajo basado en la fuenteNo es un benchmark de ejecución

El enfoque de trabajo

Design QA Checklist ayuda a verificar que una interfaz construida coincide con su especificación. Cubre valores visuales, diseño adaptable, estados de componentes, contenido real, accesibilidad y requisitos de plataforma. La referencia es la especificación real, por lo que identifica discrepancias con más precisión que una revisión de memoria.

La fuente describe una secuencia desde la autorrevisión del desarrollador hasta QA del diseñador, informes de errores con capturas y verificación de correcciones. Generar el checklist prepara el proceso; ejecutarlo aún requiere acceso a la interfaz en funcionamiento, dispositivos objetivo y comprobaciones asistivas pertinentes.

Entregables esperados

  • Un checklist acotado derivado de la especificación de diseño.
  • Comprobaciones de estados visuales, adaptables, de interacción y contenido relevantes.
  • Una estructura de notificación y repetición de pruebas para discrepancias de implementación.
Ver el brief de ejemplo

Del brief a la revisión

  1. 01
    Leer el diseño esperado

    Reúne especificación, tokens y plataformas requeridas. Traduce requisitos a comprobaciones que indiquen qué observar.

  2. 02
    Cubrir estados y casos límite

    Incluye hover, foco, activo, deshabilitado, carga, vacío y error cuando corresponda. Usa contenido real y comprueba truncamiento, desbordamiento y redistribución.

  3. 03
    Revisar la implementación

    Empieza por autorrevisión del desarrollador y después inspección del diseñador. Usa herramientas del navegador para valores exactos y capturas para comparar diseño e implementación.

  4. 04
    Priorizar y volver a probar

    Registra discrepancias por gravedad y verifica correcciones. Documenta tipos recurrentes para detectarlos antes en futuras revisiones.

02 Cuándo usarlo

Cuándo usarlo

El checklist necesita una referencia de diseño; una intención vaga no establece coincidencia exacta.

Buen encaje

  • Entrega de implementaciónUna función construida necesita una aceptación de diseño concreta.
  • QA repetible en equipoDesarrolladores y diseñadores necesitan expectativas compartidas sobre estados y detalles visuales.

Límites que conviene comprobar

  • Dependencia de especificacionesEl checklist necesita una referencia de diseño; una intención vaga no establece coincidencia exacta.
  • Aún hay que ejecutar las pruebasUn checklist escrito no prueba que se hayan ensayado navegadores, dispositivos o lectores de pantalla.
  • Otro entregableLa fuente deriva las especificaciones de traspaso a ingeniería a la skill handoff-spec.

Aporta estos datos

  • Especificación de diseñoProporciona composiciones, tokens y comportamiento esperado de componentes.
  • Versión en ejecuciónIdentifica la implementación y los estados a los que puede acceder quien revisa.
  • Matriz de plataformasIndica navegadores, dispositivos, tamaños de texto y condiciones de accesibilidad requeridos.

03 Decisiones importantes

Decisiones importantes

  1. Expectativas compartidas

    Desarrolladores y diseñadores inspeccionan frente a una única referencia definida.

  2. Cobertura de estados

    Errores y estados vacíos forman parte de la aceptación junto a la vista predeterminada.

  3. Disciplina de repetición

    Las correcciones notificadas se comprueban de nuevo antes de resolver el problema.

04 Ejemplo de brief

Prueba con un encargo concreto

El brief de ejemplo siguiente no se ha probado. Revisa la configuración del skill antes de usarlo.

Revisa la fuente y la configuración

Proporciona composiciones, tokens y comportamiento esperado de componentes.

Archivo fuente original
https://github.com/owl-listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/design-ops/skills/design-qa-checklist/SKILL.md

La referencia siguiente abre las instrucciones originales. Revisa la configuración del repositorio antes de utilizarlas; no es un comando de instalación.

Empieza con un solo entregable

Adapta el alcance, el material de origen y las restricciones de este brief antes de ejecutar el skill.

Brief de ejemplo
Usa design-qa-checklist para la nueva pantalla de facturas. Lee especificación y tokens; crea controles para escritorio y móvil, resultados vacíos, carga, errores de validación y acciones deshabilitadas. Incluye orden por teclado, foco visible, ampliación de texto y movimiento reducido cuando corresponda. Usa las facturas reales de ejemplo, no texto de relleno. Separa preparación del checklist de pruebas ejecutadas. Para toda discrepancia observada registra comportamiento esperado y real, capturas y gravedad, y deja un punto explícito de repetición de prueba de la corrección.

Inspecciona el resultado

Comprueba el resultado real con estos criterios observables.

  • Cada punto remite a una especificación o requisito declarado del producto.
  • Pruebas ejecutadas y condiciones no probadas están claramente separadas.
  • Los errores resueltos incluyen verificación del estado corregido.

OpenDesign ofrece un espacio de trabajo de diseño local para agentes de programación. Este listado no significa que el skill esté incluido ni que se incluyan sus herramientas externas, credenciales y dependencias de software.

Descargar OpenDesignLeer la guía de inicio rápido

05 Fuente y licencia

Fuente y licencia

Esta página describe la revisión fijada de la fuente enlazada abajo. El comportamiento y los requisitos originales pueden cambiar.

Propietario de la fuente
owl-listener
Repositorio
owl-listener/designer-skills
Archivo del skill
SKILL.md
Licencia
MIT
Versión revisada
2026-11-02 · 9a6930cf84a8
Resumen editorial de la fuente
Convierte una especificación de diseño en comprobaciones de implementación.

Resumen original de OpenDesign, basado en la fuente enlazada. Las estrellas del repositorio son una señal de popularidad con fecha, no el uso del skill ni una puntuación de calidad.

06 Preguntas antes de empezar

Preguntas antes de empezar

¿Es solo un checklist visual?

No. Incluye interacción, contenido, accesibilidad y controles multiplataforma.

¿Una captura demuestra el comportamiento del teclado?

Teclado y foco requieren interacción con la implementación; las capturas respaldan la comparación visual.

¿Qué contenido debe usar QA?

La fuente recomienda contenido real y casos límite, no solo recorridos sin errores o texto provisional.

OpenDesign

Mantén juntos tu encargo y tu trabajo de diseño.

Mantén juntos tu brief, el material de origen y el trabajo de diseño en un espacio de trabajo local. Revisa la configuración propia del skill antes de añadirlo a tu flujo de trabajo.

Descargar OpenDesignExplorar skills de diseño
Archivo fuente original
https://github.com/owl-listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/design-ops/skills/design-qa-checklist/SKILL.md