😎 ¡Happy #FridayHacks!

Una parte muy importante del growth hacking es el testing recurrente. Ya hemos hablado varias veces sobre el ICE Score (para ordenar los experimentos), de lo importante que es tener siempre un experimento corriendo, y tal.

Otro dato súper importante es tener en cuenta que cuando hacemos testing hay que cambiar sólo una variable para tener controlado qué es lo que sucede exactamente y dónde para poder reaccionar (test A/B de toda la vida de dios).

PERO

😳 ¿Qué pasaría si estuviéramos haciendo testing en una web que realmente no gusta a los usuarios?

Puede que no sea el color del botón, ni la tipografía, ni las fotos ni ná. Puede que sea justamente todo.

Podemos tardar mucho tiempo en darnos cuenta de algo así 🤷🏻‍♂️

Por eso, de vez en cuando, puede ser interesante hacer un testing agresivo. Hacer un testeo ofreciendo una versión que no tenga NADA que ver.

Cosas que podemos hacer de testing agresivo:

📍 Destruir la web y hacer una versión extremadamente minimalista
📍 Diseño desde 0 a nivel de estructura, copys, colores, botones.
📍 Cambiar todas las fotos y colores

💁🏻‍♂️ Hay veces que este tipo de cambio nos quita una venda de los ojos y de repente la web empieza a funcionar. Algo que quizá hubiéramos descubierto con mooooogoooolloooon de testing recurrente, o no.

Este tipo de acciones son muy agresivas y realmente hay que vigilar cuando las aplicamos. Yo creo que un buen ejemplo de cuando implementarlas en cuando te encuentras en un bloqueo de una página que literalmente no convierte.

También hay que tener en cuenta que un testeo así de agresivo tiene que mostrarse a una muestra controlada y además estar encima todo o casi todo el tiempo. Como la cosa se tuerza la podemos liar parda… pero como salga bien nos podemos coronar en plan “Mr/Mrs Disrupción 2020” 💃🏻