Design QA: revisar lo implementado antes de lanzar
El design QA compara lo construido con el diseño aprobado antes de publicar. Qué revisar, cómo registrar y priorizar desviaciones y qué hacer con las demás.
¿Qué es y por qué pasa lo que pasa?
Un diseño puede ser excelente y el producto publicado puede verse mal. Eso sucede por pequeñas diferencias: una fuente un punto más grande, un margen que cambia en tablet, un estado de foco que nadie implementó. Hypermatic dice que esto es, en el fondo, un problema de QA web: la revisión de implementación detecta los detalles que hacen que una página se vea terminada.
La diferencia con el handoff es clara. El handoff entrega el diseño y su especificación al equipo de desarrollo. El design QA verifica después que lo construido coincide con esa entrega. Sin el segundo paso, el primero no garantiza nada.
¿Qué se revisa?
Hypermatic menciona alineación, espaciado, ritmo tipográfico, recortes de imágenes, orden del contenido y pulido responsive. Design System Problems propone listas de verificación por componente y da ejemplos:
- En botones: estados por defecto, hover, activo, foco y deshabilitado.
- En formularios: diseños de los estados de validación y de los mensajes de error.
Esa fuente también incluye entre lo que debe especificarse las animaciones, el orden de foco, ARIA, el truncado de texto y los estados vacíos; luego hay que comprobarlos.
La lista no es fija. Cada producto necesita la suya, pero conviene que incluya lo que el equipo sabe que suele romperse: los textos largos, los idiomas con palabras más extensas, los estados de error y los anchos intermedios que nadie prueba.
Para esos casos, revisa los estados de carga y los patrones de estados de error, que suelen ser lo primero que se omite.
¿Cómo se organiza la revisión?
Rubyroid describe un flujo que tiene sentido en la práctica:
- El equipo de diseño crea los mockups y el cliente los aprueba.
- El equipo de desarrollo implementa usando el modo de desarrollador de Figma.
- Antes del lanzamiento, el equipo de diseño revisa la implementación contra los mockups.
- Los problemas se documentan, se devuelven para corrección y el ciclo continúa hasta que todas las partes están conformes.
- Tras las correcciones, se hace una nueva revisión, normalmente a cargo de quien hace QA.
Design System Problems propone verificar en dos momentos. Antes de programar, confirmar que la especificación está completa: dimensiones, colores, espaciado, estados, comportamiento responsive, interacciones y accesibilidad. Después de implementar, comparar el código con la especificación, mediante revisión del diseñador, comparación automatizada con exportaciones de la herramienta de diseño o QA estructurado. Los huecos que aparezcan en la primera fase se resuelven con una aclaración del diseñador antes de invertir en desarrollo.
Por eso el redline importa tanto: si la especificación tiene huecos, la revisión posterior solo puede encontrar lo que el equipo ya asumió mal.
¿Cómo se priorizan y registran las desviaciones?
Rubyroid clasifica los problemas por urgencia y los reporta con capturas, grabaciones y una nota de prioridad, en la herramienta que el equipo ya use. Hypermatic sugiere priorizar las desviaciones que afectan la confianza, la conversión, la accesibilidad o la calidad de marca. Y advierte: “Not every pixel mismatch matters, but unexplained drift should be visible” (no toda diferencia de píxeles importa, pero la desviación sin explicación debe ser visible).
Un registro útil tiene cuatro campos: qué pantalla o componente, qué debería verse, qué se ve y qué prioridad tiene. Con eso, quien corrige no tiene que adivinar qué se quiso decir.
¿Qué hacer con las desviaciones que se mantienen?
No todas las diferencias son errores. A veces el desarrollo encontró una restricción técnica y la solución real es distinta del diseño. Lo que no conviene es no registrarla.
Documenta la decisión y actualiza el archivo de diseño para que refleje lo que se construyó. Así el siguiente equipo no tomará la diferencia por un error, y el diseño sigue siendo una fuente de verdad. Si la desviación afecta a un componente del sistema, la corrección debe quedar en el componente, no en una pantalla suelta.
Ejemplo
Ejemplo ilustrativo: un equipo lanza una app de pagos. En la revisión previa, el diseñador detecta que el estado de carga del botón de pagar no existe en la versión construida, y que en pantallas de 360 píxeles el importe se corta. Ambos problemas van al registro con capturas y prioridad alta, porque afectan la confianza en el pago. Un tercer problema, un margen distinto en el encabezado, se documenta como desviación aceptada, porque el desarrollo lo ajustó por una restricción del sistema operativo. El archivo de diseño se actualiza.
Para tu próximo lanzamiento: toma tres pantallas, compáralas con el diseño a 360 píxeles y con el texto del sistema en su tamaño máximo. Las diferencias que encuentres son el registro de QA de tu primera ronda.
¿Cuándo NO conviene hacer una revisión completa?
- Cuando el cambio es mínimo y ya se revisó en un entorno de prueba. Repetir todo consume tiempo sin aportar nada.
- Cuando el equipo no tiene a nadie responsable de la revisión final. Hypermatic señala que los equipos fallan cuando nadie es responsable de la revisión final.
- Cuando la revisión se reduce a una comparación general. Si no se miran los estados y los detalles, no es una revisión; es una impresión.
Errores comunes
- Hacer QA solo en escritorio y publicar sin probar otros anchos.
- No tener un checklist y depender de la memoria de cada revisor.
- Reportar problemas sin captura ni descripción de lo esperado.
- Dejar desviaciones sin documentar, y que el archivo de diseño deje de ser verdad.
- Revisar tarde, cuando el desarrollo ya no puede cambiar nada sin retrasar el lanzamiento.