Entre bastidores: la campana que no grita, las notificaciones de una aplicación rehechas

Nuestra primera notificación útil llegó ahogada entre todo lo que no pedía nada. Cinco comentarios en una sesión, una causa sencilla y una renovación entregada ese mismo día: el relato de una avalancha que fabricamos nosotros mismos.

El 31 de agosto de 2026, el primer uso real de nuestra campana de notificaciones produjo cinco comentarios en una sesión (notas internas del equipo). La bandeja anunciaba como nuevo todo lo existente y enumeraba las solicitudes de validación de todos los productos a la vez. La rehicimos ese mismo día.

Una campana que tenía razón demasiado a menudo

La idea inicial tenía sentido: cuando un equipo de agentes trabaja mientras haces otra cosa, hace falta un lugar que diga qué ha ocurrido y qué espera tu decisión. La primera versión lo decía todo. Cada producto abierto alguna vez, cada documento pendiente desde semanas atrás y cada prueba abandonada aparecía en la misma lista, al mismo nivel que lo único importante. Se sumaron dos causas. La bandeja leía todas las solicitudes de validación pendientes, aunque el taller nunca presenta más de una a la vez. Y nada recordaba lo que ya habías visto antes de la actualización, así que todo el pasado llegaba de golpe etiquetado como nuevo.

Tres decisiones tomadas en una noche

La primera: en el producto abierto, la campana solo muestra la solicitud de validación actual, la que bloquea lo que sigue, nunca toda la pila. La segunda: las notificaciones sobreviven al cierre de la aplicación, porque una alerta que desaparece al salir del programa no sirve a quien trabaja por las noches. La tercera: un solo panel ordenado, primero este producto y después lo ocurrido en otros. Añadimos un botón «Borrar lo terminado» que retira los eventos cerrados sin tocar las decisiones pendientes. Estas tres decisiones tienen algo en común: quitan información de la pantalla. Dudamos, porque una notificación retirada es una que alguien buscará algún día. La respuesta fue mover en lugar de eliminar: lo que deja de mostrarse en la campana sigue disponible en el historial de actividad, filtrable producto por producto, y ese historial se llena al abrir la aplicación, no después del primer trabajo.

Una respuesta, un aviso

Un defecto más discreto nos costó tanta credibilidad ante el usuario: cada respuesta de un agente podía acumular varios avisos informativos en la conversación. Ahora una respuesta muestra como máximo un aviso. El botón de acción de los mensajes temporales, negro por defecto porque no se había diseñado, volvió a la paleta del resto de la aplicación. Estas dos correcciones no cambian ninguna capacidad del producto: cambian la cantidad de ruido que hay que atravesar para encontrar la línea que pide tu decisión, y es el mismo problema descrito en nuestra segunda ronda de comentarios de la beta.

El defecto encontrado en una captura de pantalla

Al día siguiente de publicar, una captura mostró un resto: un brief de marca escrito únicamente por Léa aparecía como una decisión pendiente en todos los productos antiguos de prueba y la línea llevaba al inicio en lugar de a Studio. Corregido y republicado ese mismo día. Queríamos numerar esa corrección 0.1.15.1: imposible, una versión tiene tres números, así que fue 0.1.16. Las otras líneas de proyectos antiguos sí eran solicitudes reales de validación todavía abiertas: la respuesta es archivar las pruebas, no silenciar la campana.

La regla que nos imponemos ahora

Toda nueva fuente de eventos pasa por el mismo punto de entrada, nunca por un segundo camino. Es la única garantía de que una notificación no pueda existir duplicada, eludir la ordenación ni contradecir lo que muestra el historial de actividad. La lección general va más allá de nuestro caso: un sistema que notifica debe saber primero qué has visto ya. Sin esa memoria, la primera actualización convierte todo lo existente en alertas y el usuario aprende a ignorar la campana en una noche. Tuvimos suerte con el calendario: el defecto apareció en nuestro equipo antes de llegar a nuestros dos probadores, que habrían recibido la misma ráfaga al actualizar.

Lo que te dice de una herramienta

Cuando pruebes un programa que trabaja en tu ausencia, abre su bandeja de notificaciones después de dos semanas de uso, no el primer día. Cuenta las líneas que exigen una decisión tuya y las que informan de un hecho pasado. Si la proporción se inclina hacia el lado equivocado, dejarás de mirarla y el producto perderá el único canal que podía decirte que un trabajo espera tu acuerdo. En nuestro caso, esa decisión sigue siendo el punto donde todo se detiene hasta que respondes, lo que hace innegociable la claridad de la campana.