Notificaciones, toasts y banners: comunicar a tiempo sin robar la atención

Hace un tiempo, una clínica con la que trabajamos nos contó algo que se repite mucho: habían lanzado su app de citas, configurado notificaciones para todo (recordatorios, promociones, consejos de salud, encuestas de satisfacción, novedades del equipo) y, a las pocas semanas, la mayoría de pacientes las había desactivado. Incluidas, claro, las de recordatorio de cita, que eran las únicas que de verdad querían recibir.

Las notificaciones son la voz de un producto cuando el usuario no está mirando, o cuando está mirando otra cosa. Esa voz puede ser la de un asistente atento que avisa justo de lo que importa, o la de alguien que no para de hablar. La diferencia no está en el diseño de cada mensaje por separado, sino en el sistema: qué formato se usa para cada tipo de aviso, con qué frecuencia y con qué tono.

En esta guía recorremos los formatos que tenemos a mano, del toast discreto a la notificación push, y los criterios que aplicamos en el estudio para elegir entre ellos.

01Un mapa de los mensajes del sistema

Antes de diseñar un aviso concreto, conviene tener el mapa completo. Los mensajes de una interfaz se diferencian por dos cosas: cuánto interrumpen y cuánto tiempo permanecen.

El diálogo de alerta merece su propia guía, y la tiene: modales, diálogos y drawers. Aquí nos centramos en el resto, que es donde se juega el día a día.

02Cómo elegir el formato: urgencia, relevancia y momento

Para decidir dónde va cada mensaje, en nuestros proyectos hacemos un inventario de todos los avisos que el producto puede generar y los pasamos por tres preguntas:

1. 01¿Necesita una acción del usuario? Si no, basta con un formato discreto y temporal. Si sí, el mensaje tiene que permanecer hasta que se actúe.
2. 02¿Cuánto urge? Algo que afecta a lo que la persona está haciendo ahora mismo (un error al pagar) pide un formato visible e inmediato. Algo que puede esperar (alguien ha comentado tu publicación) va a la insignia o al centro de notificaciones.
3. 03¿Dónde está el usuario? Si está dentro del producto, el aviso puede ser interno. Si está fuera y el mensaje es importante y oportuno, entonces toca un canal externo, como la notificación push o el email.

Con estas respuestas, cada aviso encuentra su lugar con bastante naturalidad. Y aparece una regla muy útil: el nivel de interrupción del formato tiene que ser proporcional a la importancia del mensaje. Si un simple «Guardado» se muestra en un modal, el usuario aprende a cerrar modales sin leerlos. Si un error de pago se muestra en un toast que desaparece en tres segundos, alguien se quedará sin saber por qué no le ha llegado el pedido.

03Toasts y snackbars: el aviso que confirma y se va

El toast es la forma más ligera de decir «hecho». Aparece tras una acción, confirma que ha funcionado y desaparece solo, sin bloquear nada. Bien diseñado, transmite que el sistema responde; mal calibrado, se pierde o estorba.

Criterios de diseño

• →Mensajes cortos. Una línea, dos como máximo. «Reserva guardada» funciona mejor que «Tu reserva se ha guardado correctamente en el sistema».
• →Una acción como mucho. Normalmente «Deshacer» o «Ver». Si hacen falta dos acciones, el mensaje probablemente necesita otro formato.
• →Duración proporcional. Entre 4 y 6 segundos para avisos sin acción; más, o sin cierre automático, si incluyen una acción. La cuenta atrás se pausa al pasar el ratón o al recibir el foco, en línea con el criterio 2.2.1 de WCAG sobre tiempo ajustable.
• →Posición constante. En móvil, abajo y centrado, por encima de la barra de navegación; en escritorio, abajo a la izquierda o arriba a la derecha. Lo importante es que siempre aparezca en el mismo sitio y que no tape botones de acción.
• →Uno a la vez. Si llegan varios, se ponen en cola o se apilan con un máximo de dos o tres visibles.

Toasts accesibles

Un toast aparece en un lugar de la pantalla donde el usuario quizá no está mirando, y un lector de pantalla no lo anunciará si no se lo indicamos. Para eso existen las regiones vivas (live regions) de ARIA, que cubren el criterio 4.1.3 de WCAG sobre mensajes de estado. La clave es que el contenedor exista en la página desde el principio y que solo cambie su contenido:

<div class="toast-region" role="status" aria-live="polite" aria-atomic="true"></div>
<div class="toast-region toast-region--error" role="alert" aria-atomic="true"></div>

.toast-region { position: fixed; inset: auto 16px calc(16px + env(safe-area-inset-bottom)) 16px; display: grid; gap: 8px; justify-items: center; z-index: 50; }
.toast { max-width: 480px; display: flex; align-items: center; gap: 16px; padding: 12px 16px; border-radius: 12px; background: var(--surface-inverse); color: var(--on-surface-inverse); }
.toast button { min-height: 44px; font-weight: 600; }
@media (min-width: 768px) { .toast-region { inset: auto auto 24px 24px; justify-items: start; } }

La región con role="status" anuncia los mensajes de forma educada, cuando el lector termina lo que estaba diciendo. La de role="alert" interrumpe, y por eso se reserva para errores. Y si el toast tiene una acción, conviene que también sea accesible por teclado sin depender del ratón y que haya otro camino para lo mismo: por ejemplo, deshacer también desde el historial.

04Banners: avisos que se quedan mientras importan

El banner es una franja que aparece dentro de la página, normalmente arriba de una sección o de toda la interfaz, y se queda ahí mientras el mensaje sea relevante. Es el formato adecuado para avisos que piden una acción sin urgencia inmediata («Verifica tu email para activar tu cuenta») o para informar de un estado que afecta a todo («Pedidos con entrega a partir del 2 de enero»).

Para diseñarlos, distinguimos dos niveles:

• →Banner global, en la parte superior de toda la interfaz. Para avisos de sistema que afectan a todo el producto. Uno a la vez, y solo cuando de verdad afecta a todo el mundo.
• →Banner en línea, dentro de una sección concreta. Para avisos que afectan a esa parte: un formulario, una configuración, una tarjeta de pago.

Y cuatro niveles de tono, cada uno con su color, su icono y, sobre todo, su texto: información (azul o neutro), éxito (verde), advertencia (ámbar) y error (rojo). El color ayuda a reconocer el tipo de un vistazo, pero nunca va solo: el icono y el texto tienen que transmitir lo mismo, y el contraste del texto sobre el fondo de color tiene que alcanzar el 4,5:1. Si el mensaje no requiere acción, el banner lleva un botón de cierre; si la requiere, desaparece cuando se resuelve.

05Insignias y centro de notificaciones: lo que puede esperar

No todo lo que pasa en un producto merece una interrupción. La insignia, ese pequeño círculo con un número o un punto sobre un icono, es la forma más amable de decir «hay algo nuevo aquí» sin exigir nada.

• →Punto sin número cuando lo importante es que hay novedades, no cuántas.
• →Número cuando la cantidad importa: mensajes sin leer, productos en el carrito. A partir de cierto límite, «99+» es más legible que «147».
• →Desaparece al consultar. Una insignia que se queda encendida aunque el usuario ya haya visto el contenido pierde su sentido.

El centro de notificaciones reúne todo ese flujo para revisarlo con calma. Funciona bien cuando cada elemento dice qué ha pasado, cuándo y dónde, con acceso directo a ello, y cuando permite marcar todo como leído. En productos con mucha actividad, agrupar avisos similares («Tres personas han comentado tu foto») mantiene la lista manejable.

06Notificaciones push: el permiso se gana

La notificación push es el formato más potente y el más delicado: llega al usuario cuando no está en tu producto, en su pantalla de bloqueo, junto a los mensajes de su familia. Cada notificación que se envía es una pequeña petición de confianza.

Lo que mejor funciona, según nuestra experiencia en apps de servicios, citas y comercio:

1. 01Pedir el permiso en contexto. En iOS y en Android 13 o posterior, el permiso se solicita con un diálogo del sistema que se puede mostrar muy pocas veces (en iOS, una sola) antes de que la única vía sea ir a los ajustes. Antes de lanzarlo, una pantalla propia que explique el beneficio («¿Te avisamos 24 horas antes de tu cita?») justo después de reservar obtiene muchas más aceptaciones que pedirlo al abrir la app.
2. 02Ofrecer preferencias por tipo. Recordatorios sí, promociones no. Si el usuario solo puede elegir entre todo o nada, a menudo elegirá nada.
3. 03Enviar lo justo, en el momento oportuno. Respetar horarios razonables y agrupar mensajes no urgentes en un resumen.
4. 04Llevar al lugar exacto. Al tocar la notificación de un pedido, el usuario aterriza en ese pedido, no en la portada.

En web, las notificaciones push también son posibles en los navegadores de escritorio y Android, y en iPhone desde iOS 16.4 para webs añadidas a la pantalla de inicio. Los mismos principios aplican, con una razón más para ser comedidos: el diálogo de permiso del navegador, mostrado sin contexto, se rechaza casi por reflejo.

07Ejemplo resuelto: el sistema de avisos de la clínica

Volvamos a la clínica del principio. Así reorganizamos sus mensajes:

1. 01Inventario. Diecinueve tipos de aviso, repartidos entre push, email, SMS y mensajes dentro de la app.
2. 02Clasificación. Cuatro eran críticos y oportunos (confirmación de cita, recordatorio 24 horas antes, cambio de hora por parte de la clínica y resultados disponibles). El resto, informativos o promocionales.
3. 03Canales. Los cuatro críticos, por push y email, con preferencia editable. Consejos y novedades, a un apartado de la app con insignia. Las promociones, solo por email y con consentimiento expreso, en cumplimiento del RGPD.
4. 04Permiso en contexto. La petición de notificaciones pasó a mostrarse justo después de reservar la primera cita, con una pantalla que explicaba el recordatorio.
5. 05Mensajes dentro de la app. Toasts para confirmar acciones («Cita reservada · Añadir al calendario»), un banner en línea para perfiles incompletos y mensajes de error junto a cada campo, siguiendo los criterios de la guía de mensajes de error que ayudan.

Con menos mensajes, los pacientes volvieron a activar las notificaciones. Y los recordatorios, que eran el objetivo, cumplieron por fin su función.

08Un producto que habla cuando tiene algo que decir

Un buen sistema de notificaciones se parece a una persona discreta y atenta: avisa de lo importante, a tiempo, con pocas palabras y en el tono adecuado. Cada mensaje está escrito pensando en quien lo recibe, y la guía de UX writing ayuda mucho con esa parte. El resultado es un producto que se siente tranquilo y fiable, y unas notificaciones que la gente decide mantener activadas.

En SIMA diseñamos estos sistemas de mensajes como parte de nuestras apps y plataformas dentro del servicio de desarrollo web y apps con IA, de la arquitectura de avisos al texto de cada toast. Si tu producto habla demasiado, o demasiado poco, escríbenos y buscamos juntos el equilibrio.