Herramientas de observabilidad para sistemas de diseño

Sin herramientas de observabilidad, ¿cómo saber si el sistema de diseño se está utilizando de forma eficaz o si siquiera se está usando? ¿Cómo supervisas su adopción? ¿Cómo decides en qué enfocarte a continuación?

Los sistemas de diseño aumentan la productividad de la ingeniería, ayudan a crear una interfaz coherente y accesible, generan confianza en el cliente y centralizan las decisiones de diseño en un solo lugar. Sin embargo, a pesar de sus múltiples beneficios, a las empresas a menudo les cuesta poner en marcha su sistema de diseño. Puede que el sistema gane terreno en un pequeño grupo de usuarios o en algunas áreas del producto, pero sin lograr la tracción universal que sus creadores esperaban.

Hay mucho que puedes hacer para asegurar el éxito de tu sistema de diseño, pero uno de los ingredientes clave es poder ver cómo se está utilizando. Un miembro del equipo de sistemas de diseño podría interesarse por preguntas como:

• ¿Quién está usando el sistema de diseño?
• ¿En qué parte de la aplicación es mayor la adopción del sistema de diseño? ¿Dónde es menor?
• ¿Qué está funcionando bien con el sistema de diseño?
• ¿Con qué tienen dificultades los usuarios al utilizar el sistema de diseño?
• ¿Nuestro sistema de diseño cuenta con los componentes adecuados que la gente necesita?
• ¿La gente usa los valores predeterminados que ofrece nuestro sistema de diseño o suelen optar por ignorarlos con diversos estilos o anulaciones de comportamiento?

En Webflow, hemos creado herramientas de observabilidad que nos ayudan a responder a todas estas preguntas y más.

Utilizamos un sistema de diseño interno llamado Spring, que creamos en 2022 y que hemos usado durante los últimos tres años y seguimos contando. Spring incluye nuestra biblioteca de componentes, así como nuestros aspectos de diseño fundamentales, como paletas de colores, temas, tamaños, tipografía y escalas de espaciado.

La clave del éxito de Spring ha sido la herramienta de observabilidad que hemos construido a su lado. Nuestros paneles, flujos de trabajo y herramientas integradas en la aplicación nos ayudan a obtener la información correcta en el momento adecuado para garantizar que nuestros ingenieros aprovechen al máximo nuestro sistema de diseño.

Las herramientas que utilizamos

Uno de los mantras de nuestro equipo de sistemas de diseño es "ingenioso, no chapucero". Buscamos soluciones creativas a los problemas para hacer el trabajo. A veces, las soluciones pueden ser sencillas o incluso parecer poco sofisticadas, pero no escatimamos en calidad.

Gran parte de nuestras herramientas de sistema de diseño se basan en una combinación de Google Forms, Google Sheets y Looker Studio. Google Forms no es solo para formularios orientados al usuario; también pueden registrar datos mediante programación a través de su API. Los datos registrados en Google Forms pueden enviarse automáticamente a las hojas de cálculo de Google correspondientes, y los datos de esas hojas pueden alimentar los paneles creados en Looker Studio.

Algunas de nuestras herramientas se integran con nuestro proceso de integración continua (CI) en GitHub. Por ejemplo, usamos GitHub Actions y un script de jscodeshift para analizar solicitudes de extracción individuales.

Por último, hemos creado una herramienta de visualización personalizada dentro de la aplicación que destaca qué componentes y sistemas se están utilizando en las distintas áreas de nuestro producto.

Vamos a profundizar en algunos de estos sistemas ahora.

Medición de la adopción en las superficies del producto

El primer panel que veremos muestra la adopción de Spring en las superficies del producto. La aplicación Webflow se puede dividir en varias "superficies de producto" o áreas principales. Tres de las más importantes en las que queríamos centrarnos eran el Designer, el Dashboard y el Marketplace.

(Ten en cuenta que, a medida que Webflow ha evolucionado hasta convertirse en una aplicación multiproducto que abarca mucho más que el diseño de sitios, ya no nos referimos a la herramienta externamente como "Designer", sino simplemente como "Webflow". Por precisión histórica y para evitar confusiones, seguiremos refiriéndonos a ella como "Designer" a lo largo de esta publicación).

Cuando creamos estos paneles de Looker Studio hace tres años, nuestro producto estaba atravesando cambios emocionantes. Dashboard se estaba migrando de AngularJS a React. Designer estaba recibiendo una importante actualización de interfaz. Marketplace se estaba migrando a Next.js.

El panel de Looker Studio que ves arriba cuenta una historia interesante: para superficies de producto totalmente nuevas como Dashboard y Marketplace, ¡nuestro sistema de diseño Spring se estaba utilizando con mucho éxito! El 99,45% de Dashboard y el 97,53% de Marketplace funcionan con Spring.

Para superficies de producto como Designer, que incluyen más de una década de código, la adopción fue más gradual. El código existente pudo migrarse para usar Spring en algunos lugares, y las nuevas funciones dentro de Designer siguen pudiendo construirse con Spring. Pero aún queda una parte importante de Designer que utiliza sistemas de diseño heredados que existían antes de la creación de Spring. En los últimos tres años, la adopción de Spring ha crecido del 0% al 64,08%. Es un gran progreso, pero aún nos queda trabajo por hacer.

Recopilamos estos datos varias veces al día con una GitHub Action que se ejecuta en la rama principal de nuestro monorepo. Esta GitHub Action realiza un análisis estático del código utilizando jscodeshift. Normalmente, verías jscodeshift utilizado para codemods, scripts que recorren el árbol de sintaxis abstracta (AST) de tu código, realizan modificaciones y luego vuelven a compilar el código. En este caso, sin embargo, usamos jscodeshift para recorrer el AST y recopilar datos sobre el uso de nuestros componentes, pero sin modificar nada. En su lugar, se utiliza exclusivamente para la recopilación de datos.

Los resultados de este codemod se envían a un formulario de Google a través de su API, esos datos se añaden a una hoja de cálculo y esa hoja de cálculo se integra con Looker Studio.

Observación del uso de componentes

Echemos un vistazo a otro panel de Looker Studio. Este muestra el uso de componentes en toda nuestra aplicación. No es tanto un único panel, sino una serie de varios paneles, uno para cada componente principal de nuestro sistema de diseño.

Por ejemplo, aquí tienes un panel para nuestro componente Popover:

La tabla de la parte superior izquierda (Sección 1) muestra todos los diferentes componentes Popover que tenemos. Lo más notable es que vemos que tanto nuestro sistema de diseño actual como nuestro sistema de diseño heredado tienen un componente Popover. Podemos ver los recuentos de componentes para cada uno.

El mapa de árbol de la parte superior derecha (Sección 2) nos muestra todas las áreas de nuestro producto en las que se renderiza un Popover. Las tablas de la parte inferior (Sección 3) nos muestran qué props se utilizan con Popover, qué valores de prop se utilizan e incluso los archivos específicos en los que se utiliza Popover, con enlaces a los archivos en GitHub.

Toda esta información es tremendamente útil para responder preguntas como:

• ¿Qué componentes de Spring se utilizan con más frecuencia?
• ¿Qué componentes heredados se siguen utilizando mucho en nuestra aplicación y necesitan ser migrados?
• ¿Dónde se utilizan más habitualmente estos componentes?
• ¿Qué props se utilizan más habitualmente con estos componentes?
• ¿Qué valores de prop se utilizan más habitualmente con estos componentes?
• ¿Se están utilizando valores de prop no válidos que se hayan colado a través de nuestro sistema de tipos?

Todos los gráficos y tablas que se ven aquí son interactivos, por lo que puedes hacer clic en ellos para filtrar y ver la información específica que te interesa. Considera el siguiente panel que tenemos para nuestro componente Button:

Aquí hemos profundizado para ver solo los componentes Button de Spring, específicamente la prop variant utilizada en nuestro componente Button. Nuestros botones utilizan por defecto una variante solid, pero ofrecemos opciones para otros estilos que llamamos outline, ghost y subtle.

Según los datos que se muestran aquí, cuando la gente elige un estilo de variant de botón alternativo, parece que outline es la opción más común.

También vemos 32 instancias de solid siendo utilizadas, lo cual debería ser innecesario ya que ese es el valor predeterminado de la prop. ¡Gracias a estos datos, ahora tenemos información sobre algunas instancias de Button que podríamos limpiar si quisiéramos!

Toda la información de estos paneles se recopila mediante la misma configuración que el panel de superficies de producto que vimos anteriormente: una GitHub Action se ejecuta periódicamente en nuestra rama principal; jscodeshift recorre el código para recopilar datos sobre cada importación de componente, propiedades, valores y ubicación de archivo; los datos se envían a un formulario de Google, luego a una hoja de cálculo y finalmente terminan en Looker Studio.

¡Está genial!

Obtención de información sobre el uso del sistema de diseño

Hasta ahora hemos visto algunos paneles. Consideremos otro aspecto de nuestras herramientas de observabilidad: obtener información sobre cómo nuestros ingenieros utilizan activamente el sistema de diseño.

Tenemos una GitHub Action a la que llamamos "DS Watch". Se ejecuta en cada solicitud de extracción (PR) como parte de nuestro proceso de CI. Esta GitHub Action también utiliza jscodeshift para recorrer e inspeccionar el código, pero esta vez solo analiza las diferencias de git de lo que realmente ha cambiado en la PR. El script busca infracciones específicas, como el uso de valores de color codificados de forma rígida en lugar de tokens de diseño, o el uso de anulaciones de estilo para cambiar la apariencia de los componentes.

Estas infracciones se registran a través de —lo has adivinado— un formulario de Google mediante la API, que luego añade los datos a una hoja de cálculo. Sin embargo, esta vez la hoja de cálculo no va a un panel de Looker Studio. En su lugar, un miembro del equipo del Sistema de Diseño revisa las nuevas entradas de la hoja de cálculo cada día. Si parece que el problema registrado es efectivamente una infracción, el miembro del equipo del Sistema de Diseño se pondrá en contacto con el autor del código en su PR en GitHub para ofrecerle orientación.

El programa DS Watch es útil por varias razones.

En primer lugar, nos permite, como equipo del Sistema de Diseño, conectar con los ingenieros dondequiera que estén. Los ingenieros ya envían solicitudes de extracción y reciben revisiones de código, así que ¿por qué no intervenir en el proceso justo en ese momento? Esto nos permite detectar posibles problemas en tiempo real antes de que lleguen a nuestra base de código.

En segundo lugar, nos proporciona una mayor perspectiva sobre cómo los ingenieros utilizan el sistema de diseño. Al observar las entradas de datos, podemos preguntarnos: "¿Hay algo en particular con lo que varios ingenieros parecen tener dificultades? ¿Algún error repetido?". Cuando encontramos estos patrones, suele ser una señal de que necesitamos mejorar algo en nuestra documentación o en nuestros tipos de TypeScript. Una mejor documentación aclara cuál es el uso correcto previsto, y unos tipos mejorados ayudan a evitar que se utilicen propiedades o valores claramente incorrectos.

En tercer lugar, el programa DS Watch nos permite construir relaciones con otros ingenieros en toda la empresa. Bromeamos diciendo que tenemos ojos y oídos en todas partes, espiando a la organización. Bromas aparte, este tipo de observabilidad resulta menos como el "Gran Hermano" y más como un compañero de trabajo amable que siempre está dispuesto a ofrecer ayuda cuando la necesitas.

También debemos señalar que este tipo de programa no escalará indefinidamente a medida que nuestra empresa siga creciendo. Incluso durante el último año, a medida que nuestro ritmo de contratación ha aumentado, a veces nos hemos sentido desbordados al realizar este tipo de revisiones. El script ayuda a identificar solo el pequeño subconjunto de PRs que requieren nuestra atención, pero aun así, a veces puede ser una cantidad considerable.

Seguiremos perfeccionando nuestras soluciones automatizadas mediante tipos de TypeScript, reglas de ESLint, scripts de codemod y revisores de código basados en IA. Aun así, estas herramientas deben complementar el elemento humano, no reemplazarlo por completo.

Visualización de la aplicación con el Inspector del Sistema de Diseño

La última herramienta que veremos es un visualizador personalizado dentro de la aplicación al que llamamos Inspector del Sistema de Diseño. Se trata de una herramienta de uso interno que se puede abrir sobre el Diseñador. Cuando la herramienta está en uso, aparece un cuadro de diálogo junto con una cantidad abrumadora de contornos resaltados con códigos de colores en la página.

El Inspector del Sistema de Diseño le permite ver de qué sistema proviene cada parte de la interfaz de usuario:

• Spring, nuestro sistema de diseño actual (resaltado en verde)
• emotionStyled, nuestro sistema actual de anulación de estilos (resaltado en amarillo)
• El sistema de diseño heredado (resaltado en naranja)
• El sistema de anulación de estilos heredado (resaltado en rojo)
• Los componentes del sistema de diseño más antiguos, a los que hemos llamado cariñosamente "viejas tradiciones" (resaltado en rosa)

El cuadro de diálogo del inspector del sistema de diseño te permite filtrar por sistema, componente o área de producto. Por ejemplo, en la captura de pantalla de abajo, limitamos los resaltados solo al panel de aplicaciones.

Mencionamos anteriormente en este blog que el diseñador está compuesto actualmente por un 64 % de componentes Spring, según nuestro script de análisis estático. El inspector del sistema de diseño nos ofrece ahora una medición alternativa, comprobando en tiempo de ejecución qué componentes se renderizan realmente en la página en cada momento.

El inspector del sistema de diseño se convierte en una herramienta muy útil para los equipos que quieren migrar más áreas para usar Spring. Estas personas interesadas pueden realizar exploraciones ad hoc para descubrir dónde pueden tener un mayor impacto al actualizar partes de su interfaz.

Recientemente, hemos empezado a utilizar el inspector del sistema de diseño no solo para exploraciones manuales ad hoc, sino también para enviar datos a Looker Studio. Al hacerlo, podemos obtener instantáneas de la aplicación para mostrar el estado actual del uso del sistema de diseño, no solo por superficie de producto, sino también por áreas específicas dentro del diseñador:

Conclusión

Esperamos que hayas disfrutado de este recorrido por algunas de nuestras herramientas de observabilidad del sistema de diseño. Quizás te inspire con algunas ideas sobre cómo obtener una mayor perspectiva de qué tan bien se están utilizando tus propios sistemas de diseño.

Esta herramienta ha sido un beneficio increíble para nosotros en el equipo del sistema de diseño. Además de resultarnos interesante, nos ha ayudado en muchas conversaciones de colaboración en toda la organización de ingeniería, producto y diseño.

¿Quieres ver qué tan bien se está adoptando nuestro sistema de diseño? Déjanos mostrártelo.

¿Quieres ver qué componentes se utilizan más y cómo? Déjanos mostrártelo.

¿Quieres saber con qué tienen dificultades los ingenieros? Déjanos mostrártelo.

¿Quieres ver qué áreas de crecimiento existen o dónde deberíamos centrar nuestros esfuerzos a continuación? Déjanos mostrártelo.

Los datos ganan, y contar con las herramientas de observabilidad adecuadas nos proporciona la información necesaria en el momento justo.