Cómo recopilar feedback de un sitio web y convertirlo en tareas

Para recoger feedback útil de un sitio web, indica qué página se debe revisar y qué decisión hace falta. Pide a cada persona que señale el elemento, describa el cambio que propone y explique el motivo. Convierte los cambios acordados en tareas con un responsable y una forma de verificar el resultado. Vuelve al sitio antes de cerrarlas.

Parece sencillo hasta que llega la primera ronda. Una persona manda una captura por chat. Otra responde a un correo antiguo. El cliente dice que “el botón todavía se ve raro” y el desarrollador tiene que averiguar de qué botón habla, en qué página y a qué tamaño de pantalla.

Lo que consume tiempo es reconstruir el pedido. Un buen proceso de revisión conserva ese contexto junto al trabajo.

Este es un flujo que una agencia o un equipo de producto puede aplicar en el espacio de feedback visual de OkFlow. La landing page que usaremos es ficticia: sirve para explicar el proceso y puedes adaptarla. No es un caso de un cliente.

Qué información conviene conservar

El software de feedback web permite comentar una página y conservar la ubicación de cada observación. Después alguien tiene que decidir qué significa ese comentario para el proyecto.

Un pin responde “¿dónde?”. La tarea también necesita explicar qué se espera cambiar. Debería entenderla una persona que no estuvo en la reunión de revisión.

En la mayoría de las revisiones conviene reunir estos datos:

• La URL y el elemento del que se habla.
• Lo que vio la persona y lo que esperaba encontrar.
• Las condiciones relevantes, como el ancho de pantalla o los pasos anteriores a un error.
• Quién se ocupa de la siguiente acción.
• Una comprobación concreta para decidir si el cambio está listo.

Adjunta una captura si ayuda a explicar el problema. Si el pedido depende de un texto aprobado, enlaza ese texto. No hace falta un informe largo para corregir una tilde; sí hace falta evitar que otra persona tenga que adivinar.

Abre la revisión con una pregunta concreta

Imagina que una agencia prepara una landing page para un taller. El cliente debe revisar la oferta, la fecha y el texto de inscripción. El diseño todavía está en ajustes.

“Por favor, revisen el sitio” deja demasiado abierto. Un pedido más útil sería:

Revisen la landing del taller para el lanzamiento de octubre. Comprueben la fecha, el precio y el texto de inscripción con el brief aprobado. Añadan un comentario separado por cada cambio. Maya reunirá el feedback el martes y Luis confirmará los textos finales.

Así se entiende qué revisar y quién decide. También se pueden registrar sugerencias de diseño, pero el equipo sabe distinguirlas de lo que debe resolver en esta ronda.

Guarda el brief en las Pages del proyecto para que quien revisa y quien implementa consulten el mismo texto. Antes de invitar a personas externas, comprueba el alcance de la revisión de invitados. Su acceso debe corresponder al entregable que van a revisar.

Convierte “arreglar el botón” en una tarea que se pueda cerrar

Una persona observa que el botón dice “Solicitar cotización”, aunque la página sirve para inscribirse en un taller. Añade una anotación sobre el botón y el equipo acuerda cambiarlo.

La tarea podría quedar así:

Título: Cambiar el CTA del taller a "Inscribirme en el taller"

Página: /talleres/octubre
Ubicación: Botón principal debajo de la introducción
Observado: El botón dice "Solicitar cotización".
Esperado: Usar "Inscribirme en el taller", según el brief aprobado.

Responsable: Desarrollador asignado
Revisión: Persona designada por el cliente para aprobar los textos

Comprobaciones de aceptación:
- El texto visible coincide con el aprobado.
- El botón abre la página de inscripción correspondiente.
- El texto completo se lee a 390 px y en escritorio.
- Se puede llegar al botón y usarlo con el teclado.

Los nombres y la ruta son datos de ejemplo. Sustitúyelos por la URL real y la persona que toma la decisión. Los 390 px sirven para este caso; el proyecto debe comprobar los tamaños de pantalla que realmente necesita soportar.

OkFlow permite vincular anotaciones visuales con tareas. Usa el espacio de tareas para conservar la descripción y la conversación junto al trabajo acordado. La anotación guarda la ubicación; las comprobaciones explican qué resultado se espera.

Descarga la plantilla para tareas de feedback web y copia su contenido en la descripción de una tarea. Es una hoja de trabajo en texto plano: puedes incorporarla a tu proceso sin configurar una importación.

Clasifica los comentarios antes de comprometer trabajo

No todos los comentarios deben entrar al lanzamiento actual. Durante la revisión, decide si cada observación es un defecto, una pregunta, un cambio acordado o una idea para más adelante.

Un segundo comentario dice: “¿Podríamos poner un video aquí?”. Todavía es una petición abierta. Falta decidir qué explicaría el video, quién lo produciría y si corresponde incluirlo en este lanzamiento. Asignarlo directamente a un desarrollador ocultaría esas decisiones dentro de una tarea aparentemente normal.

Registra la respuesta en la conversación de la tarea. Si se pospone la idea, déjala en el backlog con ese motivo. Si falta una confirmación del cliente, indica quién la va a conseguir. Una columna del tablero no explica por sí sola por qué el trabajo está esperando.

Por eso el backlog y el tablero cumplen funciones distintas. El backlog conserva trabajo que se está considerando; el tablero permite hablar del trabajo que el equipo ya asumió.

Elige dónde revisar según el entregable

La revisión de un sitio en vivo sirve cuando el problema depende de la página real: un texto, el destino de un enlace o el estado que aparece al abrir un menú. Comprueba la interacción además de su apariencia.

Algunos sitios restringen su visualización dentro de otra página. Si el canvas no puede mostrar el sitio, utiliza una imagen capturada para comentar el aspecto visual o usa la extensión si tu equipo ya la tiene instalada. Una captura puede mostrar un problema de diseño, pero el comportamiento interactivo necesita una comprobación aparte en el sitio. La página de la extensión explica cómo solicitar los detalles de instalación.

Para una propuesta, presentación o PDF, usa File Canvas. Registra la página y la versión del archivo. Si una afirmación se repite varias veces, enumera las ubicaciones para que la corrección no termine en la primera. La guía de revisión de PDF desarrolla ese proceso.

Vuelve a abrir la página antes de cerrar la tarea

El desarrollador cambia el botón y pasa la tarea a revisión. Ahora alguien debe comparar el resultado con las comprobaciones de aceptación.

Abre la página acordada, confirma el texto, sigue el enlace y repite las pruebas de pantalla y teclado que correspondan. Registra qué revisaste. Si el texto está bien, pero el enlace lleva a otro lugar, todavía queda trabajo.

Una nota de verificación puede ser breve:

Se comprobó el texto actualizado en la landing del taller a 390 px y en escritorio. El botón abre la página de inscripción aprobada y funciona con el teclado. La persona encargada de aprobar los textos confirmó la redacción en esta ronda.

Escribe la nota después de realizar las comprobaciones y ajústala a lo que observaste.

¿Cómo sabes que el cliente aprobó el trabajo?

Pide a la persona designada que identifique el entregable y el alcance de su decisión. “Texto de la landing del taller aprobado para el lanzamiento de octubre” es más claro que “se ve bien”.

Conserva las condiciones pendientes junto a esa decisión. Aprobar el texto no resuelve un problema de accesibilidad ni autoriza una página nueva. La guía de aprobación con clientes incluye un brief de revisión que puedes reutilizar.

Empieza con una ronda pequeña. Elige una página, invita a quienes deban revisarla y sigue unos cuantos cambios hasta verificarlos. Pronto verás dónde hace falta más detalle y dónde puedes acortar la plantilla.

Crea un proyecto en OkFlow o usa la hoja de trabajo con tus herramientas actuales. Conserva este hábito: la observación original debe seguir teniendo sentido cuando alguien vuelva para terminar la tarea.