¿Qué Hace que un Sistema de Diseño Triunfe?

Así que quiero decir, gracias a todos por darme la bienvenida aquí. De hecho, estoy hablando el lunes. Estoy dando una charla remota sobre pruebas. Y vine aquí solo para pasar el rato porque hablé con Tejas y él dijo que la comunidad aquí era tan cálida, tan asombrosa. Esto fue simplemente una vibra tan genial que tuve que venir a verla aquí en persona. Y le dije a los organizadores, porque esto sucede, en caso de que alguien no pueda venir aquí, de hecho tengo esta charla que acabo de escribir y que me entusiasma mucho. Espero no tener que darla, pero por si acaso, aquí está. Y ellos inmediatamente dijeron, necesitamos tu ayuda. Y de hecho me siento muy triste de que Marin no pudiera estar aquí hoy. Sé que trabajó muy duro en su charla, así que quiero que todos nosotros le enviemos algunas muy buenas vibras ahora mismo, que lo extrañamos y que esperamos que lo haga bien, y esperamos verlo pronto.

Y con eso dicho, tengo una historia que contar. Así que volviendo seis años atrás, me uní a mi primera gran empresa tecnológica, y donde me uní no es tan importante, y en qué proyecto trabajé no es tan importante. Esto podría haber sido realmente en cualquier lugar.

Para contexto, esto es marzo de 2018, y me uní a esta gran empresa que era una aplicación empresarial. Y como podrías adivinar con algunas aplicaciones empresariales, el UX y UI podrían ser un poco desafiantes para algunos de nuestros usuarios. Y el proyecto al que me uní fue fundado para abordar eso específicamente para la mayoría de nuestros usuarios para nuestros casos de uso más comunes. Así que el UI y el UX para esto fue muy, muy crucial. También pudimos probar TypeScript full stack por primera vez. Así que fue un poco ambicioso, y nos importaba mucho la calidad. Nos importaba mucho ese UX y ese UI, hacerlo bien, asegurándonos de que pudiéramos entregar valor a nuestros usuarios para que no tuvieran que hacer clic en 20 pantallas solo para enviar una solicitud de tiempo libre. Queríamos que eso fuera mucho más fácil para ellos.

Y dos años después, lo logramos. Terminamos lanzando a más de 60 millones de usuarios. Nada salió mal. Para mi sorpresa. Pero pudimos entregar esta mejora de UX a tantas personas donde podían entrar y simplemente enviar algunos mensajes de chat diciendo, oye, quiero tomarme el día libre y terminar con eso en 10 segundos. Cosas así. Y nos sentimos geniales. Y por todas nuestras medidas que teníamos al entrar en esto, habíamos logrado nuestra misión.

Pero había una cosa que realmente faltaba que era crucial, si lo piensas. Al construir nuestra pieza crucial de UI y UX para nuestra aplicación, nos faltaba algo que creo que era extremadamente importante, y ese era nuestro sistema de diseño. No habíamos aprovechado nuestro sistema de diseño para construir esto. Ahora, nuestro sistema de diseño es prescriptivo y sugerente y da orientación para asegurarse de que estamos proporcionando una experiencia de usuario cohesiva. Que estamos siguiendo las mejores prácticas. Que cuando pasas de pantalla a pantalla, las cosas se ven consistentes y no se sienten como todas estas aplicaciones dispares. Y en una aplicación empresarial donde realmente hay algo así como 100 productos todos mezclados juntos, barajados en un mazo, eso es realmente importante para lograr que sea lo más cohesivo posible. Y nuestra experiencia estaba en cada página de la aplicación. Era ubicua. Para nosotros, no tener esto, no aprovechar esto, fue potencialmente un fracaso masivo. Y aunque éramos compatibles y no se veía diferente inicialmente, si el sistema de diseño fuera a evolucionar, no íbamos a evolucionar con él, porque no lo estábamos usando.

Estábamos en nuestro propio territorio, viviendo en nuestro propio mundo. Así que este fue un desafío que pensé que era muy interesante, porque yo era un desarrollador senior de UI, y conocía el sistema de diseño, y para que hubiéramos tenido éxito en nuestro proyecto, pero no usar el sistema de diseño, sentí que era algo que no podía medir en ese momento o realmente no podía señalar cuán problemático sería, pero simplemente sabía que había algo en mi instinto que me decía que había algo mal aquí que podría ser mejor.

Así que con eso, en este momento en que nuestro sistema de diseño había fallado, quiero compartir con ustedes lo que creo que hace que un sistema de diseño gane. Mi nombre es Will Klein. Experimenté 2020 como todos los demás, y para mí, este fue un tiempo muy, muy desafiante y de hecho había estado quemado durante un año antes de eso, y me uní a una llamada de Zoom. Recuerdo unirme a una llamada de Zoom, y era mi segunda vez uniéndome a esta reunión que era esta demostración mensual que nuestro equipo de sistema de diseño estaba organizando. Había estado allí antes, y finalmente me unía de nuevo ahora que estaba desconectado de todos, y de hecho estaba un poco ansioso por unirme a Zoom y ver a una persona o ver a un grupo de personas y pasar el rato, y vi su trabajo, y fue tan claro para mí que estaban haciendo un trabajo increíble, así que si su trabajo era tan bueno, ¿por qué no estaba al tanto de ello o por qué no era evidente para mí cómo incorporar el sistema de diseño en mi trabajo y ser efectivo con él? Así que reflexioné sobre esto además de estar quemado, y sentí que necesitaba un cambio, así que tuve esta idea loca, y me puse en contacto con el gerente del sistema de diseño. Su nombre era Lynn, y dije que recuerdo estar sentado en mi porche trasero, y él dijo, ¿cómo va todo? ¿Cómo van las cosas? Creo que nos habíamos conocido un año antes tomando unas copas.

Ya éramos un poco amigos, como que nos gustaba el trabajo del otro. El sistema de diseño se había abierto un año antes, del cual yo era fan. Estaba tratando de que la empresa asistiera a más meetups y conferencias y estuviera en la comunidad compartiendo nuestro trabajo, y lo estábamos haciendo. Patrocinamos nuestra primera conferencia en 2019, y aquí estamos un año después. Nos conocíamos. Éramos amigos. Dos de las personas que terminaron convirtiéndose en co-líderes del equipo, se los había recomendado a él. Así que él tenía una gran apreciación por esto, y dije, oye, este sistema de diseño es realmente bueno, pero no lo entiendo. No lo veo, y siento que esto no es solo yo. Esto es mucha gente. Este es un problema en toda nuestra comunidad de UI en esta gran empresa. Hay algo así como 80 equipos a los que podríamos estar llegando, y están alcanzando una fracción de ellos. Hay una cantidad de ellos que lo están usando, pero hay un conjunto más grande que no estamos abordando, al que no estamos llegando, que están francamente muy distraídos con, o enfocados en el trabajo que están tratando de construir, y también están distraídos por todas las comunicaciones que llegan a través de la empresa, todas las reuniones generales y todo el crecimiento que estamos experimentando.

Así que la gente, por mucho que me gustara Zoom en ese momento, la gente definitivamente estaba comenzando a experimentar fatiga de reuniones antes de la pandemia. Ahora todo está en Zoom. Solo está empeorando, captar la atención de todos y mantener su atención. Entonces, ¿cómo resolveríamos esto? Propuse esta idea loca. Dije, ¿y si trabajamos en eso? ¿Y si entusiasmamos a la gente con el sistema de diseño? ¿Cómo se vería eso? Por cierto, estoy buscando un cambio de carrera. Podría necesitar simplemente renunciar a mi trabajo porque estoy teniendo tantos problemas, y esto es tan difícil, pero 2020 es una locura. No sé qué va a pasar. ¿Y si hiciera esto contigo? Él aceptó. Estaba encantado con la idea incluso cuando le dije que estaba quemado y que era un riesgo enorme y que esto podría estrellarse y fallar totalmente, y se vería terrible. Pero él dijo que no. Necesitamos resolver esto y me dio esa confianza y me dio esa oportunidad para ver qué podíamos hacer.

Así que me incorporó al equipo. Recuerdo que me envió un documento vacío que decía escribe tu descripción de trabajo, lo cual fue algo divertido. Y terminamos definiéndolo como un rol de defensor interno de desarrolladores. Todavía podía escribir código. Podía mostrar cosas. Podía en gran medida resolverlo, y nunca había hecho esto antes. Y también, por cierto, no conocía los sistemas de diseño. Definir un sistema de diseño, incluso hoy en día, diría que es un poco un desafío. ¿Cuál es la forma correcta de definir eso? Y en ese entonces no tenía idea. Solo sabía que tenía cosas que deberíamos estar usando como desarrolladores de UI.

Y con eso... Ah, veamos, ¿dónde estoy? Quiero decir una cosa más sobre el equipo y su trabajo. Eran realmente buenos. El problema no era lo bueno que era el sistema de diseño. No era lo bueno que era el código. No era lo bueno que era el diseño. Incluso sus documentos eran muy buenos. En términos de proyectos documentados y cómo se describen y ejemplos, era, diría, mucho mejor que el promedio de lo que verías en, digamos, código abierto.

Y en términos de un proyecto corporativo, se sentía como si fuera de una calidad súper alta. Ese no era el problema. Y lo que podría hacer con este equipo fue en gran medida agregar a lo que tenían como cultura. Así que no quiero tomar ningún crédito por lo que voy a describir a continuación. Pero sí tuve la oportunidad de trabajar de primera mano en muchas de estas cosas.

Así que, como decía, mi problema como no consumidor no era culpa de ellos. Y era un desafío común. Quiero decir, no solo para nuestro sistema de diseño, sino que hablamos con otros sistemas de diseño. Tendríamos estas llamadas con otras empresas. Encontraríamos que tenían el mismo tipo de desafíos. Y también hablaríamos con otros equipos donde estaban enviando código que otros desarrolladores estaban utilizando, como ingeniería de plataformas. Como, recuerdo que había un proyecto de editor de texto enriquecido. Vinieron y nos hablaron sobre estas cosas. Realmente, cualquier momento en que estás enviando código que otros desarrolladores consumen, lo cual creo que sucede en algún momento de nuestra carrera, tienes este desafío potencial de lograr que la gente se involucre y crea en lo que estás haciendo. Y tener un camino claro para incorporarlo en su trabajo. Los desarrolladores toman el camino de menor resistencia. Quieren construir algo y enviar algo. Quiero hacer algo. Quiero sacarlo ahí fuera. Y si no me queda claro cómo algo con lo que no estoy familiarizado va a entrar y mejorar eso, eso va a ser un desafío enorme para mí.

Así que cuando comencé, dije antes, realmente no sabía lo que estaba haciendo. Pero tenía algunas ideas. Sentía que era el cliente objetivo para el que necesitaba resolver. Estaba distraído. Tengo TDAH, de hecho. Es difícil para mí mantener mi atención en cosas en las que no quiero mi atención. Que no estoy impulsado y motivado a seguir. Y estaba en ese proyecto, donde era tan importante que usáramos esto, y no lo habíamos hecho. Así que con eso, está bien. Déjame seguir con esto.

Me encanta esta cita del actor estadounidense Steve Martin. Sé tan bueno que no puedan ignorarte. Y voy a añadir a esto, o iterar sobre esto para este contexto un poco. Como dije, nuestro código y nuestro diseño eran muy buenos. Pero hay algo más que encontré que nuestro equipo estaba haciendo que fue absolutamente crucial en construir credibilidad y obtener atención y construir confianza en toda esta empresa. Y eso fue ser muy útiles.

Este equipo estaba compuesto por personas que amaban ayudarse mutuamente. Y no solo entre ellos en este equipo, sino a cualquiera que tuviera un problema. Cualquiera que tuviera una pregunta. Y conocían TypeScript, conocían React, conocían frontend, conocían accesibilidad muy bien. Y en esta gran empresa, hay muchas personas que tienen muchas preguntas sobre estas cosas. Y he estado haciéndolas durante mucho tiempo. Y así, algo que nos encontramos haciendo muy a menudo era simplemente pasar el rato en Slack, especialmente durante 2020, y simplemente responder preguntas que veíamos en el canal de TypeScript y el canal de React. Y otros canales de equipo que eran importantes. Y así nos tomamos el tiempo para simplemente salir de nuestro camino y ser lo más útiles y útiles posible.

Y al responder preguntas que no estaban relacionadas con el sistema de diseño, simplemente salimos y ofrecimos la experiencia que teníamos. Y creo que esto fue absolutamente crucial en construir la credibilidad que no habíamos perdido, pero que no teníamos. Tuvimos que ganarla. Y al ser útiles y responder estas preguntas, y ser muy amables al respecto, establecimos un tono donde la gente podía decir que si veíamos lo que estaban preguntando, no solo los ayudaríamos, sino que estaríamos realmente felices de ayudarlos. Seríamos muy amables y generosos con ello. Nunca diríamos que algo era una pregunta tonta o asumiríamos que sabían algo o los culparíamos por equivocarse. Eso era absolutamente esperado. Nos equivocamos, y eso estaba bien.

Y creo que lo realmente genial fue que a medida que la gente entraba en nuestro canal de sistema de diseño, porque sabían que estábamos respondiendo estas preguntas, y veían que trabajábamos en sistemas de diseño, así que se unían a nuestro canal, nuestro canal público, para que la gente se uniera. Venían y hacían más y más preguntas. Vimos que eso simplemente crecía y crecía y crecía. Y parte de esto era captar su atención, y parte de esto era que la gente adoptara cosas. Pero realmente comenzó con la gente simplemente queriendo ser mejores desarrolladores. Todos estamos aquí porque queremos ser mejores desarrolladores. Y esta empresa está llena de personas como nosotros.

Y así esto simplemente creció y creció, y en poco tiempo algunas de estas preguntas no eran solo TypeScript y React. Eran, bueno, ¿qué componente usaría para este caso de uso? ¿Qué debería hacer aquí? No veo un componente que haga esto. ¿Qué hago? Y ahora la gente viene a nosotros con las cosas que hemos estado deseando. Esa pregunta directa de qué hacemos. Y podemos responderles. Y también están absorbiendo esa cultura de ser amables y ser acogedores y hacer preguntas en un tono de mente abierta.

Habría personas que entrarían y serían un poco acusatorias, como, oye, esto no hace esto, realmente debería funcionar de esta manera. Y eso siempre sucede. Y simplemente lo tomaríamos con amabilidad, como tal vez debería. ¿Cuál es tu caso de uso? Simplemente haríamos preguntas y entenderíamos el problema que tenían. Y se convertiría en una verdadera discusión donde entendemos de dónde vienen, y tal vez hay algo que hicimos mal. Pero a menudo iría en ambos sentidos, y ellos verían, oh, espera, veo por qué diseñaste de esta manera. Veo por qué hay flexibilidad aquí. Veo por qué no me estás diciendo exactamente qué hacer, porque estás apoyando tantas cosas y necesita funcionar aquí y aquí, porque me mostraste esos ejemplos.

Así que sí, que la gente venga y pregunte cosas fue muy esencial, no solo para poder apoyarlos, sino para escuchar esos problemas, para entender qué estaban tratando de hacer. Lo cual es, cuanto más grande es tu empresa, más difícil es saber todo lo que está pasando. Así que entraríamos y nos sentaríamos en el standup de todos y en la reunión de proyecto de todos para saber qué está pasando, para entender todas sus necesidades, y habíamos creado esta oportunidad donde la gente venía a nosotros.

Había algo más que, también quiero darles un par de ejemplos. Si alguien tenía un problema, también buscábamos algo, siempre había algo que sentíamos que podíamos mejorar. Si no entendían algo, ¿faltaba algo en nuestra documentación? ¿Había un ejemplo que no teníamos? ¿No estábamos describiendo un caso de uso que tenían? Éramos demasiado específicos sobre otros y los habíamos dejado fuera. Así que siempre veíamos cada pregunta, incluso si realmente no sabían lo que estaban haciendo, siempre buscábamos una oportunidad para mejorar.

Y esto simplemente nos forzaba, no solo nos forzaba, sino que nos ayudaba a mejorar constantemente e iterar en nuestra documentación e iterar en cómo comunicábamos las cosas. No solo cómo hacíamos las cosas en forma escrita, sino cómo las describíamos a persona tras persona. Así que hay algo realmente genial que sucedió que creo que fue realmente, realmente genial para atraer a aún más personas que no eran tan activas en Slack, que no estaban ya haciendo preguntas. En mayo de 2021, había estado allí un año, nuestra quinta versión principal estaba saliendo, y tenía algunos cambios radicales. En particular, estábamos haciendo un gran cambio hacia componentes compuestos.

Por si acaso no estás familiarizado con eso, en lugar de simplemente darte un elemento JSX con tal vez 30 props para configurar cosas en un combo box, estábamos diciendo, hey, te vamos a dar tres o cuatro componentes. Eso podría ser 20 líneas de JSX y tienes acceso a cada uno de los elementos individuales en el árbol de componentes JSX, que a menudo se mapea uno a uno con el árbol DOM. Así que estamos dando a la gente mucha flexibilidad. De hecho, ellos, en casos, podrían tomar elementos que estábamos proporcionando e intercambiar los suyos propios y conectar la máquina de estados para que las cosas tuvieran el comportamiento compartido y funcionaran a través de diferentes elementos. Y esto es un cambio de paradigma bastante grande.

Algunas personas verían esto y dirían, esto parece más difícil. Estoy pasando de una línea a 30 o de un elemento a cinco. ¿Cómo es esto mejor? ¿Y podría esto salir mal donde tal vez estamos dando demasiada libertad y flexibilidad y tal vez nos equivocamos en la accesibilidad, tal vez rompemos eso, tal vez dejamos algo fuera? En nuestro caso, realmente se sentía como, se sentía como una apuesta, pero se sentía como una buena apuesta para dar confianza a la gente y decir, hey, te vamos a ayudar en el camino. No solo estamos disponibles para ti, también teníamos un excelente equipo de accesibilidad con el que hablábamos casi todos los días y decíamos, hey, también puedes hacerles preguntas y eran fenomenales. Así que nos inclinamos hacia, hey, no queremos solo decirte usa esto y tienes que hacerlo bien porque te lo dimos de una manera. Dijimos que te vamos a dejar hacer esto de varias maneras y nos aseguraremos de que te brindemos apoyo, no solo en nuestro canal, sino que te daremos algunas oportunidades para aprender.

Y por supuesto, en el camino, nuestro sistema de diseño y nuestros componentes fueron el tema de los ejemplos. Así que podían ver cómo se usaban esas cosas directamente. Esto terminó siendo algo que ocurrió el año siguiente. Terminé dando una nueva iteración de esto a otro grupo de personas. Algunas personas regresaron del primero, aunque el tema realmente no cambió. Solo querían un repaso. Y luego traían a sus compañeros de equipo y decían, oye, tienes que ver esto. Tienes que venir a ver esto. Y luego creo que un año después, en 2023 en el invierno, tres nuevos miembros de nuestro equipo, porque yo fui el comienzo de nuestro equipo duplicándose, tres nuevos miembros de nuestro equipo, los miembros más jóvenes de nuestro equipo construyeron una masterclass completamente nueva que se centró en el diseño responsivo y la última suite de nuestros componentes.

Así que esto se convirtió en algo que continuaríamos ofreciendo de manera continua. Y eso, quiero decir, la gente en la empresa sabía que este era un lugar donde podías ir para aprender a ser un mejor desarrollador, que podías aprender más sobre UI y no solo sobre el sistema de diseño.

Para mantener estas conversaciones de manera regular, había algo más que hacíamos. Organizábamos horas de oficina cada semana. Y hay un par de cosas que intentamos. Una de las primeras cosas que intentamos fueron las inscripciones. Y a algunas personas realmente les gustan las inscripciones porque les gusta tener algo en su calendario, algo a lo que están comprometidos. Tengo esta pregunta, y la envían. Está en una hoja de cálculo en algún lugar. Y eso funcionó para algunas personas.

Pero a menudo lo que terminaba sucediendo era que simplemente publicaba en nuestro canal de Slack. Era de manera regular, como todos los martes y jueves o todos los miércoles. Cambiaba con el tiempo. Pero los teníamos aproximadamente dos veces por semana durante 30 minutos. Y la gente, simplemente decía, oye, estamos teniendo horas de oficina ahora. Y hacía dos cosas. Porque la gente podría tener preguntas, pero podría que no. Y lanzaba cosas que estaban sucediendo en el ecosistema de UI. Siempre hay algo sucediendo. Así que decía, oye, ¿qué tal esos? Quiero decir, no era en ese entonces. Pero, ¿qué tal esos componentes de servidor de React? ¿Quién los está usando? ¿O quién tiene curiosidad por la IA en este momento? Lanzaba cosas así, iniciadores de conversación, solo para que la gente viniera a pasar el rato.

Y eso es lo que terminaba sucediendo. La gente venía a veces con preguntas como, oye, estoy trabajando en esto, quiero resolver esto. Lo abordábamos de manera práctica. Y otras veces, venían y simplemente, oye, solo estoy aquí para relajarme. Y nuestro equipo tenía una muy buena cultura de también unirse a estos. Y éramos tres o cuatro de nosotros en esta reunión de Zoom, pasando el rato, esperando que alguien se uniera. Y nos hacíamos preguntas entre nosotros, lo cual es una gran cultura de equipo. Simplemente nos reuníamos en nuestras propias horas de oficina para todos los demás y simplemente nos ayudábamos mutuamente.

Y luego alguien se unía, nos escuchaba hablar. Y yo decía, oye, ¿qué tienes? Y ellos tenían una pregunta, y nos metíamos en ello. Y esto se volvió lo suficientemente popular como para que a veces tuviéramos tres o cuatro personas entrando en la misma llamada, y yo creaba salas de Zoom, y nos dividíamos. Y de vez en cuando, iba a Slack y decía, oye, necesito ayuda. Hay más personas de las que tenemos ahora. Así que esto funcionó muy bien para mantener esa conversación en marcha. Y creo que es un buen mecanismo donde a veces en Slack, sientes que necesitas preparar un buen mensaje claro que tenga una pregunta clara. Y eso es bueno. A veces, ni siquiera estás seguro de por dónde empezar. A menudo no sé, como, simplemente no sé lo suficiente sobre esto como para saber qué pregunta hacer. Y ahí es donde las horas de oficina son fantásticas. Así que alguien podría simplemente entrar y tener una conversación y tener un ciclo de retroalimentación realmente rápido de obtener información.

Algo más que estábamos haciendo eran las demostraciones de lanzamiento. Las mencioné antes. Me unía a estas llamadas mensuales, y esas llamadas mensuales funcionaron inicialmente. Pero a medida que la empresa crecía, notamos la fatiga de reuniones. Podíamos ver la disminución de la asistencia a medida que teníamos más cosas en nuestro calendario. Había menos personas asistiendo. Así que hicimos un par de cosas aquí. La primera fue que lo redujimos a cuando teníamos un lanzamiento. Y estábamos lanzando versiones principales cada seis meses. Y estábamos lanzando versiones menores aproximadamente una vez al mes. Y encontramos que con algunas de estas versiones menores, había solo una cosa aquí o una cosa allá. Así que dejamos de hacerlas mensualmente. Lo redujimos a hacerlas solo dos veces al año con las demostraciones de lanzamiento principales. Así que pensarías que estamos llegando a menos personas, pero estábamos invirtiendo más en menos oportunidades. Y esto fue, creo, pasamos de tener la disminución de la asistencia a que volviera a subir para estos eventos bianuales. Y para acompañar esto, creo que ayudó que tuviéramos un calendario de lanzamientos muy claro. Y éramos intencionales con, oye, los cambios importantes son costosos. Te cuestan mucho esfuerzo salir de lo que estás haciendo, para ver cómo lo estamos haciendo, cómo están cambiando las cosas.

Así que mientras vamos a hacer estos cambios importantes dos veces al año, vamos a hacer intencionalmente los de mayor impacto en mayo. Antes del verano, cuando eso comenzaba, resultó ser un buen marco de tiempo para decir, oye, aquí es donde van a ocurrir la mayoría de los cambios. Y si solo prestas atención a uno de estos, que sea este. Y luego, nuevamente, en otoño, tendríamos otra ronda de cambios importantes, pero eran mucho más pequeños, mucho más ligeros, de menor impacto. No íbamos a reescribir un montón de componentes y cambiar la API para ellos como lo haríamos con componentes compuestos en un lanzamiento de otoño. Pero podríamos aprovechar la oportunidad para desaprobar algo, tal vez eliminar algo que hemos estado comunicando durante seis meses a un año, que esto va a desaparecer, o esto se va a promover de un paquete de laboratorio o vista previa al principal. Y las importaciones cambiarán. Así que simplemente va a funcionar igual, pero algunas cosas van a ser técnicamente rompedoras. Y a la gente definitivamente le gusta esta previsibilidad. Les gusta saber qué va a pasar. Les gusta saber cuándo deben prestar atención y cuánto. Y esto también ayuda porque mientras estamos comunicando este ciclo de lanzamiento, también estamos diciendo, aquí está lo que viene en tres o cuatro meses. Y mientras están trabajando en cosas, pueden tener esa conciencia de, oh, vamos a necesitar esa nueva barra lateral. ¿Y cómo se ve eso? Ya estamos construyendo. Así que tendríamos equipos que plantearan que necesitan estas cosas antes, y podríamos asociarnos con ellos temprano y decir, oh, tal vez deberíamos darte una ventaja sobre lo que estamos intentando y puedes probar esto en tu producto. Y a medida que lanzamos esto, tendremos el beneficio de tu aporte de primera mano. Y eso fue realmente útil. Entonces, ¿qué hizo esto por la adopción? Mencioné que nuestras demostraciones bajaron un poco al principio y volvieron a subir a medida que cambiamos el ritmo. Mencioné que nuestras horas de oficina estaban creciendo. Nuestro canal de Slack, creo que cuando me uní, tenía 200 y algo personas. En dos años y medio, casi se triplicó a más de 600 personas. Era la comunidad de UI más grande en nuestra empresa. Era tan grande que era como el lugar al que ir para entender lo que estaba pasando en cualquier lugar en UI, no solo para nuestro sistema de diseño. Y eso era algo de lo que éramos, por cierto, muy cuidadosos en cómo usábamos ese canal de Slack. Nunca mencionamos a todos, nunca usamos @channel o @here. Nunca intentamos llamar a todos diciendo, oye, necesitas mirar esto. Fuimos muy respetuosos con eso. Y si teníamos un mensaje para compartir, teníamos que ser muy directos y muy claros. Aquí está lo que te podría interesar. Y tal vez en esa primera línea, pienses, no me importa eso.

Y podrías ir a otro lugar y saber que no tienes que leer el resto. Pero la gente vería, oh, tengo curiosidad por eso. Ponemos muchos detalles en los hilos.

Algo más que hicimos. Mi compañero de equipo, Allen, lideró el esfuerzo de comunicarse directamente con los equipos de producto. De hecho, escribió una herramienta realmente increíble para extraer todos los repos de Git para todos los proyectos y básicamente construir un AST de todo el código que tenían, y buscar usos de nuestros componentes en sus aplicaciones. Así que teníamos métricas sobre cuánto se usaban nuestros componentes, quién los estaba usando. También miramos en qué versión estaban las personas. Ese también es un gran desafío que tuvimos que resolver, porque algunos equipos estaban en la versión 3 cuando acabábamos de lanzar la versión 6. Esto está potencialmente años atrás, y se ve terrible.

Así que déjame hablar un poco sobre las dependencias. Como mencioné con los componentes compuestos en 2021, tuvimos muchos cambios importantes, y esto podría hacer o deshacer nuestro sistema de diseño. Las cosas se volverán más flexibles. Vamos a dar más confianza a todos, pero también van a tener que reescribir mucho código. Eso no es genial, y yo, como un desarrollador de producto muy reciente, pensé que ese esfuerzo no querría hacerlo. No querría tener que cambiar cientos de líneas y en todos nuestros proyectos. Esto eran miles y miles de líneas. Así que tuve esta idea. Estaba bastante interesado en un par de herramientas diferentes relacionadas con ASTs, y dije, oye, ¿qué si escribimos code mods para esto? El equipo dijo, sí, hagámoslo, y se lanzaron de inmediato. Así que mientras desarrollábamos o reescribíamos nuestros componentes, también añadimos code mods para reescribir el código. Si no estás familiarizado, básicamente enviamos un paquete donde alguien podría decir, ejecuta el code mod para esta versión, y recorrería su código, encontraría todas las cosas que estaban cambiando, y las reescribiría a la nueva versión de la API. No puedes hacer esto para todo, pero pudimos hacerlo para algo así como el 90% de los cambios, y esas cosas muy tediosas que simplemente estás cambiando robóticamente, fueron manejadas por ti.

Esto fue tan bien que recuerdo que hubo unas horas de oficina donde alguien vino y estoy en una versión antigua. Estoy cuatro versiones atrás. ¿Cómo es pasar de aquí a lo que está actualizado? Dije, oh, probemos esto, y saqué nuestras guías de actualización, y dije, esto es lo que vamos a hacer. Vamos a ejecutar este comando de la guía de actualización para el code mod, y vamos a ver qué pasa. En unos minutos, estoy dentro de unos minutos de la llamada, en milisegundos, ejecutamos esto, y reescribió un montón de cosas. Revisamos los cambios, revisamos la guía de actualización, y nos aseguramos de no perder nada que pudiéramos necesitar revisar manualmente, y luego hicimos eso nuevamente para la siguiente versión, y después de diez minutos, él dijo, okay, wow, wow, wow, espera, espera. Esto es mucho más fácil de lo que pensaba. ¿Podemos salir de la llamada ahora, y quiero probar el resto.

Se despidió de la llamada emocionado por hacer una actualización de sus dependencias en nuestra biblioteca, y yo creo que 20 minutos después, dijo, sí, el PR está listo para aumentar todas estas versiones para nuestro equipo. Nuestro diseñador está revisando el aspecto y la sensación de todo, asegurándose de que todo esté bien. Eso fue mucho más fácil de lo que esperaba. Y esa fue la experiencia que la gente estaba teniendo, donde en lugar de ser un problema, veían que la experiencia del desarrollador era mejor, francamente, que muchos de sus problemas de gestión de dependencias.

Así que fue realmente genial hacerlo, y realmente increíble ofrecerlo. Veamos, eso es básicamente de lo que hablé con las herramientas aquí. ¿Estoy excediéndome en el tiempo? Bien, genial. Bueno saberlo. Así que, con eso, veamos. Saltando aquí, puedo omitir un par de cosas.

Hay una cosa que quiero asegurarme de mencionar, y es la defensa que encontramos sucediendo en nuestra comunidad. Así que esencialmente crecimos una comunidad, y estas personas que estaban ayudando desde el principio y con el tiempo terminaron convirtiéndose en nuestros mayores defensores. Escuchábamos historias de, oye, estoy en tus horas de oficina porque, como alguien nuevo se unía a las horas de oficina, como, ¿por qué estás aquí? Oh, Matt me contó sobre esto, y has estado diciendo cosas geniales sobre tu trabajo.

Y escuchábamos una y otra vez cómo la gente, simplemente teníamos una muy buena reputación. La gente estaba emocionada de contarse unos a otros sobre lo que estábamos haciendo, y querían más de esto sucediendo en nuestra organización. Así que teníamos mucha defensa sucediendo. Y una de las mejores cosas que vi también fue, teníamos preguntas de soporte en nuestro canal de Slack que nuestros miembros de la comunidad estaban respondiendo. Nosotros simplemente nos sentábamos, viendo a nuestra comunidad ayudarse a sí misma. Y me encanta cuando esto sucede. Hubo momentos en los que respondíamos rápidamente, pero fue bueno que realmente desaceleráramos un poco y simplemente dejáramos que eso sucediera más y más.

Y finalmente, con eso, quiero decir, dejé eso hace un año y medio. Fue un proyecto fantástico. Cuando terminé, tuvimos una demostración de lanzamiento masiva que hicimos en una fiesta. De hecho, la tematizamos alrededor de boy bands, NSYNC y Boyzone, y pusimos música, y fue muy, muy cursi. Estaba todo vestido como una estrella del pop, y también mi compañera en Dublín en el lado del diseño, Zoe. Fue una explosión. Nos divertimos tanto como pudimos con estas cosas, para que la gente no se uniera a otra reunión general o a otra cosa corporativa aburrida. Simplemente nos soltamos el pelo y nos divertimos, y fue un ambiente realmente increíble para tener.

Así que con eso, quiero decir que te animo a pensar en tu propio trabajo y cómo puedes hacer que la gente se sienta bienvenida cuando hacen preguntas, cómo puedes crecer una comunidad donde la gente se sienta bienvenida, donde sientan que pueden traerte cualquier cosa y serán apoyados. Creo que esas son las cosas que pueden ayudar a que un sistema de diseño gane, y realmente cualquier proyecto donde estemos ayudando a otros desarrolladores. Ahora trabajo a tiempo completo en herramientas para desarrolladores. Comencé mi propia empresa llamada Tool Space. Puedes encontrar todas mis redes sociales en mi sitio web, willkline.co. Por favor, encuéntrame después si tienes algo de lo que quieras hablar. Me encanta charlar sobre sistemas de diseño, experiencia del desarrollador y todo lo demás. Gracias.