Repensando el uso de alertas:Cómo la saturación de este componente nos llevó a la creación de un nuevo tipo de mensaje

Pantalla del flujo de compra de LATAM con ejemplo de alerta sobre flexibilidad en fechas de viaje.

El componente de alerta dentro de un Design System, es un elemento fundacional dentro de cualquier librería. Su función primaria es entregar un mensaje de notificación que se genera desde el computador o device y que se visualiza en la interfaz de cara al usuario para dar un aviso crítico.

Usualmente se piensa en este componente, haciendo una analogía en el mundo físico con el objeto de un semáforo, sus tiempos y colores. Es decir, existen distintos niveles de severidad del mensaje y de acuerdo al tipo de acción del usuario, ya sea una advertencia, error, éxito o aviso, se dispara esta alerta para que se despliegue en la pantalla. Además, dependiendo de la información y su nivel de criticidad, radica la decisión de su ubicación, tamaño, color, forma y tiempo de permanencia en la pantalla.

Los alert message, como se les conoce en las librerías en los Design Systems, es un componente, que si bien a nivel de diseño es relativamente simple si lo comparamos con elementos más robustos como una caja de compra, menú lateral o el paso de checkout de un e-commerce, sí es clave la correcta construcción de éste, para que soporte un relato conciso con el fin de entregar el sentido de urgencia necesario según la interfaz que está atravesando el usuario.

Ejemplos de alertas en la página de mensajes de Airbnb. En este caso, las alertas se disparan en relación al tiempo transcurrido, para que el dueño del inmueble acepte o no la solicitud de reserva.

1. Los alerts no solo se deben considerar como un componente de diseño, sino un mensaje clave en donde el relato y su composición es lo prioritario para advertir al usuario.

Al crear este tipo de componente, es importante trabajar en conjunto con los UX Writers para entender los tipos de mensaje que se deben entregar y qué particularidades se deben considerar en el diseño, para dar énfasis en el mensaje que puedan ser un aporte real durante la navegación del usuario.

Antes de crear y diseñar un componente de este tipo es importante plantearnos las siguientes interrogantes:

• ¿Qué problemas, errores o acciones necesitamos alertar a los usuarios?
• ¿Qué mensajes de advertencia son críticos y que deben ser lo suficientemente reconocibles y encontrables en cada pantalla?
• ¿Cuántos niveles de severidad definiremos y cómo representaremos cada uno de ellos?
• ¿Qué idiomas debe soportar este alert y cuántos serían los caracteres máximos a considerar para que no quede un mensaje con una extensión exagerada que absorba o anule los otros elementos de la interfaz ?
• ¿Cuál es el icono más apropiado para acompañar a cada caso, o será solo uno estandarizado para todos los tipos de alertas como un signo de exclamación?
• ¿Es necesario considerar títulos, links o textos en “bold” o “itálica” para destacar algunas frases o datos claves como fechas, horas, documentos, nombres, lugares entre otros?
• ¿Cómo aseguramos la legibilidad de este componente, si debe coexistir con otros mensajes de forma simultanea? En ese caso, ¿cuál sería más importante? Se podría hacer un símil con el uso de TRIAGE en los recintos de urgencia médica y cómo se establece una escala de priorización para la atención de pacientes.

2. Las advertencias nos anticipan para evitar errores.

El rol del componente alert, como lo señala su nombre es alertar. Y si hacemos la analogía con las señales de tránsito en las ciudades, el uso de alertas como los letreros en las calles nos pueden ahorrar varios problemas o dolores de cabeza. Imaginen este escenario: van manejando e ingresan a una calle y unas cuadras más adelante se percatan que está cerrado el paso solo porque llegaron a una calle sin salida y vieron a otro auto hacer la maniobra para realizar el retorno. En ningún momento tuvieron una señal de alerta, como para prevenir el error, simplemente continuaron porque no había razón para no seguir, lo que los llevó a perder tiempo, bencina y energía. Esto mismo ocurre cuando nos enfrentamos a una interfaz, y en ciertos casos, necesitamos de alertas que nos anticipen a posibles escenarios que puedan ser inciertos o adversos.

Ejemplos de mensajes de alertas diseñados en nuestro Design System

3. Visualización de casos y mapeo de tipos de alertas

Cuando nos disponemos a diseñar un componente de alerta, es importante comprender que el uso de alertas debe estar cuidadosamente seleccionado. De lo contrario, terminaremos con interfaces saturadas de mensajes, en donde no es posible entender cuál es más crítico que otro. Ante esta realidad-bastante común en los sitios web- donde todo es importante y destacado, ninguno tiene un valor por sobre otro, por lo que anulan su objetivo primario de comunicación.

A partir de este escenario, diseñamos un componente de mensaje, que no necesariamente implicara un nivel específico de criticidad, sino que se podía utilizar para complementar información, o bien entregar más contexto durante ciertos flujos de navegación. Así creamos el componente “Message Info”. Este se distancia del alert, porque no incluimos en su diseño un ícono de advertencia, lo que nos ayudó a delimitar el uso de este nuevo elemento.

4. Establecer qué es y qué no es un alert message, para marcar los límites de su uso y no generar ambigüedades

Variantes del MessageInfo para seleccionar según el tipo de información a entregar

Usualmente la mayoría de los servicios digitales, abusa de los mensajes de alertas, y a partir de esta problemática que también padecíamos, decidimos como equipo crear un tipo de mensaje distinto, que no se percibiera como alerta y que facilitara la entrega de información relevante y complementaria, mas no critica.

Entonces, tomamos decisiones. Y cuando nos enfocamos en esto todo pasa a ser una decisión, no solo los estilos gráficos que utilizaremos y los tamaños del componente, sino también lo que decidimos evitar y eliminar.

5. Ejemplo de integración en pantalla

Durante el proceso de diseño de este nuevo componente, logramos definir los límites en el uso de alertas, y en qué casos aplicaría el uso del componente “MessageInfo”, y cómo para este último, no aplicaría la escala de severidad del alert ya que es un mensaje complementario y secundario en cuanto a jerarquía y peso visual.

Como se puede apreciar en la imagen de más abajo, el alert es un mensaje que no se puede remover, ya que su lectura y reconocimiento es importante para el flujo de navegación del usuario, en cambio, el MessageInfo es secundario, y su objetivo es complementar la información clave que se entrega, y que puede ser un aporte para los usuarios.

Ejemplo de pantalla en dónde interactúa un componente de alert y uno de message info

En toda construcción de un Design System, es importante considerar los niveles de severidad de los mensajes que se comunican y qué diseño responde mejor a nivel de Usabilidad y comprensión al tipo de mensaje a presentar. No se trata de que todo mensaje responda a alertas, sino de hacer un levantamiento en detalle de los tipos de comunicación a entregar y en qué momentos, para luego agruparlos en categorías primarias de información.

En nuestro caso definimos 4 niveles de agrupación:

• Tipo de comunicación: Alerta o mensaje
• Nivel de severidad: n/a, bajo, medio, alto
• Rol de jerarquía visual: secundario, complementario, primario, critico
• Visibilidad: Permanente, temporal, persistente

Esta matriz facilitó el trabajo para decidir qué tipo de componente utilizar y qué nivel de relevancia considera el mensaje a entregar. De esta forma, aportamos claridad en el proceso de decisión sobre qué tipo de componente emplear y no se abren espacios de confusión.