La review que nadie quiso hacer mal
Llevo un tiempo consultando con equipos de diseño y hay un patrón que se repite más de lo que debería: el Lead y el Senior discuten en cada design review. No porque sean personas difíciles. Sino porque nunca definieron qué estaban revisando.
Uno mira la jerarquía visual. El otro, el flujo de usuario. Uno se fija en si los estados están cubiertos. El otro, en si el copy tiene sentido. Y así, cada review se convierte en una negociación de opiniones donde gana quien habla más alto o lleva más tiempo en el equipo.
La solución no es hablar más. Es dejar de revisar en el aire.
Un checklist no limita la creatividad, la protege
Oye, lo entiendo. Suena aburrido. "¿Un checklist para revisar diseños? ¿Ahora el diseño es un formulario?"
No exactamente. Un checklist de design review no define qué es buen diseño. Define qué tienes que haber resuelto antes de llamar a algo "listo para revisar". La diferencia es importante.
Sin criterios compartidos, la review depende del estado de ánimo de quien revisa ese día. Con criterios, la conversación cambia: deja de ser "a mí esto no me gusta" y pasa a ser "este estado de error no está cubierto según nuestro criterio de usabilidad".
¿Sabes lo que pasa? Que eso es mucho más útil para la persona que está diseñando.
Los cinco bloques de una review objetiva
Un checklist bien construido cubre cinco áreas. No hace falta que sean exhaustivas desde el primer día, pero sí que sean compartidas por todo el equipo:
Accesibilidad: contraste AA, textos alternativos, foco visible, etiquetas en formularios, semántica básica. Son criterios objetivos, no subjetivos. O cumple o no cumple.
Usabilidad: jerarquía visual clara, llamada a la acción reconocible, todos los estados cubiertos (vacío, carga, error, éxito), flujo de error resuelto, funcionamiento en móvil.
Contenido: el copy es comprensible para quien no diseñó la pantalla. Los mensajes de error son accionables. No hay texto de relleno o lorem ipsum. Los placeholders representan datos reales.
Consistencia visual: los colores, la tipografía y el espaciado corresponden al design system. Los iconos son coherentes entre pantallas. Las elevaciones tienen lógica.
Performance percibida: hay estados de carga. Las imágenes tienen tamaño razonable. No hay saltos de layout. El contenido crítico carga primero.
Cada criterio en cada bloque tiene una severidad: crítico (bloquea el avance), mayor (debe resolverse antes de entregar a desarrollo) o menor (mejora deseable).
Cómo usarlo en la práctica
La primera semana, el equipo rellena el checklist individualmente para un mismo diseño. Luego compara resultados. Las discrepancias no son un problema: son la materia prima para calibrar los criterios juntos.
A partir de la segunda semana, el checklist se convierte en el documento que acompaña cada entrega. El diseñador lo completa antes de pedir review. El reviewer lo usa como guía, no como lista de la compra.
Spoiler: las primeras reviews con checklist son más largas. Las siguientes son mucho más cortas. Porque el diseñador sabe exactamente qué tiene que resolver antes de llegar.
Para esto construí el Design Review Checker, una app que lleva ese proceso directamente al navegador. Sin instalación, sin cuenta. Introduces el nombre del proyecto, evalúas criterio a criterio y exportas el resultado como archivo Markdown listo para compartir con el equipo o adjuntar al ticket.
El momento en que cambió todo
El equipo del que te hablaba al principio, el del Lead y el Senior que discutían en cada review... Hicieron una cosa concreta. Pasaron dos horas un viernes documentando en qué criterios estaban de acuerdo y en cuáles no. Del desacuerdo sacaron los criterios que faltaban.
A partir del lunes siguiente, las reviews duraron la mitad. Y las discusiones desaparecieron. No porque ya no tuvieran opiniones distintas. Sino porque las opiniones ya no eran el punto de partida de la conversación.
Eso es lo que hace un checklist bien hecho. No elimina el criterio profesional: lo estructura.