DESIGN SYSTEM
RESTRUCTURE
Lideré la reestructuración del Design System: de un único archivo a una estructura modular basada en ramas, para una colaboración más clara.
INTRODUCCIÓN
Cuando me incorporé a Swydo, el Design System estaba organizado en un único archivo que contenía todos los componentes y assets que usaba el producto, lo que dificultaba a diseñadores, desarrolladores y otros stakeholders encontrar, revisar o validar cualquier cosa. Lo reestructuré en archivos más pequeños y específicos por propósito que se comunican entre sí — más fáciles de revisar, y más fáciles de revisar y en los que colaborar para todo el equipo a través de ramas.
PROYECTO
El sistema se reconstruyó situando en su núcleo los principios de marca y de producto de la empresa, para luego dividirse siguiendo los fundamentos del Atomic Design en Foundations, Essentials, Compositions, Icons e Illustrations — con los tokens documentados en el archivo Foundations para facilitar la conversación entre diseñadores y desarrolladores.
DESAFÍO
El principal desafío era hacer que la nueva estructura fuera adoptable, no solo más ordenada: los diseñadores necesitaban poder crear ramas, iterar y solicitar revisiones sobre un único componente sin tocar el resto del sistema, mientras que los desarrolladores necesitaban una documentación en la que pudieran confiar como fuente de verdad.
MI ROL
Lideré la reestructuración del Design System como Product Designer del equipo — auditando el sistema existente, definiendo la nueva estructura de archivos y la categorización de componentes, y documentando foundations y tokens, trabajando estrechamente con los desarrolladores para que el nuevo flujo de trabajo se consolidara de verdad.
NUEVA ESTRUCTURA
A partir de experiencias previas con Design Systems, el objetivo principal era dividir el design system en archivos más pequeños que se comunicaran entre sí, haciéndolos más ligeros y fáciles de revisar.
Lo primero que hice fue identificar cuál era el núcleo de la empresa, poniendo en el centro del proyecto los principios de la compañía, tanto de marca como de negocio. A partir de ahí, el gráfico de arriba pretende mostrar cómo, desde el núcleo hasta los assets tangibles, la organización de los assets puede convertirse en una herramienta que permita a las personas de la empresa tener voz en la definición de cada paso de la creación del Design System, con los diseñadores liderando el proyecto. Aquí abajo, un flowchart detallado de cómo puede desarrollarse esta organización de responsabilidades y división de áreas.
DESIGN SYSTEM - DIVISIÓN EN CATEGORÍAS
Lo primero fue investigar los componentes disponibles. Una vez identificada la estructura de los componentes en el sistema anterior, los clasificamos siguiendo los fundamentos del Atomic Design, dividiendo los assets en: Foundations Essentials Compositions Icons Illustrations
FOUNDATIONS
En el archivo Foundations, a diferencia del sistema anterior, la idea es trabajar con Tokens que, como es sabido, facilitan la conversación entre diseñadores y desarrolladores.
Colores primitivos
Paleta de colores
Una vez añadidos los tokens a la documentación, también creé una versión más tangible diseñando parte de la documentación en el archivo Foundation. Aquí abajo un ejemplo para los colores primitivos.
En cuanto a los componentes, la idea principal es ubicar en el archivo Foundations los elementos que no son demasiado complejos en su construcción y que resultan relevantes para construir otros elementos. Aquí abajo un ejemplo del componente Button:
La ventaja de tener la documentación dividida con este criterio es que, cuando surge la necesidad de crear una variante o cambiar alguna configuración del componente actual, los diseñadores pueden crear fácilmente una rama (Branch) y enviarla para su supervisión.
Una vez terminado el trabajo en la rama, el diseñador puede solicitar una revisión a otros stakeholders, que pueden dejar comentarios o fusionar (merge) la rama si no hay problemas importantes.
ESSENTIALS
Después del archivo Foundation, el archivo Essentials incluye componentes más complejos, o "moléculas", siguiendo los principios del Atomic Design. La idea es que los componentes presentes en este nivel se construyan a partir de componentes del archivo Foundation. Un ejemplo podría ser el componente Button Group.
Arriba, la documentación del componente; abajo, la estructura de cómo se muestra el componente anidado en la barra lateral. El diseñador puede controlar tanto el componente padre como el anidado, como se muestra a continuación.
COMPOSITIONS
El archivo Compositions es el que aloja todos los componentes reutilizables más grandes y con una estructura más compleja. Aquí abajo muestro cómo abordar la construcción de un componente reutilizable con el ejemplo del Header.
Aquí abajo un detalle de cómo se construyen los componentes anidados.
Y así es como se verá un componente más complejo una vez construido y documentado correctamente.
CONCLUSIONES Y ACUERDO
Estas actualizaciones del Design System favorecieron una comunicación fluida entre diseñadores y desarrolladores y facilitaron la creación de nuevas funcionalidades. Cada vez que sea necesario implementar un nuevo componente o modificar uno existente, aquí abajo he definido un proceso para compartir del lado del diseño sobre cómo abordar posibles integraciones.
