Descubre si tu sistema de diseño es mejor que nada

Mi nombre es Arseniy, soy un Arquitecto de Soluciones en Rangel Amsterdam. En esta charla, te contaré cómo medir la adopción de un sistema de diseño basado en una métrica que establecí recientemente para uno de nuestros clientes. La conversación sobre métricas requiere datos. Desafortunadamente, no es posible mostrar datos de un cliente corporativo, así que encontré un sustituto de código abierto. Usaré Grafana como ejemplo. Si no lo sabes, Grafana es una plataforma de monitoreo de DevOps. Es un proyecto antiguo y grande. Fue reescrito de Angular a React a partir de 2018. Tiene un ecosistema de complementos y, lo más importante, para el stock, Grafana tiene un sistema de diseño. Se llama Grafana UI. En su introducción de Storybook, dicen que lo construyeron para tener un ciclo de desarrollo más corto y una experiencia de usuario consistente. Estos objetivos están en línea con lo que esperarías encontrar en un sistema de diseño corporativo. Quiero que mis productos se parezcan a mis productos y quiero construirlos más rápido.

Veamos qué tan bien le está yendo a Grafana UI. En este gráfico, estamos rastreando cómo evolucionó un proyecto y su ecosistema y cómo adoptaron un sistema de diseño. La escala de tiempo horizontal es de cinco años. Las mediciones se toman en intervalos semanales. El número vertical representa los usos de los componentes de Grafana UI. Un uso ocurre cuando un componente se menciona en el código. Discutiremos más adelante qué significa esto, pero de manera simplificada, ocurre cuando mencionas un componente en una etiqueta JSX. Para tener una idea de la escala, la semana pasada en el extremo derecho del gráfico, los componentes de Grafana UI se utilizaron más de 7,000 veces en Grafana en sí y en 290 de sus bases de código de complementos.

¿Qué imagen te muestra este gráfico? La línea va en aumento. El número de usos crece constantemente con el tiempo. ¿Esto es bueno para el sistema de diseño? ¿Significa esto que el sistema de diseño está siendo adoptado continuamente? La respuesta es que no lo sabes. La razón por la que no lo sabes es la competencia.

Soy un ingeniero. Puedo usar un sistema de diseño. Puedo usar bibliotecas de terceros o puedo construir mis propios componentes. Los desarrolladores tienen la opción de cómo construir las cosas. Esto es especialmente cierto para los complementos de código abierto en este análisis. Si construyo un complemento y lo alojo en mi propia cuenta de GitHub, ¿quién puede obligarme a usar Grafana UI? La única opción para afectar mi elección es crear un buen sistema de diseño y hacer que sea fácil de usar.

Incluso si tu producto no utiliza bibliotecas de terceros, en cualquier proyecto habrá componentes Homebrew. Homebrew son los componentes de bajo nivel implementados directamente en el código del producto. Si construyes tu propio botón, eso es Homebrew. Es muy importante centrarse en los componentes de bajo nivel. No estamos buscando encontrar cada posible uso de componente. Estamos buscando la competencia. El Componente Online 2 no es Homebrew porque es compositivo, solo utiliza otros componentes. Los componentes compositivos se esperan en cualquier base de código y no compiten con el sistema de diseño. Por otro lado, el Componente Online 1 es Homebrew, utiliza una etiqueta JSX en minúsculas en lugar de una en mayúsculas. De esta manera, sabemos que se trata de un marcado sin procesar. Debido a que se trata de un marcado sin procesar, lo contamos como Homebrew.

Ahora que sabemos lo que estamos viendo, agreguemos Homebrew al gráfico. Este es el mismo gráfico que antes. Mismo eje, mismos datos, excepto que ahora se agregan los usos de Homebrew. Quiero señalar la escala una vez más. Estamos viendo un total combinado de 11,000 usos de componentes en el borde derecho del gráfico, en 291 repositorios. El área sombreada total es casi un millón de usos, aunque no son únicos ya que estamos rastreando el código a lo largo del tiempo. ¿Qué puedes ver en este gráfico? El área gris en la parte superior, que representa Homebrew, comienza antes que el área roja, que representa Grafana UI. Al principio, no había Grafana UI. Ambas líneas están creciendo. Mientras el sistema de diseño de usuario está creciendo, también lo hace Homebrew. El hecho de que las dos líneas estén creciendo significa que el proyecto y el ecosistema están creciendo. Parecen saludables. Las formas se ven bastante similares, en particular, durante el último año.

Las irregularidades en estas líneas son características de cada cambio importante, cada conjunto de cambios agrega una irregularidad o una disminución en la línea, porque significa que los componentes se utilizan más o se eliminan de la base de código. Pero observa que las formas no siempre se reflejan entre sí. Especialmente alrededor del punto 721. Si las líneas no son similares, significa que la combinación de fuentes de componentes está cambiando.

Imagina que tienes dos cubetas, Homebrew y Grafana UI. Tomas componentes de ambas cubetas y los compones para crear tu funcionalidad. Las cubetas son tus fuentes. Cuánto tomas de las cubetas es tu combinación de fuentes. Un cambio en la combinación de fuentes significa que estás tomando más o menos de una de las cubetas de lo que hacías antes. Podemos inferir a partir de este gráfico los dos conjuntos de factores que afectan el crecimiento del sistema de diseño. Cómo crece el proyecto y cómo se está desempeñando el propio sistema de diseño.

Para aislar la adopción del sistema de diseño del crecimiento del proyecto y otros factores, debemos analizar cómo cambia la combinación de fuentes a lo largo del tiempo. Y esto, en mi opinión, es el gráfico más importante para un sistema de diseño. Muestra el cambio en la combinación de fuentes a lo largo del tiempo. Es una proporción de uso de componentes Homebrew y Grafana UI. El tamaño de una base de código no es fijo. Crece y a veces disminuye con el tiempo, pero cada funcionalidad tiene oportunidades limitadas para utilizar los componentes. De un conjunto de componentes competidores que hacen probablemente lo mismo, solo vas a usar uno en cada caso. Esto significa que la elección de la fuente del componente es un juego de suma cero. Si utilizas un sistema de diseño, no estás utilizando Homebrew y viceversa. Por lo tanto, el gráfico que estás viendo muestra el desplazamiento. Representa a Grafana UI tomando las decisiones que los desarrolladores hacen al construir cosas. Cada vez más, los desarrolladores eligen utilizar los componentes de Grafana UI en lugar de Homebrew.

Algunas cosas que puedes notar en este gráfico. Al principio, solo existía Homebrew, Grafana UI aún no existía. Luego, ves un salto drástico cuando los componentes existentes se incorporan a Grafana UI por primera vez. El proyecto aún era pequeño en ese momento, por lo que esto crea un gran cambio en la proporción. Cuando ves un período de crecimiento durante un par de años, y durante el último año, el desplazamiento casi se detuvo. Grafana UI alcanzó el límite de lo que las personas pueden hacer con él en su estado actual. La simetría de las dos líneas que has visto en el gráfico anterior es casi perfecta durante el último año porque la combinación de fuentes no ha cambiado.

Grafana UI alcanzó un estado en el que cada nueva característica utiliza la misma combinación de un sistema de diseño y componentes Homebrew, incluso si los componentes en sí son diferentes. ¿Por qué este gráfico es mucho mejor que los anteriores? La combinación de fuentes es independiente del crecimiento del proyecto, el tamaño del equipo, el nivel de inversión, etc. Si duplicas el tamaño del equipo mañana, el gráfico sigue siendo válido. Elimina cualquier volatilidad debido a las características, los únicos cambios son la combinación de fuentes, nada más.

Básicamente, muestra la preferencia del equipo por el sistema de diseño sobre la competencia. Curiosamente, también tiene en cuenta la disponibilidad. Si quiero usar un componente del sistema de diseño, pero no lo encuentro, es más probable que use Homebrew. Para un negocio o un producto, puedes mirar la cuota de mercado. Este gráfico es la cuota de mercado del sistema de diseño dentro del proyecto.

¿Es tu sistema de diseño mejor que nada? Si no haces nada, si no construyes un sistema de diseño en absoluto, el producto seguirá existiendo. Las características seguirán siendo construidas utilizando otros componentes. Si tu sistema de diseño no logra desplazar a la competencia, la participación que obtiene en el uso de componentes disminuirá con el tiempo desde las posiciones iniciales. De esa manera, el proyecto crece más rápido de lo que el sistema de diseño se adopta y las características no lo utilizan mucho. Si el sistema de diseño tiene éxito en desplazar a la competencia, eso es cómo sabes que está funcionando bien. Lo que nos lleva a la propiedad básica de esta métrica. Subir es bueno. Bajar es malo. Si el gráfico baja durante un tiempo, algo está mal. Si el gráfico sube, sigue haciendo lo que estás haciendo. Aunque no puede subir para siempre. No importa lo que diga el entrenador, no puedes dar más del 100%. Incluso si haces todo absolutamente bien, la línea se mantendrá lateral en algún momento.

¿Cuál es un nivel lateral apropiado? Para un sistema de diseño de propósito general, idealmente deberías alcanzar un nivel en el que no haya otros componentes Homebrew excepto los snowflakes. Los snowflakes son esos componentes Homebrew verdaderamente únicos y exclusivos. Imagina que estás construyendo una página de destino para una campaña publicitaria de un millón de dólares. Está bien tener un montón de componentes únicos específicamente para esa situación. Tener snowflakes en el proyecto está bien y probablemente inevitable. Si solo tienes snowflakes entre los componentes Homebrew, estás haciendo un trabajo fantástico. Es posible que no alcances ese nivel. Si solo hiciste lo básico, no esperes que la línea suba demasiado alto.

Si tu base de código tiene demasiado legado, no esperes que la línea suba demasiado rápido porque refactorizar el legado es lento, por lo que desplazar el legado también es lento. Y el nivel que alcanzas depende de los objetivos. Si te enfocas en un caso de uso específico, por ejemplo, obtener imágenes de productos perfectas para el e-commerce, está bien no obtener demasiada adopción en relación con todo el código personalizado en el proyecto.

Si tienes un enfoque específico, debes ajustar tu definición de la competencia para obtener una métrica significativa. Recuerda que hasta ahora, la definición de código personalizado era cualquier componente que renderiza código sin formato. La participación del usuario es una métrica basada en el código. Si no alcanza el nivel deseado, es posible que te tientes a culpar a esos molestos desarrolladores por entrometerse en el éxito de la adopción. Eso no es correcto. El sistema de diseño requiere gobernanza para decidir qué se incluye y qué no. Requiere mucha colaboración entre diferentes personas en toda la organización: diseñadores, desarrolladores y propietarios de productos. La falta de adopción puede deberse a cualquier punto en el proceso de toma de decisiones. Si a un diseñador no le gusta el sistema, no lo incorporará en los diseños, por lo que el desarrollador tampoco lo usará. Esta medición se encuentra al final del proceso de desarrollo y se ve afectada por todas las decisiones involucradas en él.

Sin embargo, el análisis sigue siendo válido porque, al final, el producto de software es código y el sistema de diseño se envía como parte de él. Para que este análisis sea útil, debe formar parte de tu proceso de gobernanza y, para eso, debe ser económico y repetible. Deberías poder ejecutarlo en cada sprint para ver cómo cambian las cosas, reaccionar y planificar el trabajo futuro. Afortunadamente, podemos automatizarlo. Aquí tienes un famoso ejemplo de palabras sin sentido. Si te pido que me digas de qué trata la declaración, deberías poder decir que se trata de ideas haciendo algo. Deberías poder encontrar el sujeto. Observa que la frase está diseñada para no tener sentido, sin embargo, podemos hacer algunos juicios sobre ella basados puramente en la sintaxis.

¡Sorpresa! Las computadoras pueden leer código. En términos prácticos, esto significa que el código es formal. Tiene una sintaxis estricta. Tiene que ser formal para que las máquinas lo ejecuten. Podemos enseñar a una computadora a leer código y encontrar patrones en las declaraciones estructuradas. Esto se llama análisis estático de código. Al igual que con el sinsentido de Chomsky, no tenemos que ejecutar el código para averiguar qué está haciendo. Es suficiente con mirar el código. Es probable que ya estés utilizando herramientas que leen el código programáticamente.

Tu linter realiza un análisis estático para encontrar problemas sin tener que entender qué hace tu código. Echemos un vistazo a la sintaxis de un componente. Ya hemos visto este código antes. ¿Cómo sabemos exactamente que homebrew es realmente un componente Homebrew? Un componente React es una función que devuelve JSX o una clase con una función de renderizado si eres de la vieja escuela. Tanto Homebrew como no Homebrew son componentes. Ambos son funciones que devuelven JSX.

Además, Homebrew menciona una etiqueta en minúsculas. Repitamos. Para detectar un componente Homebrew, buscaremos funciones. En las funciones, buscamos etiquetas JSX en minúsculas. Si la función contiene una etiqueta en minúsculas, es un componente Homebrew. Lo mismo ocurre con las clases. Al realizar este análisis, asumimos que el código es válido porque debe ser correcto para ser enviado a producción. Si estás enviando código no válido a producción, tienes problemas más grandes y no puedo ayudarte.

Además, asumimos que el código es coherente. Es realmente difícil escribir un programa que analice todo el Javascript posible. El código que ves también crea un componente React. No creo que sea razonable intentar analizar código como este porque este código no es coherente. Afortunadamente, los humanos tampoco suelen poder leer bien el código como este. Si alguien de tu equipo está enviando esto a producción tienes problemas más grandes y no puedo ayudarte. Prometí antes decirte qué es un uso. La etiqueta online2 hace referencia a un identificador de botón definido en la línea 1. Esa referencia es un uso de un componente de botón. JavaScript generalmente no es tan simple como eso. Así que las cosas pueden complicarse un poco. El uso indirecto como este sigue siendo un uso de un botón. Hemos tomado un botón, lo hemos asignado a otra variable y hemos hecho referencia a esa variable. Esto aún cuenta. Toma dos archivos, uno donde exportas el botón y otro donde lo importas. Hay varias formas de importar, incluyendo alias, espacios de nombres y reexportaciones.

La importación es extremadamente común y tenemos que llevar un registro de ella. El uso del botón en la línea 6 debería contar. Observa que es posible rastrear el uso de un botón a partir de la importación en la línea 5. No necesitamos saber qué es el botón, solo si el paquete exporta algo llamado botón y luego se utiliza ese algo. De esta manera podemos rastrear los usos de un sistema de design importado como un paquete.

Tienes un botón, lo colocas en el objeto y lo expandes en props. Ahora has pasado el botón como una render prop. Aún es un uso de un botón. No sabemos qué sucede con el botón dentro del componente pero sabemos que es probable que se use el botón. Otro caso de uso común son los componentes de orden superior. Observa que el botón se utiliza no cuando se crea el componente de orden superior en la línea 5 sino cuando se utiliza en las líneas 6 y 7. Cada vez que se utiliza el componente de orden superior, también se utiliza el componente de botón original. Este código cuenta como dos usos del botón.

La razón por la que estoy revisando estos casos además de presumir la sofisticación de mi herramienta de rastreo es señalar que el uso en el código no es un concepto bien definido. Para la máquina, el uso solo existe en runtime. No estamos analizando código muerto. No estamos determinando con qué frecuencia algo se renderiza para un usuario en el navegador. Si estamos analizando el código estático, tenemos que definir qué significa el uso basándonos puramente en la sintaxis. Dadas todas las formas en que se puede escribir JavaScript esa definición depende de lo que consideres como uso. Mi definición está implementada en la herramienta que estoy utilizando para recopilar los data. Se llama Radius Tracker. Te daré un enlace al final.

Ahora que sabes cómo detectar componentes Homebrew y encontrar usos aquí tienes cómo calcular la métrica. Encuentra componentes Homebrew. Encuentra importaciones del sistema de design. Recopila los usos de ambos. Calcula la proporción de mezcla de fuentes. Y repite para confirmaciones históricas. He utilizado el botón como ejemplo en esta charla hasta ahora. Pero no todos los componentes son iguales. Si comparas un botón abstracto y un selector de fechas probablemente descubrirás que cada uso de un selector de fechas vale mucho más que el uso de un botón porque el selector de fechas es un componente más grande y complicado. Para obtener un gráfico más significativo, debes descontar los componentes más simples. Esto significa ajustar los pesos según la complejidad del componente. Los gráficos que has visto anteriormente tratan todos los componentes de la misma manera. Para el cliente que mencioné al principio ignoramos todos los usos de componentes como box o typography porque no son valiosos aunque estén significativamente sobrerrepresentados en la base de código. Si tomas algo de esta charla construye lo que sea valioso para tu equipo y luego mide el porcentaje de participación de uso para ver cuánto prefieren las personas lo que estás haciendo en comparación con la competencia interna. Para ejecutar este análisis tú mismo obtén el rastreador de radio que escribimos en Wrangle es de código abierto y te sugiero que lo revises. Pídeme consejo y ponte en contacto con Wrangle para obtener ayuda práctica. Gracias.