El Viaje de Rebranding de una App de Más de 7 Años

Hola a todos. Estoy aquí hoy para guiarlos a través del viaje de rebranding de una aplicación de siete años. Pero antes de llevarlos en este emocionante viaje, permítanme presentarme. Soy Kasia Trzemska, soy líder técnica del sistema de diseño para Clio, una empresa con sede en el Reino Unido.

Sí, suficiente sobre eso. Así que comencemos el viaje. Y antes de hablar sobre el rebranding en sí, vale la pena echar un vistazo a Clio como aplicación y la etapa en la que se encontraba cuando comenzamos a pensar en el rebranding. Así que estamos hablando de una aplicación bastante antigua, una base de código bastante antigua, siete años es una eternidad si piensas en la comunidad de React y React Native, porque esto es con lo que Clio fue escrito. Pero hablemos de eso en un segundo.

También estamos hablando de un montón de pantallas diferentes servidas para nuestros usuarios con un montón de contenido y características diferentes dentro de estas pantallas. Cuando se trata de la arquitectura de Clio, en algún momento migramos exitosamente la aplicación a Expo, lo cual es bastante emocionante y ya facilita muchas cosas. Como ya se mencionó, la mayor parte de la aplicación está escrita con React Native, pero principalmente debido al ritmo rápido al que se mueve Clio, también servimos parte del contenido a través de React.

Sí, React en vistas web. Y esto, la parte divertida está realmente llegando, aún llegando. Así que la aplicación React se sirve como una vista del MVC de Ruby on Rails. Así que sí, tenemos una pila bastante interesante. Hay un montón de texto diferente y muchos idiomas diferentes involucrados, pero funcionó. Ha funcionado hasta ahora. Fue bastante bueno.

Y he mencionado el ritmo rápido, y realmente lo digo. Clio se mueve súper, súper rápido. Estamos probando A-B un montón de cosas. Así que si piensas en lo que podríamos potencialmente probar A-B, probamos A-B cosas como cambios en el flujo de registro, por ejemplo, para entender el impacto de quitar algunas de las pantallas o tal vez cambiar el flujo a un estilo más lineal, o tal vez simplemente mantenerlo todo muy simple en un formulario.

Pero también probamos A-B cosas como cambiar el contenido del CDA en algún lugar para entender, nuevamente, qué diferencia hace para nuestros usuarios. Pero esto nos lleva a algunos de los desafíos que este enfoque trae. Así que cada vez que piensas en probar características, necesitas obviamente traer algunos lados diferentes de la prueba. Uno de los lados está ganando. Y además de eso, estamos probando otra característica.

Y luego otro lado está ganando. Así que basado en estos tres, estamos probando otra característica. En realidad, nos plantea una pregunta, ¿qué pasa con estos lados perdedores de las pruebas dadas? Y dirías, sí, básicamente deberías limpiar eso lo antes posible. Y lo hicimos en la mayoría de los casos. Pero a veces, debido a las retenciones, por lo que la necesidad de mantener algunas pruebas ejecutándose por un período de tiempo más largo, lamentablemente tuvimos que dejar algunos de estos lados muertos de las pruebas, y nuestra base de código estaba creciendo y creciendo debido a eso.

Algunas de las características todavía están en vistas web, lo cual tampoco era perfecto. Así que nuevamente, ritmo rápido, a veces realmente necesitamos probar algo muy rápidamente. Y no sé si has estado construyendo cosas con React Native. Pero si lo has hecho, sabes que a veces lleva un poco más de tiempo construir un flujo completo, una característica completa dentro de un React Native comparado con React. Así que cuando queríamos probar algo muy rápidamente, generalmente lo probábamos dentro de la vista web. También creemos que si la característica está funcionando, si nuestros usuarios están contentos con la característica, y no hay otra razón que veamos para migrarla a React Native, mantendremos las cosas como están porque preferimos gastar este tiempo en invertir en la experiencia del usuario y construir otras características y mejorar otras características que realmente necesitan nuestra atención.

Pero cuando echamos un vistazo a algunas de las partes de la aplicación, y especialmente pensando en la próxima rebranding, hemos notado que hay algunas diferencias en cómo se ven las cosas, especialmente en la vista web. Así que aquí puedes ver tres pantallas de ejemplo de características servidas en una vista web, y puedes ver que hay algunas diferencias en cómo mostramos iconos, cómo mostramos títulos y encabezados y CTAs. Incluso dirías tal vez no que no es como la misma aplicación, pero se ve diferente. ¿Qué pasa con el sistema de diseño? Así que en esta etapa de cuando estoy hablando de cuando comenzamos a pensar en el rebranding, el sistema de diseño era principalmente una biblioteca de componentes, y luchamos. Luchamos con un par de cosas diferentes.

Así que luchamos con tokens distribuidos entre web y Native como ya se estableció. Teníamos algunas características siendo servidas en la web, por lo que una aplicación completamente diferente, y realmente no teníamos componentes universales o tokens compartidos entre dos aplicaciones diferentes. Los componentes flexibles eran una cosa diferente con la que luchamos. Así que a lo largo de los años, logramos crear una biblioteca realmente buena, pero también tuvimos algunos requisitos muy cambiantes cuando se trata de nuestros componentes y cómo queremos que la aplicación se vea. Y debido a eso, comenzamos a aceptar la prop de estilo, por ejemplo, lo que hizo que nuestros componentes parecieran pequeños monstruos a veces. También logramos encontrarnos en una situación donde, en algún momento, teníamos tres paletas de colores diferentes viviendo en la aplicación y siendo usadas al mismo tiempo, lo cual fue bastante interesante.

También creo que aún vale la pena mencionar que nos encontramos en una situación donde servimos tipografía en un par de estilos diferentes y a través de un par de componentes diferentes. Así que, sí. Luchamos un poco. Y si miras las pantallas de la aplicación, puedes notar que este estilo es un poco diferente. Depende de dónde mires. Bien, pero sigamos adelante. Así que punto de partida. Te di un pequeño resumen de cómo se veía Clio en aquellos días, pero cómo realmente comenzamos a pensar en el rebranding, sobre lo que necesitamos hacer. Así que entender el desorden fue, creo, el mayor punto de planificar el rebranding, planificar cómo podemos llegar allí y cómo llegaremos allí. Y cómo podemos entender el desorden. Así que a través del sistema de diseño, obviamente. Y mi comprensión del desorden fue recopilar los datos, entender dónde estamos y cómo podemos realmente mejorar la situación. Así que introduje un script usando React scanner para rastrear la base de código, que se ejecutaba a través de GitHub Actions todos los días y enviaba los datos a Redshift, que podíamos contar y verificar y consultar a través del conteo. Y los datos de los que hablo eran principalmente el uso de tokens y componentes.

Así que tenía que entender, teníamos que entender dónde estamos. Y estábamos alrededor del 50% de componentes, componentes compartidos para la adopción. No está mal, no está bien, en algún lugar. Estábamos en algún lugar. Pero también ten en cuenta que la mayoría de estos componentes eran muy, muy flexibles, lo que realmente nos lleva al segundo punto. Así que luchamos con miles de valores mágicos aleatorios. Estoy hablando aquí de simplemente usar 15 como tamaño de fuente en algún lugar, o tal vez 17 en otro lugar. O tal vez simplemente establecer un espaciado como 11, porque simplemente coincide con el diseño en aquel entonces. Y otros valores definidos simplemente no estaban allí todavía. Muchas pantallas no utilizadas fueron otro gran hallazgo nuestro.

Debido a las pruebas A, B y a que no siempre se realizaban limpiezas adecuadas, teníamos algo de código muerto viviendo en la base de código, lo cual, ya sabes, sería bueno deshacerse de él en algún momento. Y eso nos lleva a la rehabilitación. Así que el gran plan era llevar la aplicación al estado donde el rebranding ya no sea un gran problema. Y como ya mencioné, tuvimos que hacer muchas limpiezas, muchos tipos diferentes de limpiezas. Tuvimos que reducir el número de conjuntos de tokens de tres a uno. De alguna manera, ¿verdad? Creo que vale la pena. Porque, como sabes, en ingeniería usualmente parece que, sí, tenemos tres conjuntos diferentes de tokens. Introduzcamos uno nuevo y bueno. Y ahora tenemos cuatro conjuntos diferentes de tokens. Esto es usualmente cómo se ve. Así que es bueno a veces simplemente hacer la limpieza adecuada y organizar este caos antes de avanzar. Estandarizamos color, espaciado, la tipografía, pero también cosas como borde, radios de borde y otras cosas, también sombras. Como todos los diferentes tipos de tokens de estilo, que pueden venir a tu mente, los organizamos en conjuntos definidos de tokens. También creamos un grupo de acción enfocado en limpiar vistas web.

Así que aquí un poco de contexto. Nosotros, en la etapa de, ya sabes, planificar el rebranding, había un par de soluciones diferentes para lo que queríamos hacer con las vistas web. Una de ellas siendo, por ejemplo, introducir una biblioteca de componentes universales y migrar todo para usar estos componentes. Lo mismo con los tokens. Tal vez solo rebrandear la vista web, perdón, la aplicación web y la aplicación React Native al mismo tiempo. Pero volvimos a mirar los datos nuevamente y cuántas de estas vistas web tenemos. Cuánto esfuerzo sería limpiar las vistas web, básicamente migrar las más usadas a React Native, porque tanto rebrandear la web como rebrandear e introducir la biblioteca de componentes universales y luego migrar las más de mil pantallas de la aplicación Native era una gran inversión. Así que en ese momento, la mejor solución en cuanto a esfuerzo versus impacto fue limpiar las vistas web, limpiar el desorden, migrar todo a Native, y esto es lo que hemos hecho.

La gran parte de preparar la base de código para el rebranding fue la comunicación del sistema de diseño. Realmente hemos hecho mucho trabajo en torno a la comunicación, transparencia, introduciendo algunos procesos, teniendo algunos procesos en su lugar, porque eso era súper importante para establecer buenos patrones de uso del sistema de diseño en el día a día, porque nuestra base de código crecía cada día. Y obviamente, hemos hecho toda esta limpieza, pero también tuvimos que pensar en el futuro, pensar en lo que sucede en una semana si no establecemos algunos buenos procesos. Primero, celebramos todas nuestras escuadras adoptando el sistema de diseño, y realmente lo hicimos muy público. Fuimos a todas las manos con algunos tableros de líderes, porque teníamos los datos de adopción del sistema de diseño, también teníamos datos sobre qué dominio es propiedad de qué escuadra, y a través de la documentación de propiedad de código en GitHub, también sabíamos cuál de las escuadras posee cuál de los dominios. Así que pudimos construir tableros de líderes para qué escuadra lo está haciendo mejor y qué escuadra tal vez no lo está haciendo tan bien. Pero nos enfocamos en celebrar las escuadras que lo están haciendo muy bien. También promovimos la adopción del sistema de diseño a través de OKRs a nivel de escuadra.

Establecer OKRs cada término es algo muy importante en Clio. Creemos que queremos tener un objetivo común, objetivo de negocio, objetivo de la empresa, hacia el cual cada escuadra trabaja cada término. Y en algún momento, logramos convencer a nuestro liderazgo para que la adopción del sistema de diseño fuera un OKR de calidad para cada escuadra. Eso fue un gran, gran logro y realmente mejoró la adopción del sistema de diseño en toda la empresa.

También hemos abordado todos estos valores aleatorios dispersos por toda la base de código. Y me preguntas, ¿cómo? ¿Cómo? No por qué. Cómo hemos hecho esto. Y diré automatización. La automatización fue el rescate y realmente automatizamos todo lo que pudimos, lo siento, todo lo que pudimos. Automatizamos, quiero decir, no todo. Todavía había mucho trabajo manual, lamentablemente.

Pero, por ejemplo, la unificación de la tipografía, realmente logramos escalar el trabajo a través de la automatización. Logramos que esto funcionara a través del modo de código. Como mencioné, usamos un par de componentes diferentes. Por ejemplo, texto con algún valor mágico obviamente aleatorio, tamaño 15. Y componente de texto, teníamos nuestra propia implementación de componente de texto. Pero en algunos lugares, también usamos el componente de texto que viene directamente de React Native. React Native viene con estos componentes útiles. Y lo usamos a veces.

Así que, decidimos introducir además de esto, introducir el componente de tipografía con una forma más establecida de cómo queremos presentar texto en nuestra app. Así que, creamos, ya sabes, un conjunto de tamaños, un conjunto de tipos para la tipografía, y luego mapeamos todos los diferentes tamaños a lo largo de la app en diferentes, en algún tipo de tipografía y algún tamaño de tipografía. Y luego ejecutamos el modo de código para hacer el mapeo. Fue súper, súper útil, súper rápido y eficiente. Y el único trabajo que nos quedaba aquí era ejecutar tareas de extremo a extremo para asegurarnos de que nada se rompiera en el camino.

Pero eso fue una migración muy exitosa y nos ahorró un montón de horas o días de trabajo. Otra cosa, creo, muy digna de mencionar que hemos hecho, que hemos usado y automatizado, fue usar reglas de linting, un montón de reglas de linting. Usamos linter y algunas reglas personalizadas para, ya sabes, mantener las cosas limpias, básicamente. Así que, cada vez que, por ejemplo, desaprobamos un componente, introdujimos una regla de linter para prohibir el uso del componente desaprobado. Hicimos lo mismo con valores mágicos. Hicimos lo mismo con, en general, no usar tokens.

Así que intentamos no ser demasiado estrictos y molestos con estas reglas de linter, sino encontrar el punto dulce perfecto de introducirlas y hacerlas útiles para los ingenieros en lugar de molestas. Bien. Pero finalmente, hablemos un poco más sobre el rebranding y la visión se encuentra con la realidad. Así que, aquí puedes ver finalmente una pantalla de la versión renovada de la app. Súper dulce, si me preguntas. Realmente me gusta el nuevo diseño. Comparando con el muy colorido de la versión anterior. Pero, sí, hablemos de enfrentar la realidad. Así que, recuerdas que mencioné sobre las más de mil pantallas de Clio.

Y, sí, el primer punto del plan era adoptar el sistema de diseño. Así que, ya sabes, si estaremos en la etapa de, bien, ahí tenemos el 80% de adopción del sistema de diseño, si vamos a renovar todos los componentes, todos los componentes, todo debería encajar. Pero también, no fue tan simple. Aún tenías que revisar cada pantalla para asegurarte de que todo funcionara y el diseño fuera correcto. Y también, a través del rebranding, algunas de las pantallas cambiaron el diseño. Así que, tuvimos que hacer un poco más de trabajo. Pero mil pantallas son muchas. Incluso para una empresa tan grande, digamos, como Clio, así que, tuvimos que ser un poco más inteligentes sobre lo que queríamos hacer. Y el plan era enfocarse en las pantallas con mayor volumen de tráfico.

Así que, gestionamos, tenemos un montón de datos en general. En Clio, realmente confiamos en los datos. Y medimos mucho. Y gracias a eso, pudimos entender fácilmente cuáles de las pantallas son visitadas más por nuestros usuarios, cuáles de las pantallas son las más importantes para nuestros usuarios. Y enfocamos nuestros esfuerzos en estas pantallas. Así que, nos enfocamos primero en las 200 con mayor volumen de tráfico. Realmente estamos hablando de, ya sabes, el 80% de todo el tráfico siendo dirigido a estas pantallas, comparado con el 20% del tráfico yendo a otro lugar. Así que, realmente tenía sentido en ese momento hacer eso. Obviamente, pasamos tiempo en renovar el resto de las pantallas en la otra, la segunda etapa del rebranding.

Pero allí, principalmente nos enfocamos en adoptar el sistema de diseño, simplemente usando los componentes correctos, asegurándonos de que todo se vea bien. Pero cuando se trata de la otra pantalla, las pantallas más importantes, como las que están aquí, como puedes ver, el rebranding fue más que solo usar un componente en lugar de otro. A veces fue introducir una pantalla completamente nueva. También, sí, porque estamos haciendo pruebas A-B de todo en Clio, decidimos que queríamos probar la experiencia de rebranding con A-B. Esta es una gran prueba A-B, si me preguntas. Básicamente decidimos probar dos experiencias completamente diferentes dentro de una app.

Y lo hicimos realidad. Y hubo algunos de los efectos secundarios de este enfoque. Uno de los mayores efectos secundarios fue que habilitamos a los equipos de producto para trabajar en el rebranding dentro de sus dominios sin, ya sabes, preocuparse de que romperían algunas otras experiencias que podrían, gracias a las pruebas A-B, simplemente rebrandear algunas de las pantallas en las que han estado trabajando detrás de una bandera, y luego tenían una manera fácil de simplemente cambiar entre dos versiones, gracias a qué? Gracias a Teams. Esa fue nuestra solución para simplemente traer una nueva marca sobre las existentes, existente.

Y cómo hicimos esto, cómo hicimos esto realidad. Entonces, quiero decir, realmente no fue una solución compleja. Usamos un patrón muy conocido de proveedores en React. Y creamos nuestro propio proveedor de equipo, que bajo el capó usaba un hook bastante simple. Puedes ver el hook global de rebranding, que estaba devolviendo información tipo verdadero falso. Y luego, basado en eso, usamos un tema y devolvimos el tema en el valor de un proveedor. Y luego cada componente, de hecho, hablaremos de esto en un segundo.

El hook en sí es, la versión aquí está un poco simplificada, pero en general, hicimos una consulta para obtener información de un backend si el usuario dado debería ver el lado A o B del rebranding. Y basado en eso, devolvimos el resultado de nuevo al proveedor. También, en algún momento, introdujimos un interruptor local para el rebranding para facilitar a nuestros ingenieros y también a nuestros usuarios internos cambiar entre dos marcas. Entonces, el interruptor local estaba funcionando sobre la prueba A, B. Así que, hay un poco de lógica de echar un vistazo a si, esta fue nuestra operación realizada sobre si deberíamos tomar el acceso de rebranding en caché, lo cual no era cierto antes. Era más complejo. Y luego, también, echar un vistazo a la anulación del tema y simplemente cambiar basado en el valor inicial y el interruptor en la app local. Así que, así fue como se manejó dentro de la app.

Y cuando se trata de componentes del sistema de diseño, todos estos componentes del sistema de diseño dentro del proveedor, ¿verdad?, se referían a usar el tema global, un hook, que estaba usando el tema del contexto y tomaba los tokens directamente de allí y los usaba. Tan simple como eso. Pero ese era el tema.

Así que, nos permitió cambiar entre dos marcas diferentes. También gestionamos todo el rebranding a través de Rebrand Champions en toda la organización. Encontramos personas de cada equipo responsables de informar sobre el proceso de rebranding. Y también, gracias a eso, mantuvimos la transparencia y la comunicación a un nivel muy alto.

Era súper importante mantener la comunicación limpia y clara, para que todos estén al tanto de lo que está sucediendo y lo que viene. También creamos un espacio especial para compartir el estado de las pantallas de rebranding. Lo llamamos Screen Atlas. Y dentro de nuestras herramientas internas, teníamos un espacio donde subíamos todas las capturas de pantalla de, ya sabes, la marca antigua y la versión rebrandeada.

Además, tomamos estos datos en cuenta, para que pudiéramos consultarlos y entendimos dónde estamos cuando se trata de rebranding. Lanzamos toda la versión rebrandeada de la aplicación como una prueba A-B al final del trabajo para entender el impacto, para, ya sabes, tener un cambio rápido si algo malo sucediera, si introdujéramos un error en algún lugar del camino. Pero también, si todas nuestras métricas se desplomaran, probablemente tal vez potencialmente también, ya sabes, simplemente apagaríamos la prueba A-B y pensaríamos en qué podemos cambiar dentro de la nueva marca, qué podríamos tal vez ajustar para no hundir las métricas tan mal. Pero todo salió bien, así que no necesitamos eso. Bien. Así es como fue.

Pero hablemos un poco sobre las lecciones aprendidas. Creo que he mencionado la mayoría de las lecciones aprendidas a lo largo de la charla, pero déjame repetirme de nuevo. La transparencia es clave. Realmente necesitamos ser transparentes con todos los pasos que estás tomando, con todos los planes que estás haciendo. Es bueno tenerlos escritos y compartidos en toda la organización. También encontré que la comunicación es realmente clave. Realmente, puedes repetirte. Puedes, te parecerá a ti mismo cuando te mires en el espejo que eres tan aburrido. Estás diciendo las mismas cosas una y otra vez, pero así es como llegas a la gente.

Así es como haces que algo sea una prioridad, y encontré que esto es súper importante. Cuando quieres hacer un éxito de un proyecto tan grande como este, divide y vencerás. Eso fue una gran, gran cosa para mí. Si piensas en la etapa en la que Clio estaba al principio, cuando comenzamos a pensar en el rebranding y a dónde hemos llegado, no ha sucedido en un fin de semana, un mes, una semana, llámalo como quieras. Nos tomó, de hecho creo que vale la pena decir esto, nos tomó un año llegar allí. Pero no lo hemos hecho, no lo habríamos hecho sin, ya sabes, elegir nuestras batallas. Creo que es súper importante, y también es súper importante hacerlo basado no en algún tipo de corazonada, sino basado en algunos datos. Así que sí, haz eso, recopila datos, ten algunos datos para probar tu punto. Hará las cosas más fáciles más adelante. La delegación es tu amiga. Eso es algo grande para mí. Siempre encontré difícil delegar. Siempre encontré difícil, ya sabes, compartir mi trabajo con algunas personas. Y encontré que a veces el proyecto es tan grande que no podrás hacerlo por tu cuenta. Simplemente necesitas ayuda.

Y es bueno obtener ayuda. También es bueno obtener segundas opiniones. Es bueno compartir con la gente. Es la forma en que creces. Y simplemente hace las cosas mucho más fáciles, tan fácil. Así que sí, lo recomiendo mucho.

Y por último, pero no menos importante, ten un plan claro. También hace las cosas más fáciles. Nuevamente, comunicación, transparencia. Pero considera todas las diferentes cosas desde el principio. Siempre habrá algunas sorpresas en el camino. No estoy diciendo que no. Pero tener un plan te ayudará a mantenerte cuerdo a lo largo de todo este viaje.

Y eso fue todo de mi parte. Muchas gracias. Y espero que lo hayan disfrutado.