Bugs en Notion: gestiona el feedback de tu web paso a paso

Gestionar los bugs en Notion tiene mucho sentido si tu agencia o tu negocio freelance ya organiza los proyectos ahí: el equipo no aprende otra herramienta y los errores quedan al lado del briefing, el mapa web y las actas de reunión. En esta guía montamos una base de datos de bugs para proyectos web (propiedades, vistas y rutina semanal) y vemos cómo rellenarla sola con el feedback del cliente, en lugar de copiar capturas de los correos.

Qué es un gestor de bugs en Notion

Un gestor de bugs en Notion es una base de datos en la que cada error, petición de cambio o comentario es una página, y cada página tiene propiedades (Estado, Tipo, Prioridad, URL, Responsable…) que puedes filtrar, ordenar y agrupar. Notion no tiene una función especial para bugs: la base de datos es el gestor.

Para proyectos web suele bastar. No hacen falta sprints, versiones ni enlaces al código para arreglar «la imagen de cabecera se ve borrosa en pantallas Retina». Hace falta saber qué falla, dónde, quién se encarga y si ya está resuelto.

Paso 1: crea la base de datos

Crea una base de datos de página completa en el espacio del proyecto (escribe /database o /base de datos y elige la opción de página completa) y llámala, por ejemplo, «Feedback web – Nombre del cliente». Una base de datos por cliente simplifica los permisos; si llevas muchos proyectos pequeños, también sirve una común con una propiedad Proyecto.

Paso 2: añade estas propiedades

Que sea corta. Cada propiedad es un campo que alguien tiene que rellenar. Si en dos semanas nadie usa «Gravedad», bórrala.

Paso 3: crea las vistas

Las vistas convierten una lista en un gestor que funciona. Con cuatro basta:

1. Tablero por Estado. La vista del día a día, con columnas Nuevo, En curso, Para revisar y Hecho. Arrastra las tarjetas según avanzan.
2. Triaje. Vista de tabla filtrada por Estado = Nuevo y ordenada por fecha de creación, lo más reciente arriba. Una persona la revisa cada día y asigna Tipo, Prioridad y Responsable.
3. Mis tareas. Tablero o lista filtrado por Responsable = Yo, sin lo terminado. Cada desarrollador la guarda en favoritos.
4. Revisión del cliente. Filtrada por Estado = Para revisar. Compártela con el cliente como invitado para que confirme los arreglos.

Muestra la URL y la Prioridad en las tarjetas del tablero para verlas sin abrir cada página.

Paso 4: decide cómo entra el feedback

Aquí es donde fallan casi todos los gestores de bugs en Notion. La base de datos está lista, pero el feedback sigue llegando en un correo con seis capturas, un audio de WhatsApp y un comentario en un PDF. Alguien del equipo tiene que:

1. leer el correo,
2. guardar cada captura,
3. crear una página de Notion por problema,
4. pegar la captura y el texto,
5. preguntar al cliente en qué página y con qué navegador lo vio.

Son unos cinco minutos por incidencia; en una ronda de 40 comentarios, una tarde entera. Pedir al cliente que use Notion directamente tampoco suele funcionar: necesita cuenta, no conoce tus propiedades y sigue teniendo que hacer y anotar capturas a mano.

Paso 5: rellena Notion automáticamente con GiveFeedback.io

GiveFeedback.io es una herramienta de feedback visual que añade un botón «Give Feedback» a tu web. Clientes y testers hacen clic, capturan la página, la anotan y la envían. Con la integración con Notion, cada informe se crea como una página en tu base de datos.

Cómo se conecta

1. Regístrate gratis en GiveFeedback.io y crea un proyecto con la URL de tu web.
2. Pega el script en el <head> de la web (las guías de instalación cubren WordPress, Shopify, Wix, Squarespace, PrestaShop y Google Tag Manager).
3. En el proyecto, abre las integraciones y elige Notion.
4. Inicia sesión en Notion y autoriza a GiveFeedback.io (OAuth). Cuando Notion te pregunte qué páginas compartir, incluye la base de datos de feedback.
5. Selecciona la base de datos a la que debe ir el feedback.

Qué llega a Notion

Cada comentario se convierte en una página nueva de la base de datos elegida, con:

• el título que escribió quien reporta,
• la captura anotada incrustada en la página,
• la descripción y el tipo de feedback (Bug, Propuesta, Recomendación, Funcionalidad o los tipos que definas),
• los datos técnicos: URL, resolución de pantalla, sistema operativo y versión, navegador y versión, si es móvil, idioma y zona horaria,
• un enlace al informe en el panel de GiveFeedback.io.

A partir de ahí, tu equipo trabaja en Notion como siempre: quien hace el triaje pone Prioridad y Responsable, y el desarrollador mueve la tarjeta por el tablero. El cliente no necesita cuenta de Notion.

Lo que no hace (todavía)

Para que no haya sorpresas:

• La integración crea páginas en Notion. Decidid si la fuente de verdad del estado es Notion o el panel de GiveFeedback.io, para no tener que mirar en dos sitios.
• Las capturas recogen la parte visible de la página, no todo el scroll.
• No graba vídeo ni registros de consola. En aplicaciones con mucho JavaScript, el desarrollador quizá tenga que reproducir el error con las DevTools.
• El widget que ve el cliente está en inglés, aunque la app tiene versión en español.
• Notion es una de varias integraciones: los avisos también pueden ir a Asana, Jira, Trello, ClickUp, Slack o monday.com. Si tu equipo usa Asana, mira cómo llevar capturas anotadas a Asana.

Una rutina semanal para que el gestor siga siendo útil

Un gestor de bugs vale lo que su mantenimiento. Esta rutina lleva unos 15 minutos al día en épocas de revisión:

• Triaje diario (10 minutos). Abre la vista Triaje. En cada página nueva: pon Tipo y Prioridad, asígnala o fusiona duplicados. Si algo no se entiende, pregunta a quien lo reportó en el momento, mientras se acuerda.
• Antes de cada llamada con el cliente. Filtra por Reportado por = cliente y Estado ≠ Hecho. Esa es tu agenda.
• Antes del lanzamiento. Filtra Prioridad = Alta y Estado ≠ Hecho. Esa lista debe estar vacía, o aceptada por escrito por el cliente, antes de publicar. Nuestro checklist QA web recoge qué más revisar.
• Después del lanzamiento. Archiva el tablero o pasa lo pendiente de prioridad Baja a una vista «Fase 2» para que la base de datos no se convierta en un cementerio.

Ejemplo: un informe de principio a fin

Lucía, la clienta, revisa la web en staging desde su portátil y ve que el botón del formulario de newsletter sale cortado. Hace clic en «Give Feedback», captura la pantalla, dibuja un rectángulo alrededor del botón y escribe:

Título: Botón de suscribirse cortado Descripción: Solo se lee «Suscri». Debería verse la palabra entera. Tipo: Bug

Poco después aparece en tu base de datos de Notion una página «Botón de suscribirse cortado» con su captura, la URL /blog/ y «Windows 11, Chrome, 1280×720». Tu project manager pone Prioridad = Alta y se la asigna a Javier, el desarrollador, que reproduce el error con el mismo tamaño de ventana, corrige el CSS y mueve la tarjeta a Para revisar. Lucía lo comprueba en la vista Revisión del cliente y lo confirma. Ni un solo correo.

Si quieres saber qué hace útil un informe así, mira cómo escribir un informe de bugs.

¿Es Notion el gestor de bugs adecuado para ti?

Notion funciona bien cuando tu equipo ya trabaja en él, los proyectos son webs y no software complejo, y la mayoría de informes vienen de clientes y revisores no técnicos. Se queda corto si necesitas integración con Git, planificación de versiones o control de horas detallado; ahí compensa una herramienta específica.

Si Notion te encaja, crea hoy la base de datos con las propiedades de arriba, añade las cuatro vistas y conecta GiveFeedback.io para que la próxima ronda de revisión rellene el gestor por ti. El plan gratuito incluye la integración con Notion.