Table of Contents
Quizás es porque muchas veces confundimos la Experiencia de usuario (UX) con la Interfaz de Usuario (UI), esta se asocia únicamente a la parte más visual de una web o aplicación.
En este artículo, aclararemos brevemente a qué hace referencia la experiencia de usuario, y comentaremos la experiencia de mis compañeros y mía aportando soluciones y mejoras en este aspecto para nuestra aplicación. Además veremos cómo esto impacta de manera directa en lo que se conoce como el Embudo de conversión. En definitiva, entenderemos cómo podemos aportar valor a nuestros usuarios, para que su experiencia con nuestra aplicación sea mejor y, de paso, mejoremos las ventas de nuestro e-commerce.
En primer lugar, me gustaría aclarar brevemente estos dos conceptos que he nombrado anteriormente.
¿Qué es la UX?
Según Wikipedia, la experiencia de usuario es el conjunto de factores y elementos relativos a la interacción del usuario con un entorno o dispositivo concretos, dando como resultado una percepción positiva o negativa de dicho servicio, producto o dispositivo. Dicha percepción depende no solo de los factores relativos al diseño (hardware, software, usabilidad, diseño de interacción, accesibilidad, diseño gráfico y visual, calidad de los contenidos, buscabilidad o encontrabilidad, utilidad, etcétera); sino de aspectos relativos a las emociones, sentimientos, construcción y transmisión de la marca, confiabilidad del producto, entre otros.
Es decir, cuando hablamos de la experiencia de usuario hacemos referencia a todo lo que experimentan nuestro clientes cuando abren nuestra aplicación o página web. Si les gusta o les emociona lo que ven, si encuentran lo que buscan y se sienten satisfechos, o simplemente no funciona bien nuestro marketplace y les causamos frustración, haciendo que abandonen nuestra web o app.
¿Qué es el embudo de conversión?
El embudo de conversión es un término de Marketing Digital que se utiliza en los e-commerce, que define el proceso de venta de un marketplace. Para entendernos, sería definición del flujo de todos los pasos que sigue un usuario desde que entra en tu sitio web hasta que realiza el pago de la compra. Se conoce como embudo, por el hecho de que en cada paso de ese flujo, se cae un porcentaje de los usuarios, que abandona tu página web o no sigue con el proceso de conversión. El estudio de este proceso se utiliza para minimizar esa caída de usuarios en cada paso, y mejorar así las ventas en nuestro e-commerce.
¿Cómo el backend puede ayudar a mejorar estos dos conceptos?
Ahora que tenemos ambos conceptos un poco más claros, podemos llegar a la conclusión de que ambos conceptos están relacionados. La experiencia de usuario impacta directamente en el embudo de conversión, es una parte fundamental de este. Si un usuario no comprende la aplicación, no se siente atraído por ella o no encuentra lo que busca de manera rápida y sencilla, simplemente se irá y se caerá del embudo de conversión, afectando así a las ventas de nuestro e-commerce. Sin ser yo experto en marketing, podría decir que hay dos maneras de mejorar las ventas: o atrayendo más gente a nuestro marketplace, mediante anuncios online, publicidad, etc., o mejorando el embudo de conversión evitando que el mayor porcentaje posible de nuestros usuarios pierda el interés en continuar en nuestro e-commerce. En este artículo vamos a centrarnos en la retención de esos usuarios que llegan a nuestro marketplace.
Ahora que tenemos una leve idea de que son estos conceptos de UX y embudo de conversión, quiźas os preguntáis, cómo desde el backend podemos ayudar a mejorar estas dos partes tan importantes del negocio, si nosotros solamente procesamos datos, no? Nosotros sólo almacenamos y servimos información o nos dedicamos a «hacer cuatro CRUDS», no?
Pues bien, en este artículo, relataré mi experiencia en algún proyecto, y cómo con unas pocas decisiones a nivel de arquitectura, logramos ayudar a mejorar tanto la experiencia de usuario como el embudo de conversión de nuestro e-commerce.
Para poneros en antecedentes, sin entrar mucho en detalle, mis compañeros y yo nos encontrábamos trabajando en un servicio backend que servía contenido a las apps del e-commerce en cuestión. Dicho servicio lo acabamos de migrar a Kubernetes, y habíamos montado la aplicación Java con un tomcat embebido en el propio spring boot. Este cambio, ya nos mejoraba muchísimo la performance, puesto que escalaba en un tercio del tiempo en el que escalaba antes de dicho cambio. Algunos ya empezaréis a sospechar que este cambio ya mejoró la experiencia de nuestros usuarios, puesto que el servicio de backend no colapsaba y escalaba de forma rápida y fluida, sin afectación sobre los consumidores.
Estáis en lo cierto, pero en este artículo quiero resaltar un par de cambios más sencillos que nos aportaron mucho valor y podría resultar de ayuda a vosotros los lectores de este artículo. En nuestro ejemplo, tomamos dos iniciativas: Mejorar los tiempos de respuesta y mejorar el contenido de manera dinámica.
Mejorando los tiempos de respuesta
Uno de los grandes problemas, y que causa más frustración a los usuario, que podemos solventar desde el lado del servidor, son los tiempos de respuesta. Los loaders infinitos provocan frustración en los usuarios, provocando que cierren nuestra aplicación o sitio web. Primero de todo, os animaría a estudiar vuestro negocio y vuestro servicio backend. Nadie debería entender mejor que vosotros el flujo de venta del negocio en el que trabajáis. Esto es fundamental para poder diseñar un plan de acción. Una vez comprendamos esto, podremos tomar mejores decisiones, como por ejemplo, decidir cómo agrupar los datos en llamadas. Hay que saber escoger cuando se obtienen los datos en una o más llamadas, encontrando el equilibrio entre el volumen de los datos y la latencia de cada petición, que penalizan la experiencia de usuario si nos excedemos en ambos casos. Cómo todo buen consultor, os diré que «depende». Cada uno de nosotros es responsable de entender nuestra aplicación, nuestro negocio, y tomar las decisiones en consecuencia a ello.
En nuestro caso, realizamos un estudio para encontrar las llamadas que tenían peor tiempo de carga. Eran la llamada de la homepage, la llamada a la página principal, parece razonable, trae información de muchos dominios distintos que se orquestan desde nuestro servicio de backend. Con esta premisa, parece sencillo decir: «Pues lo separamos en N endpoints y se hacen las peticiones en paralelo». Podría ser una solución, pero no en nuestro caso, lo vemos enseguida.
La otra página que tenía un tiempo de respuesta alto era la de navegación a las secciones de nuestra página, también muy importante para esos usuarios que saben lo que buscan y quieren ir directo al producto que necesitan. Fundamental también para cerrar esas ventas rápidas, sin causarles frustración, por tiempos de carga demasiado largos, que pueden provocar perder ventas que a priori estaban casi cerradas. Por razones del proyecto, la mayoría de dicha información, está relacionada, así que obligábamos a un postprocesado de los datos en el lado del cliente demasiado grande, aumentando el tiempo de carga de la aplicación, cosa que tampoco nos interesaba. Analizando estos datos, nos dimos cuenta de que el contenido era en su mayoría estático, y cambiaba unas pocas veces por semana.
Esta última información fue clave para tomar la alternativa correcta: poner una caché delante de nuestro servicio dentro del CDN. Esto tiene 2 mejoras, una directa y una indirecta:
- La primera es que se servía casi instantáneamente, en el caso de la homepage, la mejora más significativa, el tiempo de respuesta pasó de unos 5-6 segundos a menos de 100ms. Como podéis adivinar, el impacto sobre el usuario es muy grande. Esta iniciativa ayuda a la venta impulsiva, puesto que no hacemos esperar al usuario, le damos lo que quiere al instante, rebajando la frustración al entrar en nuestro marketplace de manera radical.
- Por otra parte, hay un impacto de mejora indirecto. La mayor parte de nuestros usuarios consultaban en el inicio del flujo de compra esas dos páginas sobre las que pudimos realizar las mejoras. Al atacar contra una caché la mayor parte de las peticiones a nuestra aplicación no llegaban al servidor, la caché respondía a esas peticiones, aliviando así la carga de nuestro servicio, mejorando significativa la performance y disminuyendo la necesidad de tener muchos pods levantados en Kubernetes (mejorando también así nuestra factura mensual), tal y como vemos en la imágen.
Con esto experimentamos una mejora muy significativa en nuestro negocio, pero aún así, fuimos a por el bonus extra. Un compañero de apps me comentó la posibilidad de incluir en la respuesta del servidor/cache un header que definía ttl de la caché local de los dispositivos. Con esa información, los propios dispositivos de los clientes, almacenaban durante ese tiempo la información en sus cachés propias. Esto implica que las peticiones para esas llamadas no llegaban a salir del dispositivo del cliente, evitando así la latencia por realizar la llamada a nuestros servidores, ya sea al servicio o a la caché, y aliviando una vez más la carga sobre estos.
Mejorando nuestro contenido
Otra posibilidad de mejora que detectamos, era el tiempo que tardamos en cambiar el contenido de nuestra app. En el momento inicial, necesitábamos redesplegar el servidor con las configuraciones en unos ficheros estáticos. Como podéis suponer, esto nos limitaba mucho, requería de cierta planificación, se desplegaba ciertos días a ciertas horas, etc. Esto nos limita muchísimo para experimentar y mejorar nuestro embudo de conversión. La mejor solución técnica pasaba por montar un panel de administración que permitiera al negocio realizar los cambios de imágenes, secciones, etc. por su cuenta, sin necesidad del equipo técnico. Esta solución requiere de un esfuerzo y tiempo, que por necesidades del proyecto, no era posible en ese momento.
La imposibilidad de aplicar la mejor solución no implica que no podamos buscar soluciones intermedias que nos den mucho valor y no requiera de más dedicación de la que le podemos dar en el momento en el que estábamos. Así que tomamos la decisión de realizar una primera iteración: externalizar las configuraciones. Los ficheros que recargábamos en los despliegues pasaron a estar externalizados en un S3 de Amazon Web Services, y nuestro servicio lo consultaría y almacenaría en una caché interna (una vez más, para reducir latencia), cada cierto tiempo. Esto nos permite cambiar la configuración en cualquier momento, de forma independiente al servicio, dándonos muchísima flexibilidad a la hora de poder variar nuestro contenido, hacer experimentos, desactivarlos, reordenar secciones, etc. para mejorar la experiencia del usuario de una manera rápida, ágil, flexible e independiente del servicio.
Esto obviamente sabemos que es una solución intermedia, antes de llegar a la óptima, por ello, realizamos este desarrollo, basándonos en arquitectura hexagonal, de manera que el dia de mañana, solo tengamos que modificar la implementación de cómo conseguimos los datos, respetando la interfaz definida en nuestro dominio. Así, el día de mañana, ya sea por una petición http, una llamada a base de datos o cualquier otra solución de cómo queramos recoger esos datos que habrán especificado desde negocio a través de un panel de administración, podremos aprovechar el resto de la implementación que hemos hecho ahora en esta externalización de los ficheros de configuración.
Esta solución intermedia, puede parecer una tontería, pero nos ha dado muchísimo a nivel de negocio. Podemos cambiar a cualquier hora, en cualquier momento el contenido, sin tener que hacer un redespliegue de todo el servicio, evitando así los riesgos que puede conllevar. Además de poder cambiar dicho contenido o rectificar posibles errores de una manera mucho más rápida y sencilla. Esto facilita que nuestra aplicación cambie de manera más habitual, dando así al usuario una sensación de que siempre tiene algo nuevo que ver, mejorando el engagement y la fidelización con nuestro negocio, provocando, una vez más, un aumento de ese embudo de conversión.
Conclusiones
En este artículo, hemos podido ver como con dos pequeños cambios, sin apenas dificultad técnica, hemos mejorado muchísimo nuestro negocio desde el mismo backend. La clave está en entender la necesidad que tenemos como desarrolladores de comprender nuestro negocio y trabajar lo más cerca posible de él, para poder entender sus necesidades y descubrir sus puntos de mejora. Personalmente me parece algo fundamental que puede marcar muchas diferencias, más allá de buscar la excelencia que a veces no podemos conseguir a nivel de código. No todo es blanco o negro, si no te dejan aplicar la mejor solución ahora, siempre puedes pensar en como cubrir esa necesidad con una solución intermedia que aporte valor, como hemos visto en este último caso, pero para ello, es imprescindible comprender tu negocio para poder aportar valor.
