Introducción

Antes de sumergirnos en el mundo de los Design Systems, primero necesitamos entender un poco sobre dónde y cuándo surgió la necesidad de utilizar bibliotecas de componentes, qué es en realidad un Design System, y por qué lo necesitamos cada vez más como herramienta clave para el éxito de nuestros productos digitales.

Todo comenzó cuando surgió la necesidad de modularizar sistemas, que no es más que la reutilización de componentes en diversos productos diferentes. Esto ocurrió debido al enorme crecimiento de nuevos dispositivos, tamaños de pantallas y entornos de acceso en línea que continúan surgiendo hasta el día de hoy. 

Un sistema modular no solo hace más simple el proceso de desarrollo de nuevas UI’s compatibles con varios dispositivos de forma rápida, sino que también permite garantizar la consistencia de la estructura visual y la experiencia de un sistema – lo cual es aún más necesario cuando estamos hablando no solo de uno, sino de varios sistemas de una misma organización.

Con la necesidad de lidiar con la diversidad de dispositivos y con el objetivo de construir proyectos de forma consciente, surgieron, al inicio, los famosos frameworks de componentes como “Bootstrap”, por ejemplo, que fueron creados con el propósito de facilitar y agilizar el desarrollo de interfaces de front-end.

“Estos frameworks no son más que estructuras de interfaz de usuario que proporcionan una colección de patrones HTML predefinidos, estilos CSS y JavaScript para agregar funcionalidad a componentes interactivos como menús desplegables y carruseles. Uno de los aspectos más atractivos de estas estructuras es la velocidad.” (Brad Frost)

Como no todo en la vida son rosas, por más increíbles que parezcan estas estructuras, poseen desventajas.

Con el tiempo, se hizo necesaria la personalización de los componentes y la adaptación a la marca de cada producto, además de la creación de nuevas experiencias para diferentes productos.

Por lo tanto, lo ideal sería tener pequeñas bibliotecas para cada producto y cliente que puedan personalizarse según sus necesidades, pensando no solo en satisfacer las necesidades del equipo de diseño y desarrollo, sino principalmente las necesidades del usuario final.

Entonces, qué es un Design System?

Identificamos, entonces, que necesitamos más que frameworks de componentes, ¡necesitamos Design Systems! Estos son conjuntos de bibliotecas que unifican el lenguaje de un producto determinado.

“Un Design System no es un proyecto, es un producto que sirve a productos.” (Nathan Curtis)

Un Design System, en general, está compuesto básicamente por design tokens, bibliotecas de componentes y bibliotecas de código.

A menudo lo confundimos con una Guía de Estilo, pero ten en cuenta que el DS va mucho más allá de eso y/o de una simple biblioteca de componentes.

Me gusta la analogía de que el DS es una pizza y la guía de estilo es como una pequeña porción de esa gran pizza que es un Design System. Vamos a explorar algunos de los puntos que componen un DS a continuación.

Guía de Estilo

La Guía de Estilo es súper importante para la creación de los design tokens de un Design System.

Es una documentación que especifica las directrices de comunicación verbal y visual de una marca o producto, y está compuesta por: reglas de uso de la marca, posicionamiento, escritura, tono y voz, fuentes, colores, iconos, ilustraciones, formas, lenguaje de diseño, patrones de interfaz de usuario, etc.

Una guía de estilo proporciona una base para todos los involucrados en el proyecto, donde cada uno puede contribuir con sus respectivas consideraciones y preocupaciones sobre los estándares y el lenguaje de un producto.

“La educación es tan importante como la documentación. Una guía de estilo puede mostrar a los clientes que los sitios web son sistemas, y no colecciones de páginas.” (Anna Debenham)

Design Tokens

Los Design Tokens son las variables semánticas de estilo de nuestro Design System – la mejor definición dada por Meiuca, una de nuestras grandes referencias en DS hoy.

O sea, no son más que propiedades de estilo que tienen un significado común para el equipo y que pueden variar según las necesidades de nuestro proyecto.

Para dejarlo un poco más claro, estos tokens son una forma unificada de describir los elementos de estilo (extraídos de nuestra guía de estilo) que pueden tener su valor alterado en cualquier momento y también pueden combinarse entre sí para formar nuestros componentes después.

Biblioteca de Componentes

La biblioteca de componentes está compuesta por el mapeo de todos los componentes utilizados para la construcción del producto, especificando desde la estructura visual hasta la comportamental de cada uno de ellos.

O sea, contiene todos nuestros componentes con sus variantes, estados, funcionamiento, cómo se deben o no usar, cómo pueden combinarse entre sí, etc.

Existen algunas metodologías como, por ejemplo, el “Atomic Design”, creado por Brad Frost, que ayuda en la creación de Design Systems, facilitando principalmente la construcción de bibliotecas de componentes más robustas y estructuradas.

Sin embargo, existen varios otros modelos como, por ejemplo, la forma en que Meiuca organiza sus Design Systems, pensando en una construcción de diseño basado en “components first”, distribuyendo sus bibliotecas de componentes de forma a facilitar no solo la construcción de diseño de forma organizada y bien estructurada, sino también pensando en mantenimiento y en el espejado de bibliotecas de código para diferentes Stacks.

Biblioteca de Código

La biblioteca de código no es más que el espejado de nuestra biblioteca de componentes en código.

Mediante un mapeo, estos componentes se desarrollan de modo que se pueda reutilizar su implementación, siguiendo todas las directrices de nuestra biblioteca de componentes.

Así, se tiene una biblioteca de código que se comparte entre los productos, garantizando la consistencia y la posibilidad de reutilización de código entre proyectos.

Es común utilizar, para documentar bibliotecas de código y permitir mapear todos los componentes de forma más simple y rápida para los desarrolladores, herramientas como “Storybook”, por ejemplo, que ya fue mencionada anteriormente en una de nuestras publicaciones.

Entonces, por qué utilizar un Design System?

Para empezar, después de todo lo que ya hemos visto hasta aquí, podemos decir que un Design System es una gran ayuda para facilitar la vida de todos. Vamos a resaltar algunos de los puntos que lo hacen tan importante para la construcción de nuestros productos.

Un Design System, por encima de todo, trae claridad a un proyecto, eliminando ambigüedades y permitiendo que todos del equipo puedan entender y actuar con confianza, precisamente por cuenta de la documentación más robusta, que abarca desde la estructura base de un componente hasta cómo debe comportarse y aplicarse.

Se realizó un estudio por Figma para medir de forma cuantitativa el proceso creativo de algunos de sus diseñadores.

Los participantes tenían dos tareas, y solo para una de ellas se proporcionó un Design System. Se identificó, entonces, que los participantes que recibieron acceso al DS completaron sus objetivos 34% más rápido que los demás que no lo recibieron.

Por lo tanto, agilidad y eficiencia son otras dos súper ventajas en la utilización de un DS.

Además, los componentes creados pueden reutilizarse entre proyectos, dando apertura para que el equipo se enfoque más en la resolución de problemas y garantizando consistencia y una buena experiencia de uso de los productos desarrollados.

¡Pero no para por ahí! En negocios, existen beneficios que pueden agregar mucho valor al producto.

Además de proporcionar rapidez, reducción en el tiempo y costo de comercialización del producto, es posible desarrollar un proceso más ágil de lanzamiento de nuevas versiones y con calidad, garantizar una interacción más intuitiva del producto y reducir el tiempo de adaptación para nuevos usuarios, como consecuencia de una buena experiencia a partir de un diseño consistente.

Así, podemos crear diseños y códigos más limpios, crear un sistema de diseño sólido y claro para todos los involucrados desde el inicio del proceso, permitiendo alteraciones con más facilidad conforme el producto crece.

Además de lograr un proceso de integración de nuevos miembros en el equipo más ligero y simplificado, podemos mantener a todos del equipo en la misma página, que puedan colaborar entre sí, compartir conocimiento y contribuir directamente con el producto. ¡Todo esto y más a través del Design System!

Entonces, qué te parece el Design System?

Nosotros en Zappts estamos estudiando constantemente formas de entregar productos de calidad que ofrezcan experiencias increíbles a nuestros usuarios.

En la segunda parte de este artículo hablaremos un poco más sobre cómo funciona un Design System en la práctica y un poco de los desafíos que enfrentamos, especialmente en el día a día de la construcción de nuestros productos. ¡Estén atentos!

Dejo aquí algunos ejemplos top de DS para inspirarse:

• Material Design
• Atlassian Design System
• Microsoft Design
• Mailchimp
• Uber.com
• Ant Design

Referencias:

• Todo lo que necesitas saber sobre Design System | por Jonatan Zylbersztejn | UX Collective (uxdesign.cc)
• Designing Systems | Atomic Design by Brad Frost
• ¿Qué es un Design System? ¿Cómo crear un sistema de diseño? (chiefofdesign.com.br)
• Entendiendo Design Systems. Antes de comenzar: Qué es Design… | por Van Serradas | UX Collective (uxdesign.cc)
• Meiuca Design
• Design System – Una guía de design tokens por Yanna Ballantyne en Invision Design
• Figma – Midiendo el valor de los design systems por Clancy Slack

    Esta publicación fue desarrollada por Carol Zaglia, UX Designer en Zappts.