Capturas anotadas en Asana: cómo llevar el feedback web a tareas

Una captura anotada vale más que diez líneas de explicación, pero solo si acaba en la tarea donde se hace el trabajo. Si tu equipo gestiona los proyectos web en Asana, hay cinco formas de llevar capturas anotadas a Asana, desde arrastrar el archivo a mano hasta que el feedback del cliente llegue ya convertido en tareas. Aquí las comparamos, vemos cuándo conviene cada una y te proponemos cómo montar el proyecto de Asana para el feedback web.

Por qué la captura anotada tiene que estar en la tarea

Una captura anotada es una imagen de la pantalla con flechas, recuadros o texto que señalan un problema concreto. Suelta en la carpeta de Descargas o en un chat pierde el contexto. Dentro de la tarea de Asana está junto al responsable, la fecha y la conversación, y el desarrollador no tiene que preguntar «¿esto en qué página era?» ni buscar la imagen en el correo.

El objetivo es sencillo: un problema, una tarea, con la captura adjunta y la URL y el navegador anotados.

Método 1: pegar o adjuntar la captura a mano

Funciona en todos los planes de Asana:

1. Haz la captura y anótala (Recortes en Windows, Mayús-Comando-4 y Markup en Mac, o una app como ShareX o CleanShot X; lo explicamos en cómo anotar capturas de pantalla de una web).
2. Crea una tarea en el proyecto que toca.
3. Arrastra la imagen a la tarea, adjúntala con el clip o pégala en la descripción o en un comentario.
4. Escribe en la descripción la URL, el navegador y el tamaño de pantalla.

Va bien para: tu propio equipo y unas pocas incidencias a la semana. Punto débil: todo es manual, y la URL y el navegador son lo primero que se olvida.

Método 2: anotar dentro de Asana con Proofing

Proofing permite abrir una imagen o un PDF adjunto a una tarea, hacer clic en un punto y dejar un comentario. Cada anotación se convierte en una subtarea que puedes asignar y a la que puedes poner fecha, según el centro de ayuda de Asana.

Va bien para: revisar maquetas y PDF de diseño que ya están en Asana. Punto débil: alguien tiene que hacer y subir la captura primero, y Proofing solo está en los planes superiores (mira la tabla de abajo).

Método 3: enviar la captura por correo al proyecto

Cada proyecto de Asana tiene su propia dirección de correo con el formato x+IDdelproyecto@mail.asana.com (el ID es el número que aparece en la URL del proyecto). Envía un correo con la captura adjunta: el asunto será el nombre de la tarea y el cuerpo, la descripción. También puedes reenviar correos a x@mail.asana.com para crear una tarea asignada a ti. Lo explica la ayuda de Asana sobre tareas por correo.

Va bien para: convertir en tareas los correos con capturas que te manda el cliente, sin volver a escribirlos. Punto débil: solo puedes crear tareas en proyectos de los que eres miembro (salvo que el proyecto y el equipo sean públicos), así que normalmente el cliente no puede enviar ahí directamente. Y un correo con seis problemas se convierte en una tarea, no en seis.

Método 4: recoger el feedback con un formulario de Asana

Los formularios de Asana permiten que cualquiera rellene un formulario cuyas respuestas se convierten en tareas de un proyecto. Añade campos para la URL, la descripción y un archivo para subir la captura, y pásale el enlace al cliente.

Va bien para: peticiones estructuradas de gente que no usa Asana. Punto débil: el cliente tiene que hacer la captura, anotarla, subirla y escribir la URL y el navegador. Muchos no lo harán.

¿Qué plan de Asana necesitas?

Fuente: asana.com/pricing, a octubre de 2026. Precios en dólares, tal como los publica Asana.

El problema de los cuatro métodos manuales

Los métodos 1 a 4 tienen el mismo punto débil con el feedback web: alguien tiene que hacer la captura, anotarla, llevarla a Asana y añadir el contexto. Para tu desarrollador, bien. Para un cliente que revisa la web antes del lanzamiento, significa que te llega un PDF con flechas, un correo larguísimo o un formulario con «te lo adjunto» y sin adjunto, y alguien del equipo pierde la tarde convirtiéndolo en tareas.

Método 5: tareas automáticas desde un widget de feedback

Un widget de feedback pone un botón en la propia web, de modo que la captura, la anotación y el contexto técnico se recogen de una vez y llegan a Asana sin que tengas que hacer nada.

Con GiveFeedback.io y su integración con Asana:

1. Instala el widget. Crea un proyecto gratis y pega el script en el <head> de la web (hay guías de instalación para WordPress, Shopify, Wix, Squarespace y más).
2. Conecta Asana. En las integraciones del proyecto elige Asana, inicia sesión y autoriza a GiveFeedback.io (OAuth).
3. Elige el destino. Selecciona el espacio de trabajo y el proyecto de Asana donde se crearán las tareas.
4. Pásale el enlace al cliente. Hace clic en «Give Feedback» en la web, permite que el navegador capture la pestaña, anota la captura con flechas, recuadros, texto o marcador, y añade título y descripción. No necesita cuenta.

Cada informe se convierte en una tarea de Asana con:

• el título que escribió quien reporta, como nombre de la tarea,
• la descripción y el tipo de feedback,
• los datos técnicos: URL, resolución de pantalla, sistema operativo y navegador con versiones, si es móvil, idioma y zona horaria,
• la captura anotada adjunta,
• un enlace al informe en GiveFeedback.io.

Va bien para: revisiones con clientes, pruebas de aceptación y QA antes del lanzamiento, cuando reportan muchas personas no técnicas. Límites: la captura recoge la parte visible de la página (no la página completa), no graba vídeo ni registros de consola y el editor no tiene herramienta de desenfoque. El widget está en inglés, aunque la app tiene versión en español. Además de Asana, se integra con Notion, Jira, Trello, ClickUp, Slack y monday.com; Wrike y Discord están «próximamente». Si tu equipo trabaja en Notion, mira cómo gestionar el feedback web en Notion.

Comparativa: cinco formas de llevar capturas a Asana

Cómo montar el proyecto de Asana para el feedback web

Uses el método que uses, una estructura fija evita que el feedback se acumule.

Secciones (columnas del tablero):

1. Entrada: tareas nuevas sin revisar. Déjala como primera sección y mueve aquí lo nuevo si cae en otro sitio.
2. Por arreglar: revisadas, asignadas y con prioridad.
3. En curso
4. Para revisión del cliente
5. Hecho

Campos personalizados (plan Starter o superior):

Reglas prácticas:

• Un problema por tarea. Si el cliente manda cinco cosas en un informe, sepáralas en subtareas o tareas distintas.
• Una persona revisa la sección Entrada cada día durante las rondas de revisión: pone Tipo y Prioridad, asigna y fusiona duplicados.
• Antes de publicar, filtra Prioridad = Alta y sin completar. Esa lista debe estar vacía, o aceptada por escrito por el cliente. Nuestro checklist QA web recoge qué más revisar.

Ejemplo de tarea

Nombre: El texto del botón de pago sale cortado Sección: Entrada → Por arreglar Responsable: Marta (front-end) · Prioridad: Alta · Tipo: Bug Descripción: «El botón dice "Finalizar com". Debería verse el texto entero.» Página: https://staging.ejemplo.es/carrito/ · Chrome 129 · Windows 11 · 1280×720 Adjunto: captura con un rectángulo rojo alrededor del botón

Esa tarea se puede resolver sin una sola pregunta de vuelta, que es justo lo que buscas. Si quieres más detalle sobre cómo redactar informes así, mira cómo escribir un informe de bugs.

¿Qué método te conviene?

Si eres tú quien encuentra los fallos, pega las capturas en las tareas y usa Proofing si tu plan lo incluye. Si los clientes te mandan capturas por correo, reenvíalas a la dirección del proyecto. Si los clientes revisan toda la web antes del lanzamiento, deja que reporten desde la propia web y que las tareas se creen solas: eso hace la integración de GiveFeedback.io con Asana, y puedes empezar gratis.