Crear una gran experiencia de usuario fuera de su aplicación

Recientemente tuve la oportunidad de hablar con DevOps Minneapolis acerca de verdadera naturaleza de la experiencia del usuario . La audiencia encontró esta información particularmente interesante, así que pensé que sería útil compartirla con una audiencia más amplia. Esta publicación será la primera de una serie de tres publicaciones que analizarán la experiencia del usuario más allá de la interfaz de usuario de su aplicación y cómo puede optimizarla.

Entonces, ¿dónde está tu experiencia de usuario? En términos más generales, ¿dónde ocurre su aplicación? Para quienes trabajamos en SaaS, la respuesta es simple: la aplicación ocurre dentro de la interfaz de la aplicación. Ya sea que vendamos herramientas comerciales o enseñemos español, la aplicación sucede cuando nuestros usuarios acceden a la interfaz de usuario.

Tu UX está dentro de tu aplicación… ¿verdad?

Cuando hablamos de que nuestros usuarios tienen una buena experiencia, esa UX tan cacareada, las cosas que estamos modificando estarán dentro de esta aplicación. Contamos con varios especialistas que se preocupan por la experiencia del usuario. Ya sea que se trate de UX pensando en usuarios existentes o personas de datos y productos, asegurándose de que la experiencia para los nuevos usuarios sea fluida.

No pretendo trivializar este proceso: es mucho más que ajustar colores y mover botones un píxel. Los encargados de UX a menudo tienen que hacer las preguntas más básicas: ¿qué quieren nuestros usuarios y cuál es la mejor manera de dárselo? Esto es importante porque, por muy buena que sea nuestra tecnología detrás de escena, si el usuario no tiene una buena experiencia con ella, es poco probable que regrese.

Este artículo argumenta que hay una experiencia de usuario más importante que la que se encuentra dentro de su aplicación. De hecho, su aplicación tiene una interfaz completa que tiene más impacto en sus usuarios, que los toca más profundamente que la interfaz de su aplicación.

Son tus notificaciones

Aquí es donde realmente suceden sus notificaciones.

Muchas de nuestras aplicaciones favoritas interactúan en gran medida con nosotros a través de notificaciones, los ejemplos están en todas partes.

• Las herramientas de observabilidad y seguridad tienen con mayor frecuencia toda nuestra interacción a partir de las notificaciones. Después de todo, probablemente no estemos revisando nuestras herramientas APM hasta que sepamos que algo anda mal.

• Para las aplicaciones de redes sociales, el mejor momento que experimentamos con ellas es ver que a X personas les encantó nuestra publicación.

• Y para las aplicaciones de comunicación y colaboración, las notificaciones deben tener la mayor parte de la información que la gente quiere que veas.

  
  

De hecho, diría que para muchas de nuestras herramientas y servicios más valiosos, la mayor parte de nuestra interfaz, para bien o para mal, es a través de notificaciones. Las notificaciones te llevan a la aplicación. Proporcionan tranquilidad, advertencias, ansiedad o notificaciones molestas sobre las ventas de pizza. Las notificaciones son tu aplicación.

Menciono todo esto porque creo que tu UX está en peligro. Principalmente, la experiencia de las notificaciones se ha cedido a equipos fuera del equipo del producto. En lugar de que nuestro equipo de productos controle las notificaciones, son los equipos de operaciones o marketing/crecimiento los que controlan la mayoría de las notificaciones que enviamos.

Déjame mostrarte hasta dónde nos hemos desviado de la luz de Di-s:

La historia de la campaña de registro

El tiempo después de que un usuario crea una cuenta es crítico para cualquier herramienta SaaS. Incluso cuando los usuarios se registren y comiencen a usar el producto de inmediato, habrá funciones o casos de uso extendido que nosotros, los desarrolladores, queremos que prueben.

Póngase en el lugar de un equipo de producto que está tratando de mejorar la velocidad a la que los nuevos registros se convierten en usuarios comprometidos. En (casi) todos los equipos de productos, nos daremos cuenta de que queremos ponernos en contacto con los usuarios después de que se registren para alentarlos a continuar con nuestro producto.

Sin duda, la plataforma envía una confirmación de registro, y empezamos por ajustar eso. Obtenemos nuestra nueva copia y enlaces al equipo de operaciones o al desarrollador de la plataforma, y ellos cambian el correo electrónico posterior al registro. Pero pronto, queremos más. En primer lugar: no queremos enviar correos electrónicos a los usuarios en el momento en que se registran, nos gustaría esperar al menos unas horas, para que la plataforma se sienta un poco familiar primero. Luego nos gustaría hacer un seguimiento después de unos días, y unos días después de eso.

Mejor aún, a nosotros, el equipo de producto, nos gustaría personalizar un poco estos mensajes, según el tamaño de su equipo, la licencia que tengan, etc. El equipo de operaciones, que implementa todas las notificaciones salientes, está un poco frustrado por esto. Están acostumbrados a resolver errores y solicitudes de funciones para la plataforma, no a modificar un correo electrónico. ¿Planificación? ¿Personalización de la audiencia? Esto suena como un trabajo para….

El CRM, donde por un tiempo fue bueno

Con toda la necesidad de orientación personalizada, una buena primera solución es enviar un registro como un evento a una herramienta de gestión de relaciones con el cliente (CRM) como Salesforce. A partir de ahí, es fácil iniciar una 'campaña de registro'. Dado que el CRM debe saber cosas como el tamaño de la organización y el nivel de licencia del usuario, los mensajes se pueden personalizar muy bien.

Y durante un tiempo, fue bueno. Sin embargo, los problemas comienzan cuando vamos un paso más allá con la orientación y la personalización.

Verá, nuestra campaña de registro alienta a los usuarios a usar ciertas funciones, como, por ejemplo, Exportación de informes. Queremos contarles a los usuarios sobre la característica, hacer una demostración para ellos, guiarlos a través del concepto. "Por favor", ruegan nuestros correos electrónicos, "exporte sus informes, con Reports Export".

Este mensaje parecerá súper raro si el usuario ya ha usado Reports Export. Entonces, nosotros, el equipo de producto, nos dirigimos a quien ejecuta el CRM y le decimos '¿podemos cancelar este correo electrónico si han usado la Exportación de informes?' Por supuesto, el CRM no lo sabe. Así que terminamos de nuevo con la ingeniería de la plataforma, pidiéndoles que envíen un evento al CRM cuando alguien usa Reports Export por primera vez.

La solución 'rápida y sucia' de CRM no fue una solución duradera para nuestro problema.

El problema es una cesión de territorio

El problema inherente en el escenario anterior es una cesión de territorio por parte del equipo de producto. Si el equipo de producto quisiera mover un botón o cambiar el orden de una barra de herramientas, no tendría sentido que el equipo de marketing dijera 'no'. Pero cuando queremos enviar una campaña de registro correctamente dirigida, nuestra confianza en nuestro CRM significa que Marketing tiene que decir 'no' a una mejor experiencia de usuario.

Del mismo modo, no dejaríamos que las operaciones o la ingeniería de la plataforma nos impidan agregar una información sobre herramientas útil, pero estamos permitiendo que nos impidan enviar un correo electrónico útil a los usuarios correctos.

Qué podemos hacer para resolver el problema

El problema aquí es la falta de herramientas, ya sea externas o internas. Cada nuevo flujo de notificaciones requiere tiempo de ingeniería, y eso significa que las limitaciones técnicas nos impiden brindar la experiencia que merecen nuestros usuarios.

Ya sea mediante el uso de Courier o un pico interno para crear un microservicio de mensajería, desea desarrollar un conjunto sólido de características que faciliten el envío de múltiples tipos de notificaciones directamente desde su plataforma.

También publicado aquí .