Design System Essentials

Hola, bienvenido a Beyond 1.0, lecciones aprendidas, cosas que hacer después del primer lanzamiento de un sistema de diseño. Al final de esta charla, espero que puedas responder a esta pregunta. ¿Cómo puedes escalar y mantener tu sistema de diseño?

Hola, mi nombre es Amir Sami, soy un ingeniero de software senior en SNC Electric Company. En mi tiempo libre, me gusta hornear deliciosos productos horneados, me gusta programar, no solo es mi profesión, también es un pasatiempo. Me gusta hacer senderismo y explorar la naturaleza. Y también me gusta levantar pesas por alguna razón.

También me gustaría dar un gran agradecimiento a mi increíble equipo, sin el cual nada de lo que voy a discutir con ustedes hubiera sido posible. Mi equipo y yo trabajamos en SNC Electric Company, que es un proveedor global de equipos y servicios para sistemas de energía eléctrica. Fuimos fundados en 1911 en Chicago, donde diseñamos y fabricamos productos de conmutación y protección. Hoy en día, nuestra diversa fuerza laboral global desarrolla soluciones innovadoras para una red eléctrica más inteligente y resistente. Basándonos en este legado de innovación tecnológica y servicio al cliente, SNC impulsa la transformación de la red hacia un futuro de energía eléctrica sostenible y sin interrupciones.

Ahora, ¿qué es un sistema de diseño? Un sistema de diseño es una colección de componentes reutilizables, principios, restricciones y mejores prácticas gobernadas por estándares claros. Hay muchos aspectos en un sistema de diseño, y uno con el que probablemente estés familiarizado es una biblioteca de componentes. Hay muchas bibliotecas de componentes populares, como MaterialUI, XDUI, ShadCN y AntDesign. Básicamente, una biblioteca de componentes es un conjunto de componentes reutilizables que se pueden usar para construir una interfaz de manera más efectiva y eficiente. Un sistema de diseño amplía una biblioteca de componentes e incluye información sobre qué, cuándo, y cómo usar el color, la iconografía y la tipografía, así como cómo calificar el contenido para tu aplicación. También incluye soporte de documentación y también incluye patrones para construir interfaces. Todo esto se une para formar un sistema de diseño. El papel de un sistema de diseño no es limitar a sus usuarios, sino hacer que el diseño y el desarrollo sean más fáciles, rápidos y consistentes.

Cuando estábamos trabajando en nuestro sistema de diseño, evaluamos muchas bibliotecas, seleccionando finalmente React. Por eso estoy hablando en la React Summit. Elegimos React debido a su increíble soporte y comunidad, su excelente rendimiento para aplicaciones grandes y complejas, así como su soporte multiplataforma a través de cosas como React Native. Decidimos usar TypeScript en conjunto con React para asegurarnos de que nuestro código del sistema de diseño fuera lo más seguro posible en cuanto a tipos. Originalmente comenzamos a trabajar en nuestro sistema de diseño en 2018 cuando mi gerente y yo nos dimos cuenta de que estábamos recreando los mismos componentes una y otra vez en varios proyectos y también estábamos respondiendo las mismas preguntas relacionadas con el diseño. Después de esta realización, comenzamos nuestra investigación sobre los sistemas de diseño a principios de 2018, documentando los requisitos para nuestro propio sistema de diseño y teniendo un prototipo inicial listo para finales de 2018. A lo largo de 2019, continuamos mejorando e iterando en este prototipo, lanzando finalmente nuestra versión 1.0 a finales de 2019. En 2020, continuamos trabajando en nuestra versión 1.0 y comenzamos a planificar nuestra versión 2.0, que fue una revisión y renovación importante tanto de los componentes del sistema de diseño como de la documentación. En 2021, continuamos iterando en eso, y a principios de 2022, lanzamos nuestra primera versión 2.0 de nuestro sistema de diseño. Desde entonces, casi de inmediato comenzamos a trabajar en el desarrollo de componentes móviles y a descubrir cómo incorporar eso junto con nuestros componentes web que ya habíamos construido. Continuamos iterando en nuestros componentes web y lanzándolos, lanzando finalmente nuestros componentes móviles junto con ellos a finales de 2022 con la versión 22.1, que fue una renovación y revisión importante de nuestro sistema de diseño.

Continuamos iterando en nuestro sistema de diseño en los años siguientes, llegando finalmente a la versión más reciente, que es la 24.6. El sitio de documentación inicial de nuestro sistema de diseño lucía así, incluyendo información básica y pautas sobre cómo usar el color, la tipografía y la iconografía, entre muchas otras cosas, así como un pequeño conjunto de componentes de React que los desarrolladores podían usar para construir interfaces. Nuestra versión actual del sitio de documentación de nuestro sistema de diseño se ve así. A medida que crecimos, hubo más contenido y más componentes.

Me enorgullece decir que hemos trabajado en nuestro sistema de diseño durante más de seis años y medio. Durante esos seis años y medio, lo hemos expandido para incluir más de 70 componentes y brindar soporte a más de 50 desarrolladores internamente, y ahora brindamos soporte a más de cuatro plataformas, como web y móvil, a través de React y React Native. Es importante comprender quiénes son los usuarios de su sistema de diseño, ya que pueden abordar de manera más precisa y específica sus necesidades. Para nosotros, hemos identificado tres tipos de usuarios: diseñadores, desarrolladores y probadores. Al identificar estos tres tipos de usuarios, hemos podido crear documentación específica para cada uno. Para los diseñadores, proporcionamos información como herramientas y recursos para crear diseños de manera más fácil y rápida. Para los desarrolladores, son pautas y orientación sobre cómo configurar su entorno y cómo usar nuestros componentes. Y por último, para los probadores, es una guía sobre cómo probar aplicaciones construidas con nuestro sistema de diseño.

No hace falta decir que tenemos mucha experiencia en el desarrollo y mantenimiento de nuestro sistema de diseño, y me gustaría centrarme y discutir cuatro áreas con ustedes hoy, siendo la primera la arquitectura del proyecto. Cuando comenzamos a trabajar en nuestro sistema de diseño, el alcance se limitaba solo a los componentes web. Pero muy rápidamente después del lanzamiento de la primera versión, comenzamos a recibir preguntas sobre cómo incorporar otros aspectos como componentes móviles, componentes de escritorio, utilidades y variables CSS, entre muchas otras cosas. Y descubrir cómo incorporar todo esto de manera fluida mientras compartimos la mayor cantidad de código y estilos en nuestro sistema de diseño fue una tarea bastante difícil. En última instancia, decidimos refactorizar todo el código de nuestro sistema de diseño en un monorepo.

Desde mi propia experiencia, esta no fue una tarea divertida, y sugiero encarecidamente que comiences con un monorepo en lugar de migrar a uno en el futuro. Tener un monorepo desde el primer día te brinda la flexibilidad para crecer a medida que crecen las necesidades de tu sistema de diseño. Como puedes ver, nuestro sistema de diseño es bastante grande y complejo, con múltiples componentes en movimiento. Y como probablemente sepas, en cualquier software, aplicación o proyecto de software, aparecerán errores. Hemos hecho todo lo posible para mitigar y prevenir errores escribiendo la mayor cantidad de pruebas unitarias que podemos, logrando finalmente una cobertura de código superior al 80%, pero eso simplemente no fue suficiente para nosotros. Para prevenir aún más errores, decidimos expandir el alcance de nuestro sistema de diseño y nuestro monorepo para incluir dos paquetes adicionales de uso interno, una aplicación móvil de ejemplo y una aplicación web de ejemplo. Como sugiere el nombre, estas son aplicaciones de ejemplo que proporcionan ejemplos de nuestros componentes en uso entre sí. A través del poder de los paquetes de enlace automático en un monorepo, pudimos implementar estas aplicaciones localmente y probar los cambios que hemos realizado y buscar regresiones o nuevos defectos. Hemos llevado esto un paso más allá al implementar e integrar herramientas de pruebas de automatización como Cypress para probar automáticamente estas aplicaciones en busca de esas regresiones y defectos. Además, estas herramientas de pruebas de automatización se ejecutan como parte de nuestro pipeline de CI/CD para verificar automáticamente estos elementos y fallar las compilaciones si se encuentran defectos o regresiones, notificando al equipo para que podamos detectarlos antes de que se complete y realice una versión.

Ahora, cuando comienzas a trabajar inicialmente en la base de código de tu sistema de diseño, es muy fácil ubicar archivos de manera desordenada en todo el código. Pero a medida que crece en complejidad y tamaño, gestionar estos diferentes archivos y carpetas se vuelve innecesariamente complejo. Sugiero que muevas esta complejidad a un lado y, en su lugar, coloques conjuntamente la mayor cantidad de código posible.

Ahora, ¿cómo se ve esto en la práctica? Echemos un vistazo. Por ejemplo, con un componente de botón, tienes tu directorio para el archivo del componente. Y en este directorio, debes incluir las pruebas de extremo a extremo, las pruebas unitarias, el archivo de Markdown o la documentación para el componente. En nuestro caso, usamos Markdown ya que mejora el proceso de creación y edición, especialmente a medida que involucramos roles no técnicos como diseñadores y redactores técnicos. También incluimos los estilos, ya sea CSS o CSS y JS. También incluimos las escenas, que son muy similares a las historias de storybook. Y por último, el archivo del componente. Aunque esto puede parecer simplemente hermoso, proporciona una forma más fácil de trabajar en los componentes tanto para los mantenedores existentes como para los contribuyentes del proyecto, y al incorporar nuevos desarrolladores. En lugar de decirles a los desarrolladores que busquen en múltiples ubicaciones los archivos relacionados con un componente, puedes dirigirlos a un solo directorio como este.

Ahora, hablando de la incorporación de nuevos desarrolladores, cada desarrollador que se incorpora trae su propio estilo de código. Y aunque esto puede estar bien en ciertos casos, cuando estás trabajando en un sistema de diseño, el objetivo final es tener una base de código mantenible. Y eso simplemente no es posible con múltiples estilos de código. En su lugar, sugiero que apliques un estilo de código único en toda tu base de código mediante algo como un linter. Debes hacer que tu linter se ejecute en dos fases específicas. La primera es como un gancho previo a la confirmación para evitar que los desarrolladores confirmen código que no cumple con tus estilos de código, y la segunda es como parte de tu canalización de CI/CD para evitar que se fusionen cambios de código que no cumplen con tus estilos de código. Ahora, esto puede parecer molesto al principio, y créeme, lo es, pero en última instancia mejora la mantenibilidad de tu base de código y los desarrolladores que trabajan y contribuyen a tu base de código del sistema de diseño aprenderán rápidamente los estilos de código de tu proyecto.

A continuación, hablemos de la documentación, que es sin duda una parte muy importante de tu sistema de diseño. Cuando estábamos trabajando en la última renovación de nuestro sitio de documentación, estábamos evaluando muchos frameworks como Docusaurus, Box y Styleguides, que son frameworks más específicos para este propósito. También decidimos evaluar frameworks más generales como Next.js. En última instancia, decidimos seleccionar Next.js ya que los diseñadores detrás del sistema de diseño querían construir un sitio de documentación muy completo y personalizado que brindara el máximo valor a nuestros usuarios. Si echamos un vistazo a un ejemplo de una página de documentación de un componente, específicamente el componente Button, podemos ver que hay mucha información aquí. Me gustaría recordarte que todas las páginas de documentación en nuestro sitio de documentación del sistema de diseño se construyen utilizando Markdown. Ahora, en la parte superior, podemos ver que tenemos el nombre del componente, una descripción, y justo debajo de eso, podemos ver que este componente Button tiene un componente móvil hermano. Como tal, permitimos a nuestros usuarios alternar entre las diferentes plataformas que son compatibles con este componente. Si echamos un vistazo a esta página de documentación, veremos información adicional como una vista previa en vivo que proporciona una experiencia interactiva similar a una GUI para jugar y configurar tu componente. Debajo de eso, tenemos una sección de contenido que describe qué tipo de contenido se debe usar con este componente y qué no se debe usar con este componente. Y debajo de esto, también tenemos ejemplos de uso que muestran usos comunes del componente, una breve descripción y un fragmento de código. Y por último, una tabla de detalles de props que enumera todas las props, sus tipos, cualquier valor predeterminado y una breve descripción de todas las props disponibles para el componente. En las primeras versiones de nuestro sistema de diseño, la tabla de props era algo que codificábamos y obviamente no es mantenible. Cada vez que hacíamos un cambio en un componente, teníamos que recordar y asegurarnos de volver a el archivo de documentación y hacer cambios allí también.

Como probablemente puedas suponer, en algunos casos, nos saltamos eso y causó frustración tanto para nosotros como mantenedores del sistema de diseño como para nuestros usuarios del sistema de diseño. Afortunadamente, en las versiones más recientes del sistema de diseño, hemos podido resolver este problema a través de esta increíble biblioteca llamada react.gen typescript, que es capaz de analizar dinámicamente las props de un componente dado el camino a un archivo de componente. Esto nos permite simplificar nuestra documentación y construir aspectos más interactivos de nuestra documentación también. Si echamos un vistazo a un ejemplo de fragmento de código del archivo de Markdown para la página del componente de botón que acabamos de ver, podemos ver que tanto para la vista previa del componente como para la tabla de props, las props ya no están codificadas en duro, sino que bajo el capó, las props se analizan a partir del archivo de componente y luego se inyectan en ambos componentes, lo que en última instancia nos permite construir aspectos más interactivos y más mantenibles de nuestro sistema de diseño, como una vista previa del componente, que antes no era posible. También me gustaría hablar de las notas de lanzamiento. Aunque puedes crear notas de lanzamiento, ya sea en GitHub o Bitbucket, por ejemplo, no hay una razón real para tener información adicional relacionada con tu sistema de diseño ubicada en aplicaciones o sitios web de terceros. Tu usuario ya está aquí, así que inclúyelo aquí. En nuestro caso, tenemos una página de resumen que describe todas las versiones principales del sistema de diseño, así como las versiones específicas de los paquetes. Y si echamos un vistazo a una página de notas de lanzamiento de una versión específica del paquete, podemos ver que para cada lanzamiento menor, llamamos a cuatro categorías: cambios importantes, nuevos componentes, correcciones de errores y actualizaciones. Al mencionar estas cuatro categorías, podemos transmitir a nuestros usuarios de manera muy rápida el valor que se agrega en cada lanzamiento. Luego pueden tomar decisiones informadas sobre si deben actualizar a este lanzamiento y qué se debe abordar o hacer al actualizar al lanzamiento. A medida que tu sistema de diseño evoluciona a lo largo de los años, esperamos que realices cada vez más lanzamientos. Pero a medida que realizas lanzamientos, también es importante definir cuándo será el final de la vida útil de cada una de las versiones. Y debes comunicarlo de manera efectiva a los diferentes interesados del proyecto. Esto no solo ayudará a generar confianza y confiabilidad con los interesados del proyecto, sino que también definirá una línea de tiempo clara para cuándo los proyectos deben actualizarse a una versión más reciente y compatible de tu sistema de diseño. Y hablando de lanzamientos, es importante comunicar los lanzamientos que estás realizando. Envía mensajes en Teams o Slack, envía correos electrónicos y también programa demostraciones. Muestra el trabajo que estás haciendo y muestra el valor que estás agregando a tu sistema de diseño con cada lanzamiento. A continuación, hablemos de las estadísticas de uso de componentes. Lo diré diez veces rápido. ¿Qué son las estadísticas de uso de componentes? Es simplemente recopilar información sobre cómo y dónde se utilizan los componentes. Ahora, supongamos que tienes tu sistema de diseño y tu sistema de diseño es utilizado por tres proyectos, Proyecto A, B y C. Ahora, si tu sistema de diseño realiza un lanzamiento que incluye, digamos, un cambio importante para el componente de botón, sin estadísticas o información alguna, realmente no comprendes qué tipo de impacto puede tener ese cambio. Cuando en realidad, el Proyecto A podría tener un error significativo, el Proyecto B podría estar totalmente bien y el Proyecto C podría compilar con algunas advertencias. Pero nuevamente, sin esas estadísticas o esa información, no sabes qué está sucediendo y qué tipo de impacto tienes en esos proyectos. Hemos podido abordar este problema en S&C desarrollando un script personalizado que analiza los diversos archivos JSX en un proyecto y recopila información sobre cómo y dónde se utilizan los componentes. Esta información se informa a este panel al que el equipo del sistema de diseño tiene acceso, donde podemos ver en función de la plataforma qué proyectos están utilizando el sistema de diseño, cuántas instancias de nuestros componentes hay en cada proyecto y si ha habido un cambio en ese recuento desde la última vez que se realizó el panel. Podemos profundizar aún más en información más detallada a nivel de componente y ver en qué proyectos se está utilizando un componente y en qué archivos específicamente, así como qué props está utilizando cada proyecto. Toda esta información nos permite obtener información sobre cómo se utilizan nuestros componentes en nuestros proyectos y nos permite comunicarnos de manera más efectiva con los interesados del proyecto y tomar decisiones más informadas como mantenedores del sistema de diseño. Por último, hablemos de los patrones. A medida que desarrollas aplicaciones en tu empresa, te darás cuenta de que hay patrones comunes en tus interfaces. Debes documentar estos patrones comunes, como formularios de inicio de sesión, diálogos de portal, diseños de navegación y formularios. Documentarlos no es suficiente. Debes proporcionar ejemplos y definir cómo deben interactuar esos patrones con los usuarios y cómo deben funcionar, además de proporcionar ejemplos de código a tus desarrolladores, para que no tengan que reinventar la rueda cada vez. Ahora, al comienzo de esta charla te hice una pregunta. ¿Cómo puedes escalar y mantener tu sistema de diseño? Espero que al discutir y centrarnos en las cuatro áreas en las que nos enfocamos en S&C, puedas responder esta pregunta de manera más efectiva. Me gustaría agradecer a todo el increíble equipo con el que tengo la suerte de trabajar todos los días, sin los cuales nada de lo que he discutido contigo hoy habría sido posible. Así que de izquierda a derecha, tenemos a Anne, Sarah, que es nuestra increíble gerente y líder, Jacob, Ted y Audrey. Gracias.