Cómo evolucionó nuestro diseño de mensajes programados en WhatsApp

Cómo evolucionó nuestro diseño de mensajes programados

¿Qué pasa cuando un desarrollador intenta hacerle "RCP" (reanimación cardiopulmonar) a una función muerta mientras aprende diseño de nuestro cofundador?

¡Te cuento! :)

No soy diseñador. Soy un desarrollador que, de alguna forma, terminó diseñando funciones mientras las programaba. Esta es la historia de cómo llevé nuestra función de mensajes programados de un experimento fallido a algo de lo que estamos orgullosos y que la gente usa de verdad.

El cementerio de funciones

Cuando heredé los mensajes programados, ya estaban muertos. Mis compañeros habían probado algunas versiones:

Haces clic en un botón al lado de enviar. Eliges una fecha. Mensaje programado. ¿Quieres otro? Clic otra vez. Eliges la fecha otra vez.

Cada. Una. De. Las. Veces.

Después alguien agregó un modal que bloqueaba toda la pantalla de noche: "¡Oye! ¡Es tarde! ¿Quieres programar esto para mañana?"

A los usuarios no les gustó nada. El equipo lo eliminó. Terminó en nuestro cementerio de funciones.

Luego llegó la tarea de RCP: "Revive los mensajes programados. Haz que no sean un desastre."

Versión 1: mi primer intento de resurrección

Empezar una RCP es raro. Sabes que la función fracasó, pero no quieres solo maquillar el cadáver. Tienes que reimaginarla por completo.

Creé el "Modo Enviar más tarde": una barra naranja arriba que te ponía en modo programación. Lo activabas y todos tus mensajes quedaban programados. Pensé que lo había resuelto.

El feedback de Mati llegó en 30 segundos:

"cuando abro el chat, la animación de la barra superior se repite. igual no me gusta la animación. los estilos no son consistentes. los bordes son distintos y el color se siente raro. rompe los atajos. podemos hacerlo mejor."

"Podemos hacerlo mejor." La frase que iba a definir las siguientes semanas de mi vida.

El proceso de RCP: morir y renacer, una y otra vez

Hacer RCP no es solo arreglar lo que está roto. Es entender por qué murió y reimaginarlo por completo. Y muchas veces necesitas fallar unas cuantas veces más para entender cómo se ve el éxito.

Versiones 2 y 3: atendí el feedback de Mati. Arreglé los colores, moví cosas, agregué badges.

Mati: "no me gusta el estilo de la barra superior. podemos hacerlo mejor."

La función ya era mejor que lo que habían probado mis compañeros. Pero "mejor que muerta" no es la vara que buscamos.

Versión 4: me pasé de la raya. Tooltips, badges, contadores, manejo de estado complejo. 500 líneas de código. "Si quieres algo mejor, te doy todo", pensé.

Mati: "saca los efectos. no es intuitivo cómo volver. no deberíamos llevar el foco a todo el cuadro de redacción."

Estaba eliminando mis soluciones ingeniosas una por una.

Versión 5: frustrado, sugerí: "¿Y si simplemente ponemos azul el cuadro de redacción cuando está en modo programado?"

Mati: "Mejor."

Una palabra. Después de semanas de "podemos hacerlo mejor".

Qué significa realmente hacer RCP

Después de varias RCP, aprendí que no se trata de arreglar funciones. Se trata de entender por qué fallaron y tener el valor de probar algo completamente distinto.

La primera versión falló porque agregaba fricción. Clic en el botón, elegir fecha, repetir. Mis primeras versiones fallaron porque agregaba complejidad en lugar de quitar fricción.

El gran avance de la v5 no fue agregar algo nuevo. Fue darnos cuenta de que el cuadro de redacción ya estaba ahí. Solo había que cambiar su estado, no construir alrededor de él.

Versión 6: la verdadera resurrección

La versión final era tan simple que daba vergüenza:

• El cuadro de redacción se pone azul en modo programado
• Un texto limpio que muestra la hora programada
• Un badge pequeño para los mensajes pendientes
• 100 líneas de código, no 500

Mati: "Bien. Publícalo."

La función que había muerto en manos de mis compañeros, y que yo había complicado de más durante 4 versiones, por fin estaba viva. Y se sentía como si siempre hubiera sido parte de WhatsApp.

Lo que aprendí sobre la RCP (y el diseño)

La verdad sobre la RCP: no se trata de quién tiene razón. Se trata de tener las agallas de seguir empujando cuando cualquier otro habría publicado la v2.

No nos equivocamos con los primeros intentos: estábamos explorando. Cada versión "fallida" fue un paso necesario. ¿El modal que bloqueaba la pantalla? Tenía que existir para que viéramos lo molestas que son las interrupciones. ¿Mi barra naranja? Tenía que existir para que entendiéramos que distinto no siempre es mejor.

"Podemos hacerlo mejor" no es una crítica. Es un estándar compartido.

Cuando Mati lo dice, no está diciendo "fallaste". Está diciendo "todavía no lo encontramos". Esa palabrita, "podemos", lo cambia todo. No es su visión ni mi código. Es nuestro compromiso de seguir empujando hasta que se sienta bien.

Lo que esta RCP nos enseñó como equipo:

• La versión 1 nunca es la respuesta, es la pregunta
• Las soluciones simples se esconden detrás de intentos complejos
• Si necesita instrucciones, no terminamos
• Las mejores funciones se sienten como si siempre hubieran estado ahí
• "Suficientemente bueno" es enemigo de "wow, esto es perfecto"

La magia no está en el feedback de Mati ni en nuestro proceso creativo. Está en negarse a conformarse. Cualquier equipo puede publicar la v2 y seguir adelante. Hace falta una terquedad especial para llegar a la v6 y seguir creyendo que hay una solución más simple escondida ahí.

La RCP no se trata de resucitar. Se trata de evolucionar.

No solo traemos de vuelta funciones muertas. Estamos afinando nuestra idea de qué hace que algo valga la pena publicar. Cada iteración, cada "podemos hacerlo mejor", cada versión descartada: todo es parte de encontrar esa solución inevitable.

Nuestra filosofía de RCP hoy

Cuando le hacemos RCP a una función:

1. Estudiamos por qué murió (normalmente: demasiado compleja)
2. Probamos algo completamente distinto (normalmente: todavía demasiado complejo)
3. Escuchamos "podemos hacerlo mejor" (siempre)
4. Quitamos todo (duele, pero es necesario)
5. Encontramos la solución simple que estaba escondida (siempre está ahí)
6. Publicamos cuando se siente inevitable (no cuando impresiona)

Ahora mismo estoy haciendo otra RCP. Versión 4. Mati acaba de decir "podemos hacerlo mejor".

Sé lo que viene. Las versiones 5 y 6 van a doler. Pero en algún lugar de ese dolor vamos a encontrar la solución simple que le devuelva la vida a esta función.

Los números que importan

Antes de la RCP: 0% de los usuarios usaba mensajes programados. Función muerta. Abandono total.

Después de 6 versiones de "podemos hacerlo mejor": más del 20% de los usuarios la usa activamente semana a semana.

De eso se trata realmente la RCP. No solo de revivir funciones, sino de hacerlas tan intuitivas que la gente quiera usarlas. La diferencia entre 0% y 20% no son solo iteraciones de diseño: es la diferencia entre una función que te hace pensar y una que simplemente funciona.

Al final, "podemos hacerlo mejor" valió el dolor.

P.D.

Para mis compañeros cuyas versiones "fallaron" antes