Pasos para construir un Design System
Hicimos los deberes, entendimos para qué nos serviría tener un design system, llegamos a la conclusión de que realmente estamos en condiciones de encarar el proyecto y conseguimos el apoyo necesario de los stakeholders. Ahora, ¿por dónde empezamos el desarrollo de nuestro Design System?
Primero que nada, entendamos que no es un proyecto aislado. En el caso ideal, debe ser considerado un producto más de la empresa, con un roadmap de desarrollo y un backlog de funcionalidades, con un equipo dedicado y con la sola particularidad de que sus usuarios son los desarrolladores y diseñadores de los demás equipos internos. Como tal, se debe escoger una metodología de trabajo a seguir, plantear entregas con tiempos establecidos y realizar incrementos iterativos en la calidad y profundidad del producto, midiendo su uso y tu tasa de éxito.
Escribo esto pensando en el caso ideal de lograr tener dentro de la empresa un equipo dedicado al desarrollo, mantenimiento y evolución del design system. Entiendo que no siempre es este el caso, pero estos conceptos generales pueden servir para guiar los esfuerzos de equipos menos complejos y numerosos.
En los siguientes párrafos, vamos a desglosar como deberíamos conformar el equipo que va a trabajar en el design system, dejar algunas pautas para analizar el estado actual de nuestro producto, ver como definir nuestros principios de diseño, dar los primeros pasos para construir la UI, establecer la mejor manera de documentar las decisiones que tomamos y determinar pautas para realizar el seguimiento y comunicar el estado del sistema.
Conformar el equipo
Un equipo de design system es interdisciplinario por definición. Los roles obvios que nos vienen a la mente son los de diseñador y desarrollador, pero podemos profundizar un poco mas en cuanto a las responsabilidades de cada uno de ellos.
Dentro de los diseñadores, el primer rol a tener en consideración es el de Diseñador de Interfaces (UI Designer). Son quienes establecen la definición visual de los diferentes componentes, su funcionamiento, estados y criterios de utilización. Ellos son en general responsables de la parte más visible del desarrollo de un design system, y alguien en este rol es quien usualmente lleva la tarea de liderar el equipo y actuar como una suerte de Líder de Producto (Product Lead). También es muy útil contar un miembro que haga tareas de Investigación con Usuarios (User Research), sobre todo en las primeras etapas; esto permite por un lado analizar de primera mano las necesidades de nuestros usuarios (los miembros de otros equipos que usarán el sistema y los usuarios finales de la aplicación), presentando prototipos y haciendo un trabajo más bien exploratorio y propositivo; y por otro, verificar que estos puedan entender y usar efectivamente las interfaces que proponemos, de manera de tener un feedback medible y real de nuestro impacto en el producto.
Deberíamos también incluir a un Redactor de Experiencia de Usuario/Diseñador de Contenidos (UX Writer/UX Content Designer) que pueda verificar que los componentes que generamos respeten las formas comunicaciones ya definidas para las experiencias de la empresa. Por otra parte, son un gran soporte al momento de generar material de documentación y comunicación.
Del lado del desarrollo, son imprescindibles los Desarrolladores Frontend (Frontend Developer/UI Developer/UI Engineer), que son los que transforman las imágenes que crean los diseñadores en componentes reales y funcionales, con sus estados, comportamientos, variantes y validaciones. Generalmente se necesita más de una persona con este rol, dependiendo de las tecnologías que nuestro design system deba soportar (cada desarrollador tiende a especializarse en un lenguaje o plataforma en particular y un design system puede necesitar generar assets para diferentes tecnologías).
Los profesionales de Testing/Quality Assurance nos ayudan a validar la calidad y compatibilidad de nuestros desarrollos, corriendo pruebas manuales o automatizadas que mantienen la confianza en el producto que entregamos.
En las primeras instancias del un proyecto de este tipo, suele ser útil contar con el soporte de un Desarrollador Backend (Backend Developer) que prepare los servicios donde se alojará nuestro trabajo, defina la manera de disponibilizarlos al público y ayude a establecer nuestro flujo de publicación y actualización de versiones.
A partir de cierta cantidad de integrantes o cuando el trabajo se vuelve difícil de coordinar, un Agile Lead/Scrum Lead puede ser necesario para mantener a los miembros enfocados y ocupados. Finalmente, sería fantástico contar con alguien con background de Marketing que ayude a comunicar e incentivar el uso del design system dentro de la organización.
Volviendo a un escenario un poco más realista, la verdad es que los equipos de design systems suelen estar conformados por UI Designers y Frontend Developers (varios de ambos en los mejores casos), repartiendose las tareas antes nombradas y teniendo algunos momentos de soporte esporádico desde otras áreas.
Sea como sea, existen diversos modelos para organizar un equipo; para no extenderme mucho, podemos catalogarlos en Solitario (un no-equipo, una sola persona está encargada de todo), Centralizado (un equipo toma todas las decisiones y provee de soluciones al resto), Federado (todos colaboran en igualdad de condiciones a un sistema en común) y Cíclico (todos colaboran pero hay un grupo dedicado a consolidar y supervisar). Para profundizar sobre el tema, recomiendo ver estos posts de Nathan Curtis (EightShapes) y Jina Anne (SalesForce).
Analizar nuestro producto
La primera etapa de nuestro proceso intenta descubrir el estado presente y real de nuestro producto. No busca rediseñar elementos ni propone soluciones nuevas, simplemente se limita a inventariar con toda la rigurosidad posible los componentes, modelos y patrones existentes en nuestra aplicación, tal como está.
Es importante que se haga sobre el estado real de las cosas porque esto nos permite identificar elementos y situaciones verídicas de uso. Les recuerdo que un design system opera sobre la realidad de un producto establecido, el cual nos impone restricciones. Construir sobre un escenario ficticio conlleva el riesgo de comenzar una tarea que está destinada a no terminar nunca; en un escenario ideal, no hay limitaciones.
Esta auditoría se hace para entender qué es lo que tenemos construido y poder vislumbrar qué tan extenso será el trabajo de generación de consensos que tendremos por delante. Una recomendación para esta etapa: es importante incluir a miembros de todas las áreas en este proceso; de esta manera, todos pueden aportar sus puntos de vista y a su vez, conocer de primera mano cuál es el criterio racional que hay detrás de la toma de cada decisión. Tener a todo el equipo involucrado con un objetivo en común es crucial para el futuro éxito del proyecto.
El inventario visual a realizar debe ser lo más exhaustivo posible, documentando e individualizando cada elemento que exista en nuestras interfaces. Colores, tipografías, sombras, texturas, elevaciones, gradientes, espacios entre elementos, estilos de fotografías, ilustraciones e iconos; si existen, sonidos, animaciones y movimientos; todo debe ser catalogado.
Mas allá de estos elementos básicos, identificar los componentes de interfaz (elementos modulares con funciones determinadas dentro de la UI) es el principal objetivo de nuestra tarea de auditoría. Estos elementos se agrupan de acuerdo a su función, y el objetivo siguiente es buscar patrones, modelos y repeticiones que nos brinden oportunidades para unificar criterios, identificar similitudes y diferencias, y encontrar dentro de cada grupo un potencial emergente, un componente que pueda reunir las características de todas las demás alternativas, y cumplir su función sin problemas. Estos criterios de selección o descarte, deben en lo posible dejarse anotados para evitar problemas posteriores.
Los componentes de interface tienen la particularidad de ser complicados de catalogar, porque constantemente surge la pregunta ¿qué tan granular debe ser nuestra forma de catalogar? ¿es esto un componente o debería considerar sus partes como items independientes?. Si bien no hay una respuesta correcta que aplique a todos los casos (y en esta etapa no es absolutamente necesaria una clasificación exacta), una buena forma de encararlo es tomando como partida los criterios de Atomic Design, y diferenciar los componentes según los distintos niveles de construcción (átomos, moléculas, organismos…).
Otra forma de organizarlos es según la capacidad de reutilizarlos dentro del sistema; pueden dividirse en componentes (components; elementos independientes con funciones claras, poco específicos y con mucha posibilidad de ser usados en diferentes contextos), recetas (recipes; una combinación estandarizada de componentes y comportamientos con una funcionalidad) o copos de nieve (snowflakes; soluciones específicas y puntuales que no pueden ser sistematizadas por ser muy particulares).
Existen diversas mecánicas que pueden utilizarse para llevar a cabo este proceso. Desde el trabajo solitario de una persona tomando screenshots de cada pantalla de la aplicación, hasta el esfuerzo grupal de todo el equipo colaborando, pasando por soluciones semi-automatizadas con bots que pueden recorrer la aplicación y capturar cada instancia de la misma. Una dinámica que me gusta particularmente es Component Cut-Out Workshop, porque tiene una cuestión lúdica que permite involucrar a todos los miembros del equipo, sin importar si son diseñadores, programadores o tienen un background de negocios o marketing; a grandes rasgos, se reúne el equipo, se entregan capturas impresas de cada página o vista de la aplicación, y se les pide a los asistentes que identifiquen y recorten (si, analógicamente, con tijeras; también puede hacerse de forma digital pero es menos divertido) los diferentes componentes que pueden ver. En general cada persona o grupo lo hace con diferentes criterios, lo que permite en la puesta en común, entablar discusiones ricas acerca de qué elementos son indispensables y cuales pueden ser mejorados o reemplazados.
Una vez que tenemos aislados los diferentes bloques que van a componer nuestras interfaces (usando la dinámica que sea que hayamos escogido), deberíamos evaluar para cada uno de ellos:
Potenciales casos de uso: objetivos del componente, función para el usuario, lugares en que se utiliza;
Estructura y lógica de construcción: ¿cómo se construye?, ¿está formado por otros componentes?, ¿tiene dependencias de otras definiciones?;
Variaciones: cambios y combinaciones que permiten atender casos específicos;
Estados: diferentes respuestas del componente a acciones del usuario o condiciones del sistema;
Limitaciones técnicas: ¿este componente utiliza algún tipo de tecnología específica?, ¿hay alguna limitante conocida que debamos tener en cuenta?;
Posibilidades de mejora: tomar nota de aquellos problemas conocidos que el componente tiene, sean estéticos o funcionales;
Comparativa con otros design systems: research y benchmark de componentes comparables, en caso de querer implementar mejoras o desarrollar una experiencia similar a la esperada en otras aplicaciones.
Con nuestros elementos individuales analizados y aislados, ya podemos aplicar alguna metodología para decidir en qué orden se van a diseñar y desarrollar estos componentes. Los primeros de la lista son relativamente fáciles de establecer con algo de sentido común; pero a medida que se avanza en el proceso, se hace más complicado decidir a qué darle más urgencia. Una alternativa es armar una matriz de impacto-esfuerzo, que nos permita tener a la vista las necesidades de nuestros usuarios, y también seleccionar componentes a desarrollar de acuerdo a la disponibilidad del equipo. También se puede ejecutar periódicamente una dinámica como la de Priorización de Componentes en Equipo para nutrirnos de las opiniones de nuestros usuarios (internos) y avanzar con construcciones útiles.
Para toda esta primera parte del proceso, no se necesitan herramientas específicas; cualquier plataforma en la cual se puedan recolectar screenshots y operar sobre ellos (recortar, agrupar, anotar) sería de utilidad. FigJam, Miro, Mural son herramientas ideales para esta tarea, además de tener la ventaja de que pueden ser usadas en un browser cualquiera sin necesidad de instalar software ni tener conocimientos específicos. Si todos tienen acceso y los conocimientos para operarlas, también sirven las herramientas habituales de diseño que permiten la colaboración en tiempo real, como Sketch, AdobeXD o Figma.
Definir nuestros principios y foundations
Una vez que hemos podido reunir y catalogar los diferentes elementos que componen nuestras interfaces, el siguiente paso consiste en observar y tomar decisiones acerca de las mismas. Durante esta etapa, básicamente se establece qué y cómo queremos que nuestro sistema se exprese.
Si bien ya tenemos componentes y elementos de interface individualizados, lo más importante en este momento en poder definir algunos principios universales de diseño, conceptos clave e ideas guía que sean capaces de, en un futuro, ayudarnos a responder preguntas y tomar otras decisiones específicas más rápido. Estos principios tienen un lado teórico que suele enunciarse como frases explícitas, cortas, claras y fácilmente entendibles por todos; podemos encontrarlos en distintos sistemas como design principles o también como guiding light. Y tienen una contraparte más técnica, que consiste en establecer definiciones visuales que posteriormente se trasladarán al sistema como foundations, fundamentals o design bases.
Este guiding light y estas foundations específicas, son los que hacen que cada design system esté hecho a la medida de la empresa que lo genera y refleje los valores de la misma. No son lo mismo las interacciones y componentes que requieren Spotify, Airbnb, Uber o Mercado Libre. Cada una de estas empresas tiene principios distintos y cada decisión que toman sus diseñadores, debería reflejarlos.
Por ejemplo, si la definición de principios dice que tenemos que “brindar siempre información fácil, segura y completa a nuestros clientes”, como diseñadores UI deberíamos privilegiar los estilos de texto que sean legibles sin esfuerzo, abogar por una comunicación directa y sin tecnicismos, generar elementos que permitan al usuario siempre conocer en qué parte de un proceso se encuentra, y preferir experiencias más explicativas y hand-held, aunque esto implique más pasos o textos más extensos. De esta manera, los principios teóricos que establecemos se pueden manifestar en la UI que diseñamos.
Las definición de foundations para nuestro sistema es un tema muy amplio (cada uno de estos títulos se merece un post individual), pero a grandes rasgos podemos decir que establece las bases visuales y de comportamiento con las cuales después construiremos componentes de interfaz. Dentro de estas definiciones encontramos:
Sistema Tipográfico: Seleccionar las familias tipográficas con las que se trabajará (generalmente no más de 2), sus diferentes estilos (combinación de familia, tamaño y peso), adecuación a la grilla base, definiciones relacionadas a accesibilidad, tamaños mínimos y máximos, comportamiento en dispositivos de diferentes tamaños. Google Fonts tiene una extensa selección de tipografías gratuitas optimizadas para web, y herramientas como Typescale, Fluid Type Scale y Material Design nos ayudan a generar una escala de tamaños armónica.
Paleta de Colores: Primario (marca, branding), secundario (complementario), soporte y estados (alertas, errores, éxito; feedback al usuario en la UI), neutrales (escala de grises), escalas de colores (de 5 a 10 variaciones de luminosidad por color), reglas de combinación posibles según criterios de accesibilidad, variaciones en diferentes modelos de color, uso de transparencias, reglas para ampliar la paleta en caso que sea necesario. Khroma, Adobe Color y Coolors nos pueden ayudar a encontrar una paleta de colores de base para comenzar nuestro proyecto, mientras que Colorbox, Open Color, Tailwind y Material Design nos dan algunas herramientas para formar las variantes de luminosidad de cada uno.
Sistema de Espacios: Medida básica de cálculo, definir unidades de trabajo (pixeles, ems, rems), escalas, espaciado para componentes vs espaciado para layouts.
Biblioteca de Iconos: Uso de una librería externa o desarrollo de una propia, escala de tamaños permitidos, reglas de generación para crear nuevos items, tamaños mínimos y máximos, reglas de uso de color y contraste. Material Design Icons, Feather, Octicons, Phosphor, SystemUI son algunas librerías extensas, consistentes y con licencias de uso amplias.
Imágenes, fotografías, ilustraciones: Definir estilo general, ilustrador o librería externa de imágenes e ilustraciones, reglas de uso, tamaños mínimos y máximos. UnDraw, Humaaans, Ouch!, Drawkit son fuentes de ilustraciones gratuitas que nos pueden ayudar a definir el tono e imagen de nuestro proyecto antes de contratar a alguien. Unsplash es la referencia obligada cuando se trata de fotografías sin derechos de uso; también en Pexels y Burst se pueden encontrar imágenes gratuitas y de calidad.
Sistema de Grillas: Layouts de base, breakpoints, comportamiento responsive en diferentes tamaños de dispositivos, tamaños de dispositivos más usados de referencia.
Branding: Logos, variaciones de color, otros elementos de identidad (favicons, iconos para aplicaciones, avatars para redes sociales).
Animación: Escala de tiempos, tipo de aceleración, variaciones de acuerdo al tamaño de los elementos, reglas generales acerca de en qué casos usarla y cuándo evitarla. Algunas herramientas online como Ceaser, Easings o Greensock nos pueden ayudar a visualizar más fácilmente como se comportan los elementos con diferentes aceleraciones y tiempos.
Redondez, elevación, sombras: Otras definiciones visuales no obligatorios. Su presencia dependerá de las características visuales puntuales de la interface que estamos construyendo. Tools online como Box Shadow, Shadow Palette y CSSMatic nos pueden ayudar a comparar visualmente como funcionan nuestras sombras.
Principios de Escritura: Glosario, reglas para el uso de mayúsculas, formato de escritura de moneda, fechas, horarios y nombres.
Para esta etapa ya necesitamos de herramientas específicas de diseño (además de las ayudas online previamente mencionadas), para poder iterar, compartir y definir las distintas dimensiones sobre las que vamos trabajando. Sketch, AdobeXD o Figma son las más conocidas en este aspecto. Para probar estilos de animaciones en la interfaz, probablemente necesitemos del soporte de un desarrollador con quien podamos consultar las posibilidades de la tecnología con la que trabajamos (no es lo mismo animar para aplicaciones nativas que para web, ni si los movimientos serán gestionadas desde JavaScript o desde CSS), o algún software como After Effects o Principle si necesitamos hacer transiciones más complejas.
Construir la UI
Esta es la etapa que el púbico generalmente identifica como “diseño”, y consiste en establecer las características visuales que tomarán los diferentes elementos que forman nuestra aplicación. Los componentes se construyen de manera modular, de forma que puedan ser reutilizados y combinados de múltiples formas a lo largo de la aplicación.
Se suele utilizar como guía la metodología de Atomic Design, que propone ordenar los componentes a desarrollar en niveles de construcción, partiendo de átomos (elementos muy simples, con una funcionalidad poco específica, y muy utilizables en otras composiciones), moléculas (conjuntos de átomos que forman componentes para necesidades puntuales), organismos (grupos complejos de moléculas, generalmente con fines específicos), plantillas y páginas (múltiples moléculas organizados para dar forma a vistas específicas, con o sin contenido, de la aplicación). Se suelen decir que las primeras tres instancias son las que conforman el sistema (piezas sueltas y sus reglas de combinación) y las últimas dos, el producto (layouts específicos con funciones establecidas). Atomic es una metodología abierta y poco estricta, y al tener ya algunos años, han empezado a surgir reversiones y mejoras, como por ejemplo Atomic 2.0, que mantiene la misma base conceptual de elementos menores que se combinan para formar entidades más complejas, pero agrega niveles y mantiene más consistente la metáfora de los elementos de la naturaleza. Podemos evaluar distintos modos de organización hasta encontrar la manera de trabajar que cuadre con nuestro equipo.
Antes de continuar, me detengo en un concepto que funciona como complemento a Atomic Design y que son los design tokens; se los suele definir como el punto en que los equipos de diseño UI y desarrollo se conectan, porque guardan una serie de valores asociados a estilos visuales, como colores, tipografías y espacios, permitiendo que dichos valores se utilicen de manera consistente a lo largo de las diferentes vistas y plataformas usadas por la aplicación. En cierta forma, es bajar a código la mayor parte de las definiciones generales que tomamos en la etapa anterior, representando las pequeñas decisiones de diseño que hacen al estilo visual general para que actúen como via de comunicación entre los equipos. En un hipotético futuro, solo editando estos tokens podríamos cambiar drásticamente el look and feel de nuestro producto sin editar los componentes per se ni tocar demasiado el código frontend. Se pueden leer algunos pensamientos del creador de Atomic Design sobre los tokens en su blog.
Algo que no debemos dejar de lado en esta etapa, son algunas definiciones generales de flows o de experiencia que serán reutilizadas en muchas instancias de nuestra aplicación, o que exceden a un solo componente específico, como por ejemplo: patrones de validación de formularios y manejo de errores (¿Cómo se muestran los errores? ¿Detenemos el funcionamiento de la aplicación o permitimos recuperos? ¿Permitimos enviar un formulario incompleto o bloqueamos la acción haste que esté lleno? ¿Los formularios validan datos a medida que se completan o al enviarlos?), normas de uso de ventanas modales (¿En qué circunstancias se disparan? ¿Son siempre flotantes o quedan ancladas a algún extremo de la pantalla? ¿Pueden coexistir más de una al mismo tiempo? ¿Puede haber modales de más de un nivel? ¿Cómo se cierran? ¿Cómo se comportan en dispositivos mobile?), estados de los componentes (¿Cómo marcamos visualmente los componentes activos, en foco, etc? ¿Qué estados deben contemplar todos los componentes de nuestro sistema?) y adaptación a distintos tamaños de dispositivos (¿Qué textos deben cambiar de tamaño? ¿Ocultamos algunos elementos decorativos? ¿Cómo mostramos las tablas en pantallas pequeñas? ¿Los drawers y modales siguen siendo tales, o los reemplazamos por otro componente? ¿Qué pasa con la navegación?).
Con algunas definiciones generales, habiendo decidido una estructura de trabajo y teniendo nuestros principios de diseño en su lugar, podemos comenzar con la construcción de los componentes propiamente dichos. Tener un abanico importante de componentes es lo que le da flexibilidad a nuestro design system, y lo que permite que el trabajo de diseñadores y desarrolladores se acelere visiblemente. Deberíamos llegar a un escenario en el que ante cada necesidad de la interfaz, ya existe un elemento que la resuelve; y si no hay algo que la resuelva específicamente (o la respuesta existente no nos satisface), están definidas las reglas y piezas para conformar una nueva solución original.
Si bien el orden natural de construcción sigue la lógica de comenzar con los elementos menos complejos (átomos) para luego irlos combinando en estructuras más complicadas, las necesidades puntuales que revista el sistema que estamos armando serán las que finalmente dicten el orden en el que trabajemos cada uno de los elementos.
Recordemos que cada empresa, cada producto y cada equipo es un mundo, pero podemos tomar como inspiración o referencia design systems de otras empresas: Atlassian, Google, Shopify, Salesforce, Microsoft, Github, Adobe, IBM. Adele es un hermoso trabajo que recopila decenas de sistemas de diferentes. Y nunca está de más darse una vuelta por las “enciclopedias” de componentes, como Storybook Component Encyclopedia, Component o UIGuideline.
Una vez que tenemos los componentes más simples diseñados, se los puede ir combinando en estructuras más grandes, complejas y específicas.
Un momento fundamental de esta etapa sucede cada vez que el equipo de diseño hace entrega de un componente terminado a su contraparte del equipo de desarrollo. Este momento del hand off, es crucial y ha cambiado mucho en los últimos años. Antes, pasábamos un archivo de imagen (JPG, PNG) al desarrollador, que tenía que hacer malabares para poder reproducir tamaños tipográficos, colores y gradientes. Ahora, las herramientas modernas para el diseño de interfaces como Figma, Sketch o Adobe XD, ya traen incorporada la opción Inspect, que nos permite ver el código o los estilos necesarios para poder reproducir el elemento tal cual fue diseñado. Si necesitamos más profundidad en las directivas, también hay plugins que nos pueden ayudar a hacer el redlining (marcas e indicaciones de diseño) de nuestras pantallas.
Documentar nuestro sistema
La documentación de un design system es parte fundamental del proyecto; sin ella, no estamos construyendo un design system, sino que solamente tenemos una librería de elementos de interfaz, más o menos completa dependiendo del caso.
El rol fundamental de la documentación es facilitar el uso del sistema por cualquier persona, y a su vez, poder descentralizar la toma de decisiones en cuanto al uso de las partes del sistema, permitiendo que la información sobre sus componentes sea abierta y conocida por todos y, de esta manera, liberar las posibilidades de uso (y de aporte) a todos los miembros del equipo. La democratización del acceso a la información quita del medio trabas burocráticas, cuellos de botella y diferencias graves de criterio a la hora de armar una interface.
Si bien es una tarea que puede volverse tediosa y a casi nadie le gusta hacerla, es indispensable para el éxito y el correcto uso del sistema. Las secciones más generales se documentan solo una vez, y para los componentes individuales, que suelen ser los que más carga de trabajo y modificaciones periódicas insumen, existen métodos para poder automatizar al menos parte del proceso de documentación, con un mínimo de esfuerzo adicional al momento del desarrollo. Probablemente Storybook sea la herramienta más completa y extendida para mantener documentación de los componentes ya desarrollados. Y para la fase de diseño, se pueden usar extensiones como Zeplin o Zeroheight para tener información siempre actualizada directamente desde nuestros archivos de diseño.
Si queremos unificar todo el contenido en un solo lugar, tampoco hace falta desarrollar un sitio desde cero. Podemos usar alguna plataforma genérica como Notion, Coda o Tettra, y recién cuando cobre un cierto volumen, pasarse a un servicio pago específico como Frontify.
Mientras más detallada y completa sea la bibliografía que disponibilizamos, menos horas de soporte habrá que dedicarle a los usuarios del sistema (aunque esta relación no siempre es lineal, cuidado). Es importante contar con información sobre:
Visión general: organización, arquitectura de la información, tecnologías involucradas, secciones, principios de diseño (guiding light), design foundations, tokens.
Herramientas de desarrollo: software soportado por el sistema, requerimientos de hardware para desarrollar con o para el sistema, frameworks y librerías externas necesarias o recomendadas, pasos para instalar, usar o modificar el sistema.
Herramientas de diseño: software soportado, librerías y plugins externos necesarios o recomendados, pasos para instalar, usar o modificar el sistema; librerías de componentes de diseño para diferentes soportes y softwares (Figma, Sketch, etc.)
Lineamientos editoriales: glosario, reglas para el uso de mayúsculas, formato de escritura de moneda, fechas, horarios, nombres y otras informaciones repetitivas dentro de la aplicación.
Componentes: listado de items con su código de versión y disponibilidad real (disponible para su uso, en desarrollo, a considerar, rechazado); nombre, definición, casos de uso, variantes, estados, propiedades que acepta, valores input (que el componente recibe) y output (que devuelve), documentación de construcción (medidas, colores), documentación de uso (dónde, cómo y por qué debería usar el componente), ejemplos con uso de código real (editable y copiable siempre que sea posible); pueden ordenarse según su complejidad (átomos, moléculas, organismos, etc.) o su funcionalidad (contenido, navegación, feedback al usuario, ingreso de datos, etc.).
Catálogo/Biblioteca/Explorador de componentes: también lo pueden encontrar como Kitchen Sink; una página o espacio donde ver todos los componentes en todas sus variantes juntos (muy útil para hacer validación visual de cambios y conocer las posibilidades del sistema)
Equipo: ¿quiénes están detrás del sistema?, ¿cómo se organizan?, medios para solicitar soporte, incorporaciones, cambios y ofrecer adiciones.
Comunicar el estado del sistema
Cuando evaluamos los criterios para decidir si estamos o no en condiciones de encarar un proyecto de design system, escribí que para mi, uno de los principales determinantes es el compromiso existente en el equipo de usuarios para usar y respetar el sistema. Es entonces parte de nuestra responsabilidad cuidar, mantener y aumentar ese compromiso con una comunicación clara, que especifique el estado real del sistema, muestre en qué estamos trabajando y prevea qué otras cosas vamos a desarrollar en el futuro.
En este caso, es siempre preferible sobrecomunicar que quedarnos cortos con la información que damos; newsletters, reuniones fijas, posts en redes internas de la empresa, comunicados por Slack, un poster en la pared de la oficina, son todos métodos válidos y no son mutuamente excluyentes. Además de canales para exteriorizar información, es importante dejar abiertos métodos para poder recibir feedback de nuestros usuarios; un formulario preestablecido, un spreadsheet de acceso público, o una acción pre grabada en Slack, son formas rápidas de recibir información estructurada y valiosa.
El cambio en un sistema complejo es inevitable, y es muy difícil hacer que todo funcione bien desde el primer momento. Es natural y deseable que el sistema evolucione, se modifique y se adapte. Pero, dentro de esta constante inconstancia, podemos estar casi seguros de que los principios de diseño sobre los que descansan el resto de las decisiones, no deberían modificarse nunca; los fundamentals, bases y átomos, deberían cambiar muy poco a lo largo del tiempo; las moléculas o construcciones complejas, van a cambiar bastante seguido; y podemos esperar que organismos, patterns y templates muten constantemente.
Sabiendo esto, mientras más temprano en el proceso podamos involucrar a los usuarios, siempre es mejor. Invitar a personas de diferentes equipos y backgrounds a las primeras sesiones, donde se definen los límites y los principios generales sobre los que se construirá el sistema y hacerlos parte de la toma de decisiones, nos dará un grupo de embajadores que a futuro nos ayudará a defender nuestro trabajo, convencidos de los fundamentos detrás de nuestro diseño.
Una pieza fundamental de la comunicación, es la documentación del sistema de la que previamente hablamos. Pero, esta se convierte en letra muerta si no hacemos el trabajo de constantemente recordar al equipo que el sistema existe, está en movimiento y evolución, y está a su disposición para que lo usen.
Hay quienes dicen que el design system como producto debería tener consumer level marketing and communication (es decir, una estrategia de comunicación al mismo nivel que la que manejaríamos con los clientes de la empresa). Y más allá de la información periódica de cambios, avances, mejoras y roadmap para los siguientes semanas, algunas tácticas de marketing menos tradicionales que podemos usar para “publicitar” nuestro design system son:
Organizar eventos, desafíos y hackatones que obliguen a usar o colaborar con el sistema para participar; de esta forma podemos exponer a usuarios que nunca usaron el sistema a sus beneficios;
Tener un showcase que muestre casos de éxito de uso del design system, diseños y desarrollos que puedan ser admirados y copiados, destacando aquellos equipos que mejor uso hacen del producto y marcando el norte de lo que se busca desde nuestro equipo y cómo esperamos que usen los componentes que hacemos;
Generar proyectos o colaboraciones específicas con personas que nos interese tener a bordo de nuestro sistema, ya sea por el peso de sus decisiones dentro de la empresa (referentes del área de tecnología y diseño, stakeholders) o por la relevancia del trabajo que están haciendo (aplicaciones muy visibles, iniciativas muy promocionadas dentro de la empresa);
Tener preparado un onboarding al design system para cada persona que ingrese a los equipos de diseño, desarrollo y producto.
Seguimiento de uso del sistema
Una de las preguntas típicas alrededor de los design systems es ¿y esto, sirve realmente para algo?. Y si bien podemos enumerar un montón de razones por las cuales su implementación es beneficiosa para la empresa, medir fehacientemente en términos numéricos cómo impacta en el desenvolvimiento del equipo, es algo que puede tornarse complicado.
La verdad es que un design system revela su verdadero valor cuando los productos que hacen uso de él salen a producción. Si no llegan a ese estadio, lo que construimos es solo un juguete para diseñadores, que puede contribuir a mejorar algunos procesos internos, pero no explota todo su potencial. La idea detrás de todo esto, no es solo mejorar la experiencia de los equipos de diseño y desarrollo, sino también del usuario y finalmente, mejorar los números del negocio. Porque a la larga, la implementación de un design system debería repercutir en una mejora en los tiempos de entrega, en una mayor consistencia visual del diseño, en una resolución estética más cuidada y finalmente, en menores costos de desarrollo.
Un primer item a evaluar, sería sobre el uso en general del sistema. Podemos verificar para cada uno de los proyectos, aplicaciones o secciones que deberían estar usando nuestro design system, si realmente lo están haciendo. ¿Tienen el proyecto/paquete/librería instalada? ¿Es una versión actualizada? ¿Qué versión están usando? De allí podemos sacar un primer set de métricas sobre el estado del ecosistema en su totalidad, donde podemos mostrar qué porcentaje del total de iniciativas ya está usando el sistema.
Para ir más profundo, deberíamos medir la cantidad de componentes se están usando en cada producto final. Lo lógico sería que este número medido a lo largo del tiempo se vaya incrementando en una proporción mayor al crecimiento “natural” de la aplicación (entendiendo esto como el agregado sucesivo de features, secciones, etc.). Si efectivamente es así, podemos inferir que ese equipo está reemplazando código ad-hoc por componentes, aunque no estén sumando nuevas vistas o funcionalidades. Esto puede hacerse tanto en el software de diseño mediante plugins que verifiquen el uso de componentes desde la librería compartida, o directamente en el código de la aplicación ya desarrollada.
Podemos luego trasladar esa medida a horas de diseño y desarrollo ahorradas (un componente X insume Y horas de trabajo; se reutilizó código en Z ocasiones, por lo tanto ahorramos Y*Z horas de trabajo, que podemos fácilmente traducir a dinero). No es una métrica de lo más realista (porque no es real que todas las cosas se hagan desde cero cada vez), pero es muy didáctica y ayuda a demostrar el potencial de trabajar con elementos modulares.
De esta manera, ya armaríamos un primer tablero de salud general del sistema en relación a los productos que hacen uso del mismo, y podríamos hasta discernir que porcentaje del código de la aplicación es trabajo puntual de cada equipo de producto, y qué proviene del design system.
Con estas mismas mediciones, podemos tomar otras relacionadas, útiles para la construcción del roadmap del sistema: ¿Cuáles son los componentes más usados de nuestro catálogo? ¿Y los menos? ¿Qué componentes se modifican recurrentemente al momento del uso y por qué?
Otra manera de analizar el grado de conformidad del trabajo de los equipos con las reglas establecidas por el design system, es correr herramientas de análisis de estilos sobre el código real implementado, y verificar en que medida los valores utilizados en los estilos (tamaños, espacios, colores, tipografías, etc.) se corresponden con los tokens o foundations establecidas por el design system. También existen plugins que hacen el mismo tipo de análisis sobre archivos de diseño (design linters).
Más allá del feedback que nos aporta este tipo de análisis para dar respuestas a posibles cuestionamientos desde el negocio, es indispensable para poder evaluar la exactitud de nuestras decisiones y armar nuestro roadmap de crecimiento y próximos pasos. El conocimiento de cómo se está usando el sistema, en dónde está acertando y dónde está fallando, es lo que nos permite mantenernos en el proceso constante de iterar y mejorar el producto. En todo momento, un team de design system debe preguntarse si el componente que está poniendo a disposición de los demás equipos es la mejor versión posible.
Siempre es importante que el equipo de design system, como con cualquier otro producto, escuche a sus usuarios y ponga todo su foco en resolver sus problemáticas reales.
La decisión de empezar a trabajar en un design system no es trivial. Potencialmente involucra muchas personas y requiere del compromiso no solo de los encargados de construirlo, sino también de sus futuros usuarios y de los stakeholders.
Los pasos planteados aquí no son la única manera de encarar un design system, pero sinceramente espero que les sirvan como inspiración y guía para poder encontrar su propia versión del proceso con sus equipos.
