Español

Crítica de diseño que mejora el trabajo, no los sentimientos

Ocho diseñadores en una sala de Zoom. Cuarenta y cinco minutos. Tres comentarios de "me encanta la jerarquía tipográfica". Dos menciones de "¿lo has probado en dark mode?". Una persona que no estaba prestando atención pero dijo "se ve genial". El presentador cierra sesión sintiéndose validado. El lunes por la mañana, el archivo se lanza sin cambios.

Eso no es crítica. Es terapia de grupo con un fondo de Figma.

Si sus últimas cinco críticas produjeron cero diferencias en el archivo, no tiene una práctica de crítica. Tiene una reunión recurrente que cuesta a su equipo aproximadamente seis horas de diseñador por semana y no produce nada. El criterio con el que evalúo la crítica es brutalmente simple: el artefacto tiene que ser diferente después de la sesión de como era antes. No los sentimientos del presentador. No el ambiente de la sala. El archivo.

Aquí se explica cómo ejecutarla de verdad.

Crítica y feedback no son lo mismo

Este es el primer punto donde los equipos se pierden. Usan las palabras indistintamente y luego se preguntan por qué sus sesiones no hacen avanzar el trabajo.

El feedback es una reacción amplia. "No me gusta el azul." "Esto se siente pesado." "Algo no cuadra." Es útil en términos de dirección pero no tiene estructura. Se recopila de usuarios, de PMs, de su pareja que pasa por casualidad frente a su monitor. El feedback no tiene contrato. El emisor no tiene obligación de vincular su reacción a nada específico.

La crítica es una evaluación estructurada frente a un objetivo declarado. "El color del CTA no supera el contraste AA sobre el fondo atenuado, por lo que subirlo de #6B7280 a #4B5563 lo lleva a 4.6:1." "El estado vacío entierra la acción principal por debajo del pliegue en breakpoints móviles, por lo que moverla sobre la ilustración coincide con el orden de lectura del usuario." La crítica cita el objetivo, nombra el problema y señala la evidencia.

Necesita ambos. Pero no puede ejecutar una crítica como una sesión de feedback y esperar resultados distintos. La sesión tiene que empezar con un objetivo declarado, y cada comentario tiene que conectar con él. Si un revisor dice "no me gusta el azul" y el brief era sobre arquitectura de la información, ese comentario es feedback, no crítica, y se aparca.

Haga esta distinción explícita al inicio de cada sesión. "Hoy hacemos crítica contra el brief, no feedback abierto. Si tiene feedback que está fuera de alcance, déjelo en el documento y lo gestionamos después." Doce segundos. Ahorra cuarenta minutos.

El brief de encuadre es responsabilidad del presentador

Sin brief, sin crítica. Esto no es negociable.

Antes de que alguien revise nada, el presentador escribe tres cosas al inicio del archivo o documento de Figma:

  1. El problema que se está resolviendo. No la funcionalidad. El problema del usuario o el problema del negocio que el diseño debe abordar. "Reducir el abandono en el paso 3 del onboarding" es un problema. "Rediseñar el paso 3 del onboarding" es una tarea.
  2. Las restricciones. Técnicas (lo que ingeniería confirmó como posible), de marca (qué reglas del design system aplican), de tiempo (fecha límite del sprint, dependencias), de investigación (qué se ha validado, qué no). Aquí es donde se previene el 80% de los comentarios poco útiles.
  3. El tipo de feedback que se busca. Direccional ("¿funciona este enfoque en absoluto?"), pulido de detalles ("microcopy y espaciado"), accesibilidad ("contraste, estados de foco, flujo del lector de pantalla"), arquitectura de la información ("¿es esta la estructura correcta?"), copy ("¿aterriza el lenguaje?"). Una o dos categorías, no todas.

Noventa segundos de escritura. El presentador lo lee en voz alta al inicio de la sesión, o, mejor, los revisores lo leen antes de la sesión y llegan ya orientados.

Plantilla de brief de encuadre

## Brief de crítica, [Nombre de la funcionalidad/flujo]
Fecha: [fecha] · Presentador: [nombre]

### Problema
[1-3 frases. El problema del usuario o del negocio, no la tarea.]

### Restricciones
- Técnica: [lo que ingeniería confirmó]
- Marca/sistema: [reglas relevantes del design system, excepciones]
- Tiempo: [fecha de lanzamiento, bloqueadores]
- Investigación: [qué está validado, qué se asume, vacíos]

### Feedback buscado
[Elija 1-2: direccional / arquitectura de la información / pulido de detalles / copy / accesibilidad / interacción]

### Qué NO está en alcance
[Decisiones ya tomadas, conversaciones aparcadas para más adelante]

### Preguntas abiertas
[2-3 cosas específicas sobre las que quiere ayuda]

La línea "qué NO está en alcance" es la parte del brief con el ROI más alto. Es donde se dice "no estamos reconsiderando si esto debe ser un modal o un panel lateral. Eso está decidido." Salva la sesión de retroceder en el tiempo.

Prohiba el "me gusta". Use "qué está funcionando".

"Me gusta" ancla en el gusto. "Me gusta" le dice al presentador cómo se siente el revisor, lo cual es irrelevante para determinar si el trabajo es bueno. "Me gusta" tampoco es accionable. ¿Qué hace el lunes con "a Sara le gusta la jerarquía tipográfica"?

Sustituya "me gusta" por "qué está funcionando frente al objetivo declarado" y "qué no está funcionando frente a él". Mismo instinto, resultado distinto.

Mal: "Me encanta lo limpio que se siente esto."

Mejor: "Frente al objetivo de reducir el abandono en el onboarding, la jerarquía visual simplificada está funcionando. El CTA principal es el elemento más brillante de la pantalla, lo que coincide con lo que queremos que los usuarios hagan primero."

La segunda versión (a) se vincula al brief, (b) nombra la cosa específica que funciona y (c) explica por qué funciona. El presentador sabe qué conservar. Los revisores saben qué tiene peso en el diseño.

Esto suena pedante. Lo es. La crítica de diseño es una habilidad del craft, y las habilidades del craft requieren vocabulario pedante. Los equipos que prohíben el "me gusta" durante dos meses dejan de necesitar la regla porque el nuevo vocabulario se convierte en hábito. Los que no lo hacen nunca mejoran.

Asincrónico vs. sincrónico: equivóquese en el predeterminado, pague para siempre

La mayoría de los equipos optan por la crítica sincrónica para todo y queman entre cuatro y seis horas de diseñador por sesión que no necesitaban ser en vivo. La regla:

Asincrónico (Loom + comentarios de Figma, ventana de 24 horas):

  • Pulido de detalles (espaciado, microcopy, elección de iconos)
  • Auditoría de accesibilidad (contraste, estados de foco, estructura semántica)
  • Revisión de casos límite (estados vacíos, de error, de carga)
  • Revisión de copy (voz, tono, legibilidad)
  • Pulido final antes del lanzamiento

Sincrónico (sesión en vivo de 30-45 minutos):

  • Decisiones direccionales: ¿es este el enfoque correcto en absoluto?
  • Debates de arquitectura de la información: cinco revisores van a estar en desacuerdo y necesitan argumentarlo
  • Patrones novedosos: cualquier cosa fuera del design system que requiera un juicio de valor
  • Aportación multifuncional: cuando PM e ingeniería necesitan estar en la sala
  • Trabajo atascado: cuando el presentador lleva un tiempo dando vueltas y necesita desatascarse

El predeterminado asincrónico funciona porque obliga a comentarios escritos y reflexivos. La gente no puede divagar ni actuar. Los revisores ven el Loom, dejan comentarios en Figma vinculados a frames específicos, y el presentador puede abordarlos en bloque. Una sesión sincrónica de 45 minutos se comprime en un Loom de 6 minutos más 30 minutos de revisión distribuida, con menos horas en total y a menudo mejor calidad.

El predeterminado sincrónico falla porque mete a ocho personas en una sala para el trabajo de una persona, donde cinco de ellas no tienen nada significativo que decir sobre esa superficie específica pero sienten la obligación de hablar de todos modos. Ahí es de donde viene el "me gusta la jerarquía tipográfica".

Elija el modo según el campo "feedback buscado" del brief. ¿Pulido de detalles? Asincrónico. ¿Direccional? Sincrónico. Si no está seguro, primero asincrónico, luego escale a sincrónico si los comentarios exponen un desacuerdo que necesita resolución en vivo.

Los diseñadores defensivos: nómbrelos, redirija

La defensividad mata la crítica más rápido que el feedback de mala calidad. El presentador que no puede estar quieto tres minutos ininterrumpidos de revisión destrozará la sesión. Tres patrones que nombrar y redirigir:

El Explicador. Cada comentario recibe "pero la razón por la que lo hice así fue..." El Explicador trata la crítica como un malentendido que aclarar en lugar de información que absorber. El trabajo no cambia porque el Explicador no cambia.

Script de redirección: "Apúntelo, sigamos. Si queda tiempo, volvemos al contexto al final."

El Desviador. Cada comentario recibe "sí, pero ingeniería dijo..." o "sí, pero el PM quiere..." El Desviador externaliza la decisión a terceros ausentes para no hacerse responsable de la elección de diseño.

Script de redirección: "Eso es una conversación sobre restricciones, no de crítica. Regístrelo en el documento como seguimiento. Estamos evaluando el artefacto que tenemos ante nosotros frente al brief."

El Retrocededor. Cinco minutos dentro de la crítica, el Retrocededor vuelve a presentar el brief, la investigación de usuarios, las exploraciones anteriores, la reunión donde se tomó la decisión. El Retrocededor está ganando tiempo e intentando reconsiderar decisiones frente a una audiencia.

Script de redirección: "Ya hemos pasado el encuadre y estamos centrándonos en el trabajo. Si hay que reabrir una decisión, eso es una sesión separada con las personas que la tomaron originalmente."

Tres scripts. Memorícelos. La primera vez que los use en una sesión, se sentirá incómodo. En la tercera sesión, el equipo se adapta y los patrones desaparecen en su mayoría. En la quinta, el equipo empieza a monitorearse a sí mismo.

Normas para el presentador

Si es usted quien presenta, estas son las reglas:

No se defienda en tiempo real. Anótelo. ¿Los revisores dicen algo con lo que no está de acuerdo? Regístrelo. No argumente. La forma más rápida de matar una crítica es pasarla negociando en lugar de escuchando. Después de la sesión, aborde las notas en sus acciones a realizar.

No pregunte "¿funciona esto?" Invita a comentarios sobre el gusto. Pregunte "¿esto resuelve [problema declarado] dadas [restricciones declaradas]?" Esa es una pregunta a la que los revisores pueden responder de forma concreta.

No presente 14 pantallas. Presente las 3 con la pregunta abierta. Si trae 14, los revisores comentarán las 14 y diluirán la atención lejos de la decisión real con la que necesita ayuda. Elija las pantallas donde vive la decisión. Aparte el resto en un apéndice.

No actúe. Nada de "vale, pues me fui por unas cincuenta iteraciones y..." Muestre el trabajo. El recorrido está en su cabeza y no tiene peso para los revisores. Necesitan el estado actual, el brief y su pregunta abierta.

Termine con la pregunta. Última diapositiva antes del debate: "Lo que necesito de ustedes hoy es X." Prepara a la sala. Sin ello, obtiene una lluvia de comentarios inconexos.

Normas para el revisor

Si es usted quien revisa, estas son las reglas:

Vincule cada comentario al brief. "Frente al objetivo de arquitectura de la información, la navegación de tercer nivel añade dos clics para una tarea principal. Considere promoverla al nivel superior." No "yo la promovería al nivel superior." La primera versión es crítica. La segunda es dirección artística no solicitada.

Diagnostique antes de proponer soluciones. "Esta navegación parece confusa porque las etiquetas mezclan modelos mentales: algunas son sustantivos (Bandeja de entrada, Informes) y otras son verbos (Redactar, Revisar)" es un diagnóstico. "Use un menú hamburguesa" es una solución. Diagnostique primero. Deje que el presentador decida la solución. Tiene contexto que usted no tiene.

Sin reconsiderar decisiones anteriores. Si el brief dice "el patrón modal está decidido", no empiece con "sigo pensando que esto debería ser un panel lateral". Eso no es crítica. Es intentar ganar un argumento antiguo.

Sin diseño por comité. Los revisores asesoran. El presentador decide. Si cinco revisores se contradicen entre sí, el presentador pondera las aportaciones y elige un camino. La sesión no vota. Votar sobre diseño produce papilla.

Ajuste la profundidad al brief. Si el brief dice "solo pulido de detalles", no llegue con preocupaciones direccionales. Déjelas en el documento como seguimientos. Respete el alcance.

Plantilla de comentario del revisor

Frente a [objetivo del brief], [observación vinculada al frame/elemento específico]. Considere [dirección o principio, no una solución].

Ejemplo:

Frente al objetivo de reducir el abandono en el onboarding, el CTA secundario en la pantalla 3 compite visualmente con la acción principal. Ambos son botones rellenos de peso similar. Considere diferenciar la jerarquía para que la acción principal capte la atención.

Esa es la fórmula completa. Objetivo, observación y dirección. Los comentarios que no encajan en esta forma generalmente no son crítica.

Toda crítica termina con acciones a realizar, o no ocurrió

Esta es la regla que convierte la crítica de una reunión en una práctica.

Al final de cada sesión (sincrónica o asincrónica), el presentador (no el revisor más ruidoso, no el design manager, no el consenso de la sala) escribe entre 3 y 7 acciones a realizar en el archivo:

  • Qué cambia.
  • Qué se mantiene.
  • Qué es un seguimiento pendiente para el PM, ingeniería, investigación u otro diseñador.

Publicado en el canal del equipo dentro de las 24 horas. Vinculado al archivo. Etiquetado con la siguiente fecha de revisión.

Plantilla de acciones a realizar

## Acciones a realizar de la crítica, [Funcionalidad/Flujo], [Fecha]
Presentador: [nombre]

### Cambia
- [ ] [Cambio específico vinculado a un comentario de crítica, con referencia al frame]
- [ ] [Cambio específico]
- [ ] [Cambio específico]

### Se mantiene (y por qué)
- [Decisión sostenida], [1 línea de justificación vinculada al brief o a la restricción]
- [Decisión sostenida], [razón]

### Seguimientos
- [ ] @pm, [pregunta específica]
- [ ] @eng, [pregunta específica]
- [ ] @investigacion, [pregunta específica]

Próxima revisión: [fecha / asincrónica o sincrónica]

Sin acciones a realizar, no hay crítica. Si el presentador no puede escribir entre 3 y 7 elementos, o la sesión fue desenfocada o el brief estaba mal planteado. Ambos son problemas diagnosticables. Ambos son corregibles. Lo que no es corregible es un equipo que ejecuta críticas durante un año y no produce nada registrado.

Errores comunes

Criticar sin un brief. El fallo más común. La sesión se convierte en feedback, luego en vibes, luego en nada.

Mezclar la crítica con la revisión de stakeholders. Audiencia distinta, reglas distintas. Los stakeholders se preocupan por el alcance, la marca y el riesgo. Los revisores en la crítica se preocupan por el craft. Combinarlos produce una sesión donde ningún grupo obtiene lo que necesita. Ejecútelas como reuniones separadas con agendas distintas.

Ejecutar la crítica como una actualización de estado. "Así es como estoy esta semana." Eso es un standup. La crítica requiere una pregunta abierta y un brief. Si no los tiene, omita la crítica y simplemente publique el archivo en el canal.

Saltarse la crítica porque "vamos rápido". Los equipos que se saltan la crítica para avanzar rápido son los que tienen más regresiones y más apuros de última hora. La crítica es un mecanismo para pensar antes de lanzar. Los 45 minutos que ahorra al omitirla le cuestan cuatro horas de correcciones tras el lanzamiento.

Dejar que la voz más senior anule el brief. El diseñador staff que llega y dice "simplemente no me gusta esta dirección" sin vincularlo al brief está causando daño. La seniority no exime a nadie de la plantilla de comentarios. Si la voz senior tiene una preocupación direccional, la plantea como una pregunta de seguimiento y convoca a las personas adecuadas. No secuestra la sesión.

El script de Loom para la crítica asincrónica

Para sesiones asincrónicas, el presentador graba un Loom de 4 a 7 minutos. Cualquier cosa más larga y los revisores dejan de verlo. Estructura:

  1. 0:00-1:00, Brief. Lea el brief de encuadre. Problema, restricciones, feedback buscado, qué no está en alcance.
  2. 1:00-4:00, Muestre el trabajo. Tres o cuatro frames clave. Narre el recorrido del usuario. No explique cada elección. Deje que los revisores identifiquen lo que llama la atención.
  3. 4:00-5:00, Preguntas abiertas. Mencione las 2-3 cosas sobre las que específicamente quiere aportaciones.
  4. 5:00-fin, Cómo responder. "Dejen comentarios en Figma vinculados a frames. Usen el formato objetivo, observación y dirección. El plazo es [24-48 horas]. Publicaré las acciones a realizar antes de [fecha]."

Los revisores ven en 1.5x, dejan comentarios de forma asincrónica, el presentador los compila. El tiempo total del equipo es aproximadamente la mitad de lo que cuesta una sesión sincrónica.

Cómo saber que está funcionando

Deje de medir la crítica por "si todo el mundo se sintió escuchado". Empiece a medir por:

  • Acciones a realizar por sesión. Objetivo: 3-7. Por debajo de 3 significa que la sesión fue desenfocada o el brief era demasiado estrecho. Por encima de 7 generalmente significa que el brief era demasiado amplio.
  • Diferencia en el archivo en 48 horas. ¿El artefacto cambió realmente? Haga una captura antes y después. Si el archivo tiene el mismo aspecto 48 horas después de la crítica, la sesión fracasó.
  • Comentarios del revisor vinculados al brief. Tome una muestra de 20 comentarios del último mes. ¿Qué porcentaje se vincula al objetivo declarado? Objetivo: 80% o más. Si está por debajo del 60%, su equipo está ejecutando sesiones de feedback y llamándolas crítica.
  • Satisfacción del presentador (binaria). "¿Esta crítica cambió mi trabajo?" Sí o no. Sin escalas del 1 al 5. La respuesta es sí o no. Regístrela mensualmente.

Si ejecuta estas cuatro métricas durante un trimestre y la tendencia es plana, la práctica no está funcionando y necesita reconstruirla desde el brief de encuadre. Si la tendencia sube, la práctica está haciendo su trabajo: proteger el trabajo, no al presentador.

Ese es todo el trabajo. La crítica existe para mejorar el artefacto. No para que el presentador se sienta visto, no para darles un escenario a los revisores, no para llenar un hueco recurrente en el calendario. Mejor artefacto, acciones a realizar escritas, cambios en el archivo en 48 horas. Cualquier otra cosa es sobrecarga.

Más información