Validando un caso de uso como Product Designer, no como UX/UI.

Hoy podemos dar por hecho que las personas que diseñan producto lo validan, por lo tanto, podemos dar por superada esa etapa. Aquí la pregunta es ¿Cómo se validan las cosas?¿Cómo sabemos si algo funcionará antes de ponerlo a producción?

Si esta pregunta se la haces a una persona que acaba de salir de un bootcamp de UX/UI te dirá “Haciendo test con usuarios” o “Entrevistas”, “Haciendo discovery” por ejemplo. Está bien, pero vayamos un poco más allá. Esas técnicas desde mi punto de vista se quedan un poco atrás en el mundo de los datos, multicanalidad, pluralidad…etc. Pueden valer para un discovery inicial, pero ya está. A más de una persona le ha debido salir unos salpullidos al escuchar las palabras “Validar con datos”.

Realmente está bien ver de forma cualitativa y hasta cuantitativa si hacemos una encuesta, pero no siempre nos vale. De acuerdo, podemos testear a 100 personas con Maze de forma remota no mederada, pero el contexto no siempre lo permitirá.

Tenemos una hipótesis: “La conversión de compra será más alta si no hacemos registrar ni loguear a los usuarios”.

Una cosa es lo que dicen los usuarios, otra es lo que acaban haciendo.

Idea inicial y el caso de uso

Hace un tiempo, un compañero del sector me hizo una pregunta muy directa. Curiosamente, esa pregunta me la encontré en 3 empresas donde trabajé. (Privalia, Colvin, Docplanner)

En nuestro ecommerce actualmente obligamos a los usuarios a registrarse para realizar una compra ¿Cómo puedo ver si realmente es mejor dar la posibilidad de realizar la compra sin registrarse? ¿Qué aporta a la empresa y al usuario?

¿Qué información tenemos?

• Es super habitual estar registrado en una web para poder comprar… vale sí, que lo hagan todos no significa que sea lo mejor. Tras hacer un benchmark, el 100% de la competencia lo hacía así.
• El equipo de UX de mi amigo ya hizo un test, como todos podemos imaginar en los resultados, 18 de 20 usuarios no querían registrarse o no le veían valor.
• Aplicaron “Social Login” en el pasado: El gasto medio de carrito y el ratio de abandono con el logueo de redes sociales es mejor respeto el registro normal por email. Al ser un poco mejor, potenciaron esta opción, el % de conversión subió, pero muy poco. No entraré al detalle, pero para la empresa tener registrados los usuarios con redes sociales no es la mejor opción. ¡Ojo, en mi caso Amazon nos prometió un 15% más de conversión si lo hacíamos! Ya podéis imaginar que lo hicimos y no subió un 15%.
• El equipo de desarrollo a valorado el coste para que los usuarios puedan realizar la compra sin la necesidad de registrarse. El coste es muy alto, ya que no implica solo un tema de flujos, sino de base de datos y como se gestiona internamente “cliente-pedido-producto”. Aquí ya dejo de lado la relación número de pedido con el Saas de customer support.
• Tener registrados a los usuarios conseguirás segmentar y potenciar las compras según sus necesidades, enviar descuentos o ventajas, contactarles más fácilmente y solucionar posibles problemas, conocer el tiempo que tarda en volver a comprar en tu tienda… y un sin fin de métricas. Recuerda que si las cookies no caducan en X tiempo, durante ese tiempo, cada vez que el usuario accede a la web, le puedes ofrecer una compra personalizada y contextualizada según las compras anteriores.
• Si dejamos que los usuarios no se registren, perdemos funcionalidades vitales para la empresa como es la recomendación entre clientes (Refer a friends). El refer a friend suele ser muy utilizado ya que el coste de adquisición de un cliente mediante esta forma vs otras suele ser mucho mejor.
• Otra de las funcionalidades que podemos perder si no están registrados son funcionalidades como “guardar como favoritos”, “crear un wishlist”. Estas funcionalidades realmente aumentan la conversión por parte de los usuarios.
• ¿Y si buscamos un punto intermedio? Por ejemplo, en vez de obligarles a registrarse al abrir la página, que lo hagan antes de iniciar el proceso de compra o quizás justo antes de pagar… o como decía mi colega, que no se registren nunca.
• Si es la primera vez que un cliente accede a tu web, menos va a querer que registrarse y que le pidamos datos, antes o después. No te conoce.

Como ves son muchos los puntos que se han tenido en cuenta antes de realizar cualquier acción, los costes pueden ser muy altos o no… Todo depende de como lo pruebes. :)

Las opciones que tenemos:

Estamos hablando de un ecommerce donde el usuario compra algo y le llega a casa. Podría ser aplicable otras opciones aunque sea un producto digital.

A: Registrarte o loguearte antes de acceder

La descartamos por completo. Solo lo utilizan aquellos ecommerce con un cierto mercado o quieren ofrecer una visión exclusiva a sus clientes, como podrían ser algunos ecommerce como Privalia.

B: Registrarte o loguearte para iniciar el proceso de compra

Este es el más habitual en los ecommerce, el usuario busca los productos que le gustan más, los añade al carrito. Una vez a tomado la decisión de empezar el proceso de compra, se le pide que se loguee o que se registre. Aquí podemos perder usuarios, ya que para poder realizar la compra le estas obligando hacer algo que no quiere o simplemente no espera. Aquí el truco es decirle lo importante que es “para el usuario” estar registrado, como poder recuperar dirección de envío, formas de pago, compra en un click, descuentos de cupones personalizados… etc.

C: Registrarse justo en el momento de pagar

Puede parecer muy raro pero cada vez son más las empresas que deciden hacer el proceso de registro o login en este punto. Mentalmente el usuario ya hizo un “esfuerzo” rellenando todos los datos de dirección, fecha de envío, dedicatorias (si el ecommerce lo permite), configuración de la compra… el hecho que le pidas ahora registrarse para pagar quizás no será tan doloroso, el esfuerzo más grande ya lo hizo. Aquí el punto es que el dinero es el dinero, y justo cuando el usuario iba a introducir o seleccionar la forma de pago le estamos bloqueando. Este es un punto muy crítico para el usuario (abandono total de la compra) o para ti (ingreso de dinero).

D: No pedir registro, no hace falta.

Dejaremos esta opción, el usuario escoge lo que quiere, aunque como vimos en los resultados del test la gran mayoría no se registraría para realizar la compra.

En este punto hay que dejar claro al usuario lo que perderá si no lo hace, realmente podríamos ofrecerle muchas ventajas. Las ventajas y como diseñar esta parte daría para otro artículo :)

Tenemos 3 opciones:

• La B, la opción más habitual y la que actualmente tiene ese ecommerce.
• La C, una opción un tanto agresiva pero evitaría un abandono previo por parte del usuario y este ya ha rellenado toda la información.
• La D, crítica para la empresa. Sin datos de los usuarios no hay paraíso ;)

Aquí como product designer las preguntas que nos debemos hacer son:

• ¿Cómo impactará en el negocio cada una de las opciones? No solo a nivel de “dinero”, sino retención de los clientes, carrito medio de compra, abandono de compra…
• ¿Cómo impactará en los equipos de support y marketing cada una de las opciones?
• ¿Cómo impactará a nivel de usuario, confianza, satisfacción…?

Si pensáramos solo en mentalidad UX nos quedaríamos seguramente con la última pregunta.

¿Qué sucede actualmente en este ecommerce?

Los usuarios hacen algo que tienen integrado en su ADN digital, se registran una vez empiezan el proceso de compra, es decir, antes de introducir cualquier dato como dirección de envío, se loguean o se registran.

Partiremos de unos datos ficticios (bastante habituales), no vaya a ser que mi colega me bloquee:

• Ratio de conversión mobile: 5,3%
• Ratio desktop: 12,5%
• Ratio tablet: 10%
• El 85% de los usuarios acceden mediante dispositivos móviles.
• El carrito medio mobile es de 34€, desktop 58€, muy parecido al de tablet.

Entendiendo el ratio de conversión como el total de usuarios que acceden a tu web o app y acaban comprando. El carrito medio es el total quitando descuentos aplicados por los usuarios en sus compras como por ejemplo el de Refer a friend o códigos de descuento de influencers.

Hay un dato muy interesante, aunque la UX en mobile y desktop sean las mismas, el ratio de conversión es muy diferente. ¡Ojo! el gasto medio también es muy diferente. Ahora es cuando los Product Owners tienen que sacar la calculadora y ver si realmente hay que poner tanto esfuerzo en mobile cuando la conversión y carrito medio en desktop es mucho más alto que en mobile.

¿Os suena de algo la frase de “en mobile hay mucho más tráfico”? Hace falta analizar bien los datos y ver si hay que hacer mucho caso a ese dato.

Esos datos son ficticios pero el ratio se suele cumplir en muchos de los ecommerce que os podéis encontrar. Más tráfico en mobile = más compras en mobile, pero quizás el CR es más alto en Desktop.

Si ahora quieres ir mucho más al detalle, tendríamos que comparar otro tipo de información:

• Usuarios que ya están logueados vs los que no lo están.
• Aquellos que vienen de redes sociales, tráfico orgánico o directo.
• Usuarios que como mínimo hicieron una compra en el pasado vs los que no tienen ninguna.
• Veces que accedieron a la app o web antes de comprar.
• Comparativa entre países. La forma de compra de los países latinos es muy diferente a los países nórdicos. Realmente factors como la confianza y comunicación son muy importantes en los países de Europa central y del este.

Antes de hacer cualquier cosa en los flujos y mejoras en la UX, es muy necesario tener en mano esos datos para poder tomar decisiones y defenderlas.

Voy a dar por supuesto que actualmente estamos traqueando cada una de las interacciones que hace el usuario en nuestro ecommerce, tanto a nivel de analítica como podría ser GA o MixPanel y a nivel recording/heatmaps como podría ser con Hotjar.

Sin esto último podemos decir que estamos más ciegos que Don Cieguin. Es verdad que tendremos ciertos datos básicos de analítica web pero no son todos los datos que nos gustaría tener como product designers.

Paso 1: Validación de compra sin registro, en la pantalla de login o registro

Puede parecer muy difícil pero os confieso que simular la idea y testearla en real es muy fácil y rápida. No hay que tener miedo, apóyate de esa o ese developer que le gustan estos temas.

Actualmente el usuario puede loguearse con las redes sociales o con su mail.

Versión B: El usuario realiza el login o registro al iniciar la compra

En este punto queremos validar que pasaría si en esta pantalla le damos la opción al usuario de continuar sin registrarse o loguearse. Podríamos hacer un diseño muy bonito, testearlo con usuarios y decir al Front y Back que hagan su magia. Aquí no sabemos que pasará y como hemos comentado, el coste de hacer esto es muy alto si no estamos seguros de como impactará a todas las métricas. Recuerda, una cosa es lo que te dicen los usuarios en un test, la otra es lo que harán realmente.

Testeemos todo esto con un test A/B

Tenemos muchas herramientas para realizar test A/B sin depender de los desarrolladores, por lo tanto, podremos testear algo y ver como afecta con poco tiempo y recursos. Puedes utilizar herramientas Optimizely o AB Tasty. Anteriormente teníamos Google Optimize pero Google dejó de darle continuidad, tristeza máxima.

La variante que montaríamos con la herramienta de test a/b sería parecida a lo siguiente:

• Añadimos un botón de “Continuar sin registrarme”.
• Al pulsar el botón, mostraría una modal informando a los usuarios que esta funcionalidad aún no está disponible.

Como buenos y buenas product designers no tendríamos una sola variante a testear:

• No estamos seguros del claim del botón,
• Ni la prioridad de cada uno de los botones de login o registro,
• Ni tan siquiera el orden de los botones 🤯 Os aconsejo que primero se haga un test a/b de toda la vida (para validar la idea principal) y luego haced el test multivariante.
• No sabemos si realmente funcionará mejor en la pantalla de registro, la de login o en ambas.
• No olvidemos que no es lo mismo testearlo para usuarios españoles, que alemanes, por lo tanto deberemos ver en las analíticas que sucede en los diferentes perfiles de usuario. (país, edad, sexo, tipo de dispositivo, productos en la cesta …)

Lo malo de los test multivariante es que el tráfico que necesitamos para realizarlo es más alto ya que no solo testeamos una variante.

Os recomiendo utilizar una calculadora de a/b test para ver el total de usuarios que necesitáis para saber si los resultados de vuestro test pueden ser válidos. A su vez, poder ver que variantes son mejor que otras en conversión.

En resumen, testeemos lo básico validando si realmente hay un interés real por realizar la compra sin registrarse.

¿Realmente es necesario que lo hagas tu?

Soy de hacer las cosas yo mismo si puedo hacerlo, pero entiendo que no siempre será posible. En muchas empresas los test a/b los lanza el equipo de desarrollo. El equipo de Back lanza los test desde el servidor y el equipo de Front monta las variantes. Eso sí, tendrás que tener en cuenta que el equipo de Back y Front tienen su backlog, por lo tanto deberás defenderlo para que se priorice y se ponga en el siguiente sprint.

Hemos lanzado un test a/b ¿Ahora qué hacemos?

Primero de todo tendremos que ver los resultados de test y validar si realmente hay un interés en esta nueva funcionalidad. El interés no solo lo validamos en la conversión, no os quedéis en los resultados básicos, intentad entender por que ha pasado eso y que pasa para cada tipología de usuario. ¿Podemos hacer un patrón con los resultados?

A) El resultado a sido desastroso:

Si el resultado del test no os dice nada de nada o simplemente no mejora nada… os recomiendo dejarlo aquí, por lo menos ahora mismo. Hemos validado una hipotesis. Revisemos los datos y veamos si realmente se podría hacer el test de otra forma.

B) Una o varias variantes ha ido bien

Si esta es la opción, felicito a mi colega :) Su hipótesis es buena. El siguiente paso sería preguntarnos en que momento es ideal que le digamos a los usuarios que pueden realizar la compra.

¿La conversión al principio del funel será mejor o peor que poner esta opción antes del paso de pago?

Técnicamente, como sucedía en la primera parte, pasar el paso de autenticación antes del paso de pago es aún más complicado. Por lo tanto, de alguna forma deberemos poner un botón para que los usuarios lo pulsen y veamos la conversión. (Cuando hablo de conversión en el funnel no solo es el total de compras/total usuarios, sino que % de usuarios pasan de un paso del funnel a otro.

Personalmente, si la conversión y los resultados del test son muy significativos, me quedaría aquí y empezaría el proyecto para poner el proceso de compra sin autenticación.

Si tienes dudas, como siempre, gracias al ingénio de las y los Product Designers, se puede testear sin la necesidad de código.

Testear con ingenio

Si has llegado hasta aquí es que la cosa va de rock’roll y debemos poner un poco de ingenio y imaginación. Quizás hay otras formas, pero así lo conseguí testear:

Vamos a lanzar un test a/b a todos los usuarios que ya estaban logueados por defecto. Estos usuarios, ni si quieran han pensado si estaban o no logueados. En el paso antes del pago, mostraremos una pantalla muy parecida a la pantalla de login que habíamos propuesto anteriormente.

Pulse donde pulse el usuario irá al paso de compra excepto si pulsa en el botón de “Continuar sin registrarme”. Como ya hicimos, si pulsa en ese botón le mostraremos la modal.

Este test es muy delicado ya que estamos en el último paso del funnel y son muchos los usuarios que pueden caer por mostrar el “fake login”. Por lo tanto, tendremos que ver muy bien lo que pasa con los usuarios.

Con esta forma tan simple, podríamos validar si ese es el punto donde poner la pantalla de autentificación o no.

Eso sí, recordad nuestra hipótesis, queríamos validar si los usuarios compraban más si realizaban la compra sin la necesidad de autentificarse. Esta última validación es para descartar si el punto en el que se lo mostramos es el mejor o no.

Conclusiones finales

Mi colega podrá validar una cosa que puede llegar a ser muy compleja técnicamente a algo más simple. Los datos serán su mejor arma para defender sus diseños.

Como suelo decir muchas veces, el diseño de la opinática no vale de nada, tu opinión puede ser tan válida como la mía.

Gracias a los test con usuarios, encuestas y otras técnicas podremos ver que piensan los usuarios pero no podremos ver que es lo que realmente hacen.

No tengas miedo a los datos, el día que consigas dominarlos tendrás la pócima mágica de todos tus diseños.

Pon imaginación cada vez que quieras validar algo. Recuerda que todo cambio que hagas en el diseño o toda funcionalidad que hagas o midifiques se verás afectada de alguna forma en tus usuarios, en el negocio y posiblemente en la experiencia de usuario.

Como product designers hemos de ponernos en la cabeza que al final, en el centro está el usuario, pero en los extremos todos los stackeholders del proyecto.