Validar

Por esta razón, por todas estas cuestiones, en Ebury nos decidimos a establecer un framework y una metodología de validación que nos ayudara, como mínimo, a reducir la incertidumbre.

Respecto al framework, quizá habréis oído hablar de las métricas HEART propuestas por el equipo de investigación de Google. Éstas tienen como objeto medir experiencias de usuario a gran escala en base a cinco indicadores:

  • Happiness: actitud o satisfacción.
  • Engagement: cuánto interactúa una persona con un producto.
  • Adoption: número de usuarios nuevos por un período de tiempo.
  • Retention: número de usuarios que mantenemos activos por una cantidad de tiempo.
  • Task Performance: tiempo y/o esfuerzo para realizar una tarea con éxito.

Lo bueno de partir de un framework como éste es que resulta muy fácil de entender y de comunicar a través de distintos equipos. Además genera un debate interesante, cuando el equipo tiene que decidir sobre qué señales son indicativos de ‘felicidad’ – ¿hacemos encuestas? ¿recogemos feedback a través de un formulario en línea? ¿Hacemos sentimental analysis sobre los comentarios que nos dejan en un foro? – o ‘retención’ – cuando comparamos usuarios nuevos con usuarios recurrentes ¿qué características hacen que sea una persona sea considerada ‘nueva’?. En cualquier caso, lo importante en estos casos es tener un criterio común.

La parte más desafiante según qué empresa es la de establecer una cultura y unas herramientas que permitan la recolección de esos datos de una forma relativamente sencilla. Os invito a explorar tanto el blog de Research como el de Technology de Netflix para que entendáis hasta qué punto están estas ideas en su ADN.

Ebury Framework – Design with data –
https://labs.ebury.rocks/2019/01/14/visualizing-user-experience-data-part-i/

Nosotros empezamos de menos a más, partiendo de cosas muy sencillas. Primero revisamos los servicios que ya teníamos en marcha recogiendo información de usuarios: Google Analytics (servicio de analítica web), Inspectlet (servicio de grabación y reproducción de sesiones de usuario, al estilo Hotjar o Fullstory) e Intercom (servicio de chat que nos permite dar soporte a los clientes en tiempo real). Como no queríamos lidiar con tres APIs diferentes encontramos Segment (un modelo de datos que permitía conectar aplicaciones como fuentes y destinos de datos). Lo que nos abrió la posibilidad de experimentar y añadir más servicios de almacenamiento de datos (como Big Query) y de analítica, probar cuáles funcionaban mejor, cuáles no, etc. Ésta idea de interactuar con un único API (el de Segment) ya la teníamos en mente cuando nos montamos nuestra propia librería en JS (huha.js, disponible en Github) para recoger y enviar eventos de interacción y de usuario desde la aplicación web.

Respecto a los datos que identifican a los usuarios sólo los incluimos los descriptivos y relevantes (nada de sexo o edad), por ejemplo el tipo de cliente que es, qué permisos tiene activo, qué idioma tiene configurado o a qué oficina está asignado. Además añadimos datos relacionados con su contexto, para saber desde dónde se conectan, si están en un entorno de producción, de desarrollo o de demo.

Para los eventos de interacción decidimos no sólo enviar eventos sencillos disparados por una interacción (un click en un enlace, por ejemplo para saber el número de descargas de un documento determinado). Sino que queríamos crear un modelo de tarea que nos permitiera recoger información parecida a la que obtendríamos de la realización de un test de usuarios convencional. Cuando se realiza un test de usuarios, a los participantes se les da una serie de objetivos y de ellos (además de observar la experiencia) se mide el inicio y el fin de la tarea (el resultado, con o sin éxito) y cuánto tiempo, esfuerzo y errores le supone a un usuario realizarla. Esta misma información es la que recoge el Modelo de Tarea de forma automática y masiva.

Lecciones aprendidas

En la actualidad, ese framework no se limita sólo a resolver las dudas existenciales del equipo de diseño, sino que es utilizado por los equipos de producto, datos y desarrollo tanto para conocer el impacto de estos datos en el negocio, como para descubrir y resolver posibles problemas de la plataforma (que no existen, nuestra plataforma online es perfecta).

Durante todo este tiempo jugando y experimentando con datos hemos aprendido ciertas cosas que me gustaría compartir:

Más no es siempre mejor

Hay que ser honestos con lo que se quiere saber de verdad, debemos recoger los datos justos y necesarios. Más no es siempre mejor y de hecho los científicos de datos lo saben, nosotros también tenemos que hacerlo, hay que limpiar, filtrar y comprobar la integridad de los datos antes de realizar ningún análisis.

Hay que dejar margen a descubrir cosas inesperadas

Incluso aunque estemos seguros de que una solución de diseño en base a un estándar o un patrón es predecible, obtener datos y combinarlos con otros nos puede ayudar a descubrir y a aprender cosas que no esperábamos y no formaban si quiera parte de nuestras hipótesis iniciales.

No todas las métricas significan ‘conversión’

Ésto se explica muy bien en el libro ‘Designing with data’ donde se explican las diferencias entre el diseño dirigido por datos (como la ejecución sistemática de tests A/B) y el diseño informado por datos (donde el equipo utiliza los datos junto con otras fuentes de conocimiento para tomar decisiones).

No todas las métricas significan ‘conversión’, hay datos más allá del test A/B hay datos que hablan de las actitudes de las personas por ejemplo. Datos que nos hablan de cómo son y cómo se comportan las personas que de verdad utilizan el producto y que no necesariamente tienen por qué servir como KPIs del negocio.

Conocer a tus usuarios es un privilegio

Conocer a tus usuarios es un privilegio. Hay que crear oportunidades para que en tu compañía conozca más sobre la gente que usa el producto. Hay que explicar y mostrar cómo el proceso de diseño puede convertirse en algo experimental y el diseño experimental es algo esto favorece la innovación como en el caso de Netflix. Antes recomendaba el blog de Netflix, Spotify también lo hace fenomenal compartiendo sus descubrimientos a través del blog:

— Un ejemplo de la importancia del contexto cuando analizamos los datos nos viene de la mano de Spotify. Spotify sabe que la música que escuchamos no depende sólo del estado de ánimo que tenemos actualmente sino también del que queremos tener, o de la actividad que vamos a realizar, no es lo mismo la música que escuchamos cuando nos dirigimos a un sitio, que cuando hacemos ejercicio o cuando trabajamos. Pero además Spotify sabe que nuestros gustos musicales cambian según la estación del año, por lo visto en Invierno escuchamos más música ‘local’ (asociada a nuestro país) que en otras estaciones del año. Ellos suponen que es porque a la gente le gusta volver a sus raíces en esta época del año. Los mismos datos que revelan un patrón determiado, pueden servir para iniciar una investigación cualitativa.

Ningún usuario va a pedirte datos

Ningún usuario va a pedirte datos, nadie va a decirte ‘por favor observa lo que hago y analiza estadísticamente si puedo hacerlo mejor’, sin embargo, existe una obligación de contarles para qué se usan esos datos: ¿estamos mejorando el diseño, el soporte (cuando hay fallos y podemos reproducir lo que los usuarios hicieron)? ¿o forman parte del modelo de negocio?

Por otra parte la personalización es una expectativa y esto se consigue gracias a recoger información contextual e individualizada. Eso sí, una cosa es permitir a tus usuarios ajustar contenidos a sus necesidades e intereses y crear un sistema inteligente de recomendaciones, y otra es asumir intereses en base a prejuicios y limitar la visibilidad de ciertos contenidos sin que las personas sean conscientes.

Previous ArticleNext Article
UX Lead at Ebury and graduated as a Computer Engineer at the University of Granada. In the past, I've worked as a teacher, consultant, and developer. Designing valuable technology for people is what I enjoy the most.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.