Una revisión de diseño asíncrona necesita una versión concreta que examinar, unas pocas preguntas, un plazo de respuesta claro y alguien que decida cómo afectan los comentarios al trabajo. Comparte esos elementos juntos. Pide que cada comentario identifique una parte del diseño y explique el problema para el usuario; al cerrar la revisión, publica las decisiones.
Así se obtiene más información útil que enviando un enlace con «¿Qué os parece?». Una pizarra compartida para colaborar visualmente permite reunir el contexto, el flujo, las preguntas y los comentarios. Cada persona puede participar en otro momento sin reconstruir la información a partir de un hilo de chat.
Elige una pregunta que se pueda responder de forma independiente
La revisión asíncrona encaja cuando el material se entiende por sí solo y los participantes tienen tiempo para examinarlo antes de responder. Puede ayudar a detectar estados que faltan en un flujo, comprobar si el texto responde a una tarea del usuario o identificar dependencias que el equipo de diseño ha pasado por alto.
Organiza una conversación breve en directo cuando no haya acuerdo sobre cuál es el problema, la decisión sea urgente o el intercambio escrito genere nuevos malentendidos. El objetivo es revisar bien el trabajo, no eliminar todas las reuniones.
Aclara si buscas comentarios o una aprobación formal. Un conjunto de comentarios no equivale a una aprobación, y el silencio tampoco. Identifica a quien toma la decisión y a los revisores imprescindibles antes de empezar. Para ampliar la práctica de dar comentarios, consulta la explicación y plantilla de crítica de diseño.
Escribe el contexto antes de enviar el enlace
Imagina un equipo que revisa un flujo de cancelación de suscripciones. La persona que diseña quiere saber si se entiende qué ocurrirá después y cómo recuperarse si falla la solicitud. La revisión trata de la interacción y la redacción; no establece la política de cancelación de la empresa.
| Campo | Ejemplo |
|---|---|
| Versión | Flujo de cancelación, versión de revisión R2. Pantallas C1–C4. |
| Tarea del usuario | Cancelar una suscripción y entender si la solicitud se ha completado correctamente. |
| Pregunta 1 | En C3, ¿se distingue una solicitud enviada de una cancelación completada? |
| Pregunta 2 | Si el envío falla en C2, ¿hay una forma clara de reintentarlo sin perder la intención del usuario? |
| Alcance | Estados del flujo y texto de la interfaz. No se decide la identidad visual ni la política comercial. |
| Revisores | Diseño, ingeniería, soporte y la persona responsable de confirmar la redacción de la política aprobada. |
| Plazo | Cierre en una fecha, hora y zona horaria explícitas, acordadas con los participantes. Indicar a quién avisar si no pueden revisar dentro de ese plazo. |
| Responsable de la decisión | La persona responsable de producto consolida los comentarios con diseño; las dudas sobre la política se remiten a quien tiene autoridad para resolverlas. |
Esta ficha evita que cada participante evalúe un problema distinto. Ingeniería puede examinar los fallos, soporte puede señalar malentendidos frecuentes y la persona responsable de la política puede comprobar si el texto propuesto coincide con las reglas aprobadas.
En su relato de primera mano sobre crítica de diseño asíncrona (en inglés), Erin Casali destaca las preguntas precisas y los momentos explícitos de revisión. La ficha aplica esas ideas a un alcance delimitado, en vez de pedir reacciones a un producto entero que sigue cambiando.
Mantén estable la versión que se revisa
Si el flujo cambia mientras llegan comentarios, alguien puede detectar un problema en una pantalla que ya no existe. Otra persona responderá sobre su sustituta. El hilo parecerá mostrar un desacuerdo cuando, en realidad, se están examinando versiones distintas.
Identifica el material como R2 y mantenlo intacto durante el plazo acordado. Puede ser un conjunto de pantallas exportadas o una copia claramente identificada del material pertinente. Deja cerca el enlace al diseño de origen, pero especifica qué versión recibe los comentarios. Crear una copia separada es una decisión de organización del equipo; la etiqueta no impone un bloqueo del programa.
Si una corrección necesaria no puede esperar, señala qué ha cambiado e indica si los comentarios siguen siendo necesarios. No sustituyas el material sin avisar ni supongas que todas las observaciones se refieren ya a la nueva versión. Al terminar, identifica la propuesta revisada como R3 y explica los cambios.
Pide observaciones que ayuden a decidir
Un comentario útil identifica el lugar, la preocupación y su importancia. Una solución propuesta es bienvenida, pero debe distinguirse del problema que intenta resolver.
Lugar: C3, encabezado de confirmación.
Observación: El encabezado dice que la suscripción está cancelada, mientras el mensaje inferior indica que la solicitud sigue en proceso.
Consecuencia: La persona puede salir creyendo que el cambio ya se ha completado.
Sugerencia: Utilizar un encabezado de estado pendiente hasta que el sistema pueda confirmar la finalización.
Este comentario resulta más útil que «La pantalla de confirmación no me convence»: identifica estados contradictorios. Aun así, ingeniería debe confirmar qué sabe el sistema en ese momento y la persona autorizada debe validar la redacción.
Pide que se diferencie una contradicción observable de un supuesto o una preferencia personal. «Prefiero un título más corto» se puede discutir, pero no tiene el mismo peso que un estado de error omitido. Los comentarios del equipo pueden señalar algo que probar; no sustituyen la evidencia de quienes utilizan el producto.
Resuelve los desacuerdos a partir de la misma pregunta
No cuentes comentarios como votos. Dos personas pueden proponer cambios contrarios porque intentan resolver problemas diferentes. Repite la pregunta compartida antes de decidir.
| Comentario | Preocupación de fondo | Resolución |
|---|---|---|
| «Acortad C3; el mensaje es demasiado largo». | Un párrafo denso puede ocultar el estado principal. | Revisar la jerarquía para destacar el estado y valorar qué detalle complementario resulta necesario. |
| «Añadid más explicación a C3». | Puede no entenderse qué ocurre mientras la solicitud está pendiente. | Conservar la información esencial sobre el siguiente paso debajo del estado. La brevedad y la claridad pueden coexistir. |
| «Cambiad la política para que la cancelación sea inmediata». | Se está pidiendo otra regla de servicio. | Tratar esa propuesta por separado. No cambiar la interfaz para prometer una regla que no está aprobada o implementada. |
| «El reintento en C2 podría duplicar la solicitud». | El diseño puede ocultar un modo de fallo técnico. | Pedir a ingeniería que confirme el comportamiento. Mantener abierta esa decisión del flujo hasta conocer la respuesta. |
Los dos primeros comentarios no obligan a elegir un ganador. El tercero está fuera de la autoridad de esta revisión. El cuarto puede bloquear la interacción propuesta. Tratarlos todos como peticiones de editar una pantalla borraría esas diferencias.
Prepara el espacio de revisión en Boardmix
Coloca la ficha de revisión en el punto de inicio de la pizarra. Debajo, organiza el flujo con el material de diseño existente o con una secuencia sencilla de formas y conectores. Asigna a cada estado una etiqueta visible, como C1 o C2, para que los participantes puedan referirse a él con precisión.
Añade las dos preguntas junto al tramo correspondiente. Deja un espacio para comentarios al lado de cada una y utiliza los comentarios de Boardmix para aclaraciones sobre el trabajo. Una nota puede incluir «C3 · estado pendiente» aunque parte de la conversación ocurra en otro canal.
Reserva otra área para las decisiones con los títulos «Cambiar», «Investigar» y «Mantener, con motivo». La persona responsable mueve o resume allí las aportaciones después de leerlas. Boardmix ofrece el lienzo compartido y los comentarios; el equipo establece el plazo, comunica los recordatorios y toma las decisiones.
Antes de enviar la invitación, pide a un participante que confirme que puede acceder, leer la ficha y comentar de la forma prevista. Incluye la hora exacta de cierre tanto en la invitación como en la pizarra. Si una persona cuya revisión es necesaria no puede participar, acuerda otra solución en vez de interpretar su ausencia como aprobación.
Publica el resultado junto a la siguiente versión
Al cerrar el plazo, resume los cambios y las preguntas pendientes. En el ejemplo, el resultado podría ser:
- C3 distinguirá una solicitud pendiente de una cancelación completada.
- La explicación del siguiente paso seguirá debajo del estado principal.
- El comportamiento del reintento en C2 espera una respuesta de ingeniería.
- La propuesta de cambiar la política comercial se ha remitido a su responsable y no forma parte de la aprobación actual del diseño.
Muestra el material revisado como R3 y relaciona cada cambio importante con la pregunta que responde. Pide otra revisión solo donde haga falta una nueva respuesta; no obligues a releer pantallas que no han cambiado. Un comentario tardío que revele un error grave merece atención, mientras que una nueva preferencia puede esperar a la siguiente revisión adecuada.
Para empezar, abre Boardmix y prepara una pregunta sobre una parte del trabajo claramente identificada. Da suficiente contexto para que los participantes puedan responder sin tenerte delante.
