Mucha gente escribe artículos en contra del A/B Testing, como un ejemplo de la dictadura del dato. Seamos realistas. Hay más artículos de A/B Testing que empresas haciéndolo.
A/B Testing es una herramienta más. Dependiendo de lo que quieras validar, y tu volumen de uso, será más o menos útil. Si abusas de ella como empresa, efectivamente tus equipos construirán un Frankenstein.
¿Qué recomiendo yo?
Lo principal es:"1) entender bien el problema que quieras resolver"2) tener clara tu hipótesis de porqué esa solución va a funcionar
Para mí, es un error probar soluciones sin hipótesis. Debemos construir una base sólida.
La mejor manera de validar las hipótesis es hacer User Testing con usuarios. Desgraciadamente, también puedo decir que hay más artículos de User Testing que empresas haciéndolo.
Cuando ves como los usuarios usan tu diseño, revisarás tus hipótesis. Con eso, tendrás un nivel de certidumbre. Si tu nivel de certidumbre es alto, posiblemente no haga falta que lances A/B Testing; a menos que lo tengas como una herramienta de phased rollout. Si tu nivel de certidumbre es medio, puedes utilizar el A/B Testing para ganar más confianza antes de decidir el rollout completo.
Para mí, el problema de hacer A/B Tests sin validar las hipótesis con usuarios es que no entendemos porqué ha funcionado o no.
¿Qué hemos aprendido para seguir iterando? ¿Cuál es el aspecto clave que no debemos tocar? ¿Cuál es el siguiente paso en esta dirección?
Si tenemos el problema claro, y buen feedback de usuarios; el A/B Testing nos da más datos para evitar el sesgo de la muestra pequeña de usuarios que hemos elegido. Nos permite aprender antes de afectar negativamente a las métricas de producción.
Nos puede descubrir segmentos de usuarios que se comportan de manera distinta, llevándonos a entender mejor los problemas o el uso que tienen de nuestro producto.
También puede interesarte

40 clics para pagar dos horas de aparcamiento
Un parquímetro me ha recordado por qué contar los clics y los segundos que le cuesta a tu usuario completar una tarea es clave al diseñar un producto.

5 comportamientos que definen a un Product Engineer
La IA hace que programar sea rápido. El reto que queda es entender el problema, plantear una buena arquitectura y fasear con criterio.
