Retroalimentación: cómo mostrar el feedback en productos digitales
¡Hola! Soy Ana Vidal, Product Designer y Design Systems Specialist en Aplazame.
Cuando Andrea, en nombre del equipo de producto presentó el blog, os contó que nuestra idea era poder compartir nuestra forma de trabajar, y, en general, contar cómo hemos ido resolviendo problemas en Aplazame para intentar allanar el camino -desde nuestra experiencia- a quien pueda verse en los mismos apuros que nosotras.
Hoy me estreno en el blog con un artículo sobre cómo dar feedback a las personas usuarias y qué componentes usar para hacerlo.
La idea de escribir este artículo lleva rondándome la cabeza unos 3 años, ¡así que estoy muy emocionada de poder compartirla al fin! 🥳
Esperamos que podáis utilizar el contenido expuesto, o que os sirva como base si estáis pensando en hacer una revisión de cómo estáis retroalimentando a vuestros clientes.
¿Empezamos?
Un poco de contexto…
En un momento de duda existencial hace unos años, intentando encontrar una manera de unificar los elementos a través de los que nos estábamos comunicando a lo largo de un flujo, me encomendé -confiadísima- a San Google en busca de un artículo que diera respuesta al dilema.
Para ser sinceros y escribiendo claro, lo que quería era encontrar una regla para saber cuándo lanzar un modal, un toast, una notificación, un push o un banner y definir cómo se iban a usar los componentes del sistema de diseño que estaba creando.
Solo encontré best practices de cada uno de los componentes de manera independiente, o como mucho, alguna comparativa entre dos componentes.
Una de las partes más importantes y relevantes en los sistemas de diseño para crear consistencia en un producto es tener definidos unos buenos patrones y usos de los componentes y el diseño de interacción.
En ese momento comencé a investigar sobre cuál era la mejor forma de dar feedback y cómo podíamos aportar solidez al producto y confianza al equipo a la hora de diseñar la retroalimentación.
Vale… ¿de qué estamos hablando?
La retroalimentación es un estímulo que se muestra en forma de mensajes -textuales o ilustrativos-, que aparecen en la UI y aporta notas aclaratorias -más o menos relevantes- para la persona que lo recibe.
Las personas están acostumbradas a navegar por los productos digitales y recibir notificaciones que les ayuda a orientarse dentro de los flujos y procesos (visualizan qué es lo que ha pasado, está pasando o va a pasar), reduciendo la carga cognitiva y dotándoles de control.
Si no funcionan bien, corremos el peligro de que se frustren o se pierdan, e incluso terminen abandonando la página o aplicación.
Esta información tiene unas características específicas y se repite a lo largo de las interfaces de manera generalizada en forma de “componente”, agrupación de elementos o “señales”. Estos suelen ser comunes en todas las interfaces, así que las personas usuarias están acostumbradas a consumirlos:
- Snackbar / Toast: mensajes inmediatos y temporales sobre procesos en el sitio, dependiente de las acciones previas ejecutadas por la persona usuaria
- Alerta / Notificación: mensajes inmediatos que informan a la persona de alguna acción se ha llevado a cabo, no necesariamente dependiente de las acciones de dicha persona
- Modal / Diálogo: ventana obstructiva que aparece delante del contenido principal y lo deshabilita. Proporciona información crítica, o requiere una decisión o información relevante
- Estado vacío: páginas que se muestran cuando no hay contenido disponible
- Tooltip: caja interactiva que muestra texto complementario cuando la persona interactúa con el elemento que lo activa
- Banner: recoge mensajes destacados de diferentes tipologías
- Badge: insignia o indicador visual que hace referencia al grupo que acompaña
- Microanimación: a través del movimiento transmite el estado del elemento al que acompaña (o que representa)
- Push: mensaje corto e inmediato que se envía al dispositivo sin necesidad de estar en el sistema
- Input error: ayuda en vivo en un campo de entrada de texto que informa cómo resolver el estado de error
Creo que no me dejo ninguno, ️¿se os ocurre alguno más?☺️
¿Qué suele ocurrir con los feedbacks?
Diseñar una experiencia de usuario y un diseño de interacción de calidad pasa por analizar los componentes que se utilizan para realizar las retroalimentaciones a las personas usuarias y mantener los estándares a lo largo de toda la interfaz.
De manera general, en los proyectos suelen existir muchísimas incongruencias en cómo se muestra la información de retroalimentación. Estas inconsistencias suelen suceder por diferentes factores:
- Se construyen funcionalidades nuevas sin tener en cuenta el resto de feedbacks del producto (esto tiene que ver con los tiempos para creación de funcionalidades y la antigüedad de los productos). A más años, mayor posibilidad de que existan inconsistencias
- Las funcionalidades son creadas por diferentes diseñadores (con diferentes conocimientos, experiencias y percepciones). Influye tanto el tiempo que tiene el producto, como la actualización de las best practices
- No existe una revisión de la consistencia general del producto
- Falta de patrones y documentación sólida
Al lío:
Como no encontré esa regla general, creé una tabla basándome en cómo se activaba el componente, su urgencia, su contexto y el contenido que recogía.
Esta tabla es la que traemos hoy, revisada y actualizada. 🎉
En ella se compara, se define y se enfrentan los diferentes elementos que se usan para enviar feedback, según nuestros propios patrones de uso de componentes.
Gracias a ella hemos creado las reglas de uso en el sistema de diseño de Aplazame y estamos cambiando y puliendo las notificaciones que enviamos a nuestros clientes, tanto B2B como B2C.
En el esquema, el uso de los componentes quedan definido teniendo en cuenta los siguientes principios:
- Activación: si es activado por la persona o por el sistema
- Urgencia: Si el mensaje es urgente (urgencia alta), importante (urgencia media) o es informativo (urgencia baja)
- Contexto: si acompaña a un contexto específico (que suele corresponderse a un espacio concreto asociado a otros elementos) o global
- Contenido: el tipo de información que recoge: un éxito, un error, estados, recomendaciones, noticias, alertas, confirmaciones, selecciones, permisos…
- Agrupación: si pueden agruparse con otras notificaciones de la misma tipología o no
- Condicional: si aparece o cambia según las condiciones
- Transitorio / Persistente / Descartable: si es estático o transitorio; y en el caso de que se vaya, si lo hace de manera automática o puede ser descartable por la persona
- Interrupción: aplica a componentes que interrumpen la navegación y existen diferentes grados (molestia, bloqueo…)
- Número de acciones a despedir: pueden no tener acciones o tener varias
- Sonido: algunos elementos pueden ir acompañados de sonido para mayor retroalimentación 🎉
- Foco en accesibilidad: dependiendo de la importancia del componente (altísima, alta o media. El foco en accesibilidad nunca es bajo💙)
- Elementos: ¡un extra! Todos los componentes se construyen a base de elementos más pequeños. En la tabla podemos ver una muestra de los elementos “básicos” que debería llevar dicho componente (y los que van entre paréntesis son opcionales). Hay notificaciones que pueden requerir elementos ad hoc como campos de entrada de texto, selectores…
¿Cómo lo estamos usando?
Como habéis podido ver, se trata de una tabla que sirve como consulta y nos facilita el día a día a la hora de que cada una de nosotras diseñe una nueva funcionalidad o revise un flujo fijándose en cómo se deben estar notificando estados de confirmación, errores o solicitudes de documentación a las personas usuarias dentro de los flujos.
He marcado lo que más usamos en Aplazame, que son toast, modales y los hints de ayuda en campos de entrada de texto. Esto no significa que no tengamos el resto de componentes -los tenemos-, pero no existe tanta confusión con su uso como ocurría con estos tres a lo largo del producto.
El ecosistema de Aplazame se ha ido construyendo poco a poco (es decir, corriendo 😝). Ahora nos estamos tomando un tiempo para revisar y mejorar la experiencia de usuario en todas los flujos y productos, y esto también pasa por revisar la retroalimentación que estamos enviando y cómo la enviamos en cada momento.
La tabla es un análisis revisable y abierto a cambios, pero nos ayuda a mantener coherencia tanto dentro de un producto como entre ellos.
Y por supuesto, disponer de ella también nos ha ayudado a ir definiendo los patrones de nuestro sistema de diseño.
¡Esperamos que este post pueda servir -como a nosotras- para revisar la retroalimentación de los productos que estáis construyendo!
Os dejo el link a la tabla en Figma, por si queréis duplicarla y editarla 😘.
Si tenéis cualquier duda o pregunta no dudéis en escribirnos, estaremos encantadas de poder ayudaros 💙👇🏻
