Rediseño de Activación WTFast

Cómo un diseñador se ganó la confianza de un CTO encontrando lo que ingeniería había pasado por alto, y convirtió un adiós de 45 segundos en 4× activación.

1. El producto le mentía a sus propios usuarios

Un usuario nuevo descargaba WTFast, lo abría, y desaparecía en 45 segundos. No molesto. No lo suficientemente confundido como para pedir ayuda. Simplemente se iba, de vuelta al lag del que estaba tratando de escapar.

La activación estaba en 10%. La adquisición funcionaba bien. Partnerships, anuncios, orgánico. La parte de arriba del embudo estaba llena. La parte de abajo era un agujero. Cada dólar gastado en ads compraba un viaje de ida al botón de cerrar.

WTFast es un SaaS para gamers: optimización de red propietaria que baja el ping en League of Legends, Fortnite, Valorant. Los usuarios retenidos lo amaban. Eran power users con opiniones fuertes sobre selección de servidores y ruteo de paquetes. El producto había pasado años haciéndose mejor para servirles: más dashboards, más controles, más perillas. Nada de eso le importaba a la persona que abría la app por primera vez.

La teoría que circulaba en el equipo era que el onboarding necesitaba pulido. Una UI más limpia, quizás una pasada de tooltips. El tipo de arreglo que se puede shipear en un sprint y sentirse productivo.

Yo no creía que fuera un problema de onboarding. Creía que el producto le estaba mintiendo a la gente. Solo que todavía no sabía cómo.

2. Dejé de abrir Figma y empecé a ver gente irse

El trabajo estaba enmarcado como un rediseño del FTUE (la primera experiencia de usuario), anclado a un solo número: la tasa de activación. El porcentaje de nuevos usuarios que efectivamente lograban que el producto hiciera su función principal en su primera sesión.

Acepté el encuadre e ignoré la solución implícita. Antes de dibujar nada, quería saber cómo se veía realmente el “irse”. No en agregado. No en una encuesta. En el momento.

WTFast tenía una herramienta interna de grabación de sesiones en JS, el tipo de artefacto que existe en cada SaaS maduro pero que casi nunca se mira. Me senté con ella y empecé a sacar sesiones fallidas. Después saqué más. Después más. Al final había visto más de 2.000 primeras sesiones terminar en abandono.

No ves a 2.000 personas dejar tu producto sin que algo se mueva. El patrón era tan consistente que daba escalofrío.

1. Instala. El usuario está emocionado. Vino a arreglar un problema real.
2. Primer lanzamiento. La app ofrece modo Automático o Manual.
3. Aproximadamente el 70% pulsa Manual. Quieren control. No confían en un software que nunca usaron para que elija por ellos. Justo.
4. Manual revela 200+ servidores en un dropdown plano. Dallas 1, Dallas 2, Dallas 3, Los Angeles 5, Singapore 12. Sin contexto. Sin “el mejor para tu juego”. Solo un muro.
5. Bloqueo. Cuarenta y cinco segundos. Cerrar.

La narrativa interna era “a los power users les encanta el control manual, así que hay que mantenerlo prominente”. El comportamiento decía algo más frío: los nuevos usuarios querían control porque no confiaban en el producto, y el producto los castigaba por eso.

Eso solo ya alcanzaba para rediseñar alrededor. Pero no fue lo peor que encontré.

3. La cosa que la empresa no sabía que estaba haciendo

Mientras veía sesiones, empecé a marcar otra categoría: gente que sí confiaba en el modo automático. Lo elegían. Esperaban. Y los enrutaba a algún lugar equivocado.

Un usuario en Nueva York conectando a Singapur. Un europeo ruteado por Brasil. Reducciones de ping que funcionaban en una sesión y empeoraban en la siguiente. Dentro de un porcentaje no trivial de esas sesiones, el producto estaba activamente haciendo el juego del usuario peor de lo que era antes de instalarlo.

Lo llevé a ingeniería. No como acusación. Como pregunta. ¿Por qué el modo automático está eligiendo servidores raros?

Lo que descubrimos juntos es la parte de esta historia a la que sigo volviendo.

WTFast medía la calidad de servidor corriendo un test de ping desde la máquina del usuario hacia afuera: rápido, paralelo, agresivo. Diseñado para velocidad. El problema es que el test era tan agresivo que los ISPs lo clasificaban como tráfico sospechoso. Algunos lo throttleaban. Otros directamente lo bloqueaban. Los datos que volvían no eran una medición real de la calidad de la red. Eran una medición de cuánto cada ISP estaba ahogando al test mismo.

Después el algoritmo tomaba esos datos contaminados y recomendaba con confianza el “mejor” servidor. Que, para una porción nada trivial de usuarios, era el servidor equivocado.

El producto no era malo eligiendo. Lo estaban engañando las redes que intentaba medir, y le pasaba esa mentira al usuario como una recomendación segura.

Alex Needham, el CTO, se acercó directo después de que lo rastreamos. No un mensaje de Slack. No un “gracias por flaggearlo”. Me dijo, sin vueltas, que el diseño no era el problema. Yo había encontrado el problema.

Ese fue el momento en que el proyecto cambió. No porque el bug se haya arreglado. Los bugs se arreglan todos los días. Porque por primera vez en mi carrera un ingeniero senior trataba a un diseñador como alguien que podía ver el producto, no solo decorarlo. Cada founder secretamente quiere a ese diseñador. La mayoría nunca trabajó con uno.

Después de esa conversación, tenía el espacio. Lo que propusiera a continuación, ingeniería lo iba a construir conmigo, no a mi alrededor.

4. Diseño, después de que el producto dejó de mentir

El arreglo tenía dos capas, y el orden importa. Ingeniería tenía que ir primero.

La base: hacer que el producto fuera honesto otra vez

Ingeniería ajustó el test de ping. Menos agresivo. Más lento. Lo suficientemente parecido al tráfico común como para que los ISPs dejaran de marcarlo. Los datos de latencia empezaron a reflejar la realidad. El algoritmo empezó a recomendar los servidores correctos.

Nada de lo que vino después habría funcionado sin esto. Un onboarding pulido envuelto alrededor de un motor de ruteo roto es una forma más rápida de perder usuarios. Llegan al “momento de valor” y el valor no está. Diseñar después de que el producto es honesto es un ejercicio distinto a diseñar como tapadera.

Los primeros 30 segundos: convertir la espera en una sensación de poder

El nuevo test de ping tomaba unos segundos. En la versión vieja, esa espera era aire muerto incómodo, el tipo de pausa donde el usuario cambia de pestaña y nunca vuelve.

Diseñé una pantalla de carga para ese intervalo que tenía un solo trabajo: comunicar que algo sofisticado estaba pasando para ellos. “Analizando red global. Detectando ruta óptima. Calculando el mejor servidor para tu juego”. No decoración. Narración. La misma cantidad de segundos, encuadrada como el producto trabajando duro a favor del usuario en lugar del producto haciéndolos esperar.

Este es el movimiento al que vuelvo siempre en producto. Un momento neutro es una fuga. Un momento narrado es una promesa.

El flujo: cinco pasos, tres de ellos sobre jugar

En lugar de tirar al usuario dentro de 200 servidores, construí un flujo lineal de cinco pasos. Los primeros dos eran sobre quién era el usuario. Los últimos tres eran sobre meterlo al juego.

Paso 1. Avatar. Elegí tu cara. Una cosa pequeña, excepto que no lo es. Para cuando el usuario eligió un avatar, dejó de pensar en la app como software y empezó a pensarla como suya. Dos segundos. Identidad gratis.

Paso 2. Los juegos que sí juegas. Una encuesta corta: ¿en cuáles títulos te logueas? League, Valorant, Apex, el resto. Esto era andamio para el Paso 4, pero más importante: hacía que el usuario revelara algo. La revelación es inversión. La inversión es retención.

Paso 3. Región. No “elegí un servidor”. Elegí tu país, y el país donde están los servidores del juego. Los gamers saben esto. Llevan años leyendo etiquetas de región en los launchers.

Paso 4. Detección de juego. La app escanea los juegos que el usuario acaba de decirnos que juega y se los muestra. Ven su biblioteca real de vuelta, no una lista de strings. La “magia” es solo el producto demostrando que se acordó de con quién estaba hablando dos pantallas atrás.

Paso 5. Un botón. “Lanzar Juego”. Eso. Sin toggles avanzados, sin CTAs secundarios, sin “¿estás seguro?”. El usuario hace un clic, la optimización está activa, el juego se lanza con un ping medible más bajo.

El flujo entero corre en menos de 30 segundos. Los controles avanzados no desaparecieron. Se movieron a un lugar donde el usuario podía encontrarlos después de haber sentido al producto funcionar una vez. Que es el único punto en el que los controles avanzados realmente significan algo.

5. Lo que cambió, y para qué eran realmente recibos los números

Lo lanzamos como un A/B test. No tuvimos que esperar mucho.

• La activación pasó de 10% a 50%. Cinco veces la cantidad de nuevos usuarios efectivamente experimentando aquello a lo que vinieron, en su primera sesión.
• La conversión de prueba a pago se triplicó. Los usuarios que sintieron al producto funcionar fueron mucho más propensos a poner una tarjeta.
• Las unit economics se movieron. El mismo gasto de adquisición ahora compraba usuarios que sí pagaban. El ROI por nuevo usuario aproximadamente se triplicó, sobre el mismo embudo y los mismos dólares.

Esos son números reales y sostuvieron el caso de negocio. Pero no son lo que pienso cuando pienso en WTFast.

Lo que pienso es la frase de Alex. El CTO de la empresa, la persona cuyo código yo había estado picoteando en silencio, diciéndome que el diseño no era el problema. Yo había encontrado el problema. Esa es la frase que cada founder está esperando que un diseñador se gane el derecho a escuchar. La mayoría de los diseñadores nunca llega ahí porque nunca mira más allá de la pantalla.

El 4× de activación está río abajo de ese momento. Una vez que el producto dejó de mentir, el diseño solo tuvo que amplificar lo que ya era cierto. La pantalla de carga, el flujo de cinco pasos, el botón “Lanzar Juego”. Nada de eso es ingenioso por separado. Lo que lo hizo funcionar es que era la primera versión honesta de WTFast que un usuario nuevo había visto.

6. Lo que querría que un founder se lleve de esto

Si solo contratas diseñadores que pulen lo que ya construiste, vas a tener una versión más linda de tu techo actual. Los diseñadores que valen lo que cobran son los que van a seguir a un usuario confundido a través de la costura entre UX e ingeniería y te van a decir qué está realmente roto. A veces es la interfaz. A veces es el producto. Muchas veces, cuando miras de cerca, es el producto usando la interfaz como máscara.

El mecanismo no es glamoroso. Ver sesiones reales hasta que aparezca un patrón. Hacerle preguntas a ingeniería hasta que algo no cuadre. Cuando la respuesta es “eso no debería estar pasando”, seguir tirando. El bug que encuentres del otro lado normalmente vale más que cualquier rediseño por sí solo.

El diseño no arregló WTFast. El diagnóstico sí. El diseño hizo que el producto, ahora honesto, se sintiera inevitable. Que para un usuario por primera vez es el único tipo de “funcionar” que cuenta. Si tu curva de activación se parece a la nuestra, la respuesta probablemente no es un onboarding más limpio. Está en algún lugar más abajo, donde nadie miró todavía, esperando a alguien dispuesto a hacer la segunda pregunta.