Design system: qué es y para qué sirve

Un design system (sistema de diseño) es el conjunto de decisiones visuales y de interacción de un producto digital, recogidas con sus reglas de uso: colores, tipografías, espaciados y componentes como botones, formularios o tarjetas. Sirve para que una web o una aplicación sea coherente en todas sus pantallas, para diseñar y desarrollar más rápido y para que el producto crezca sin desordenarse.

No es lo mismo que un manual de marca. El manual de marca define la identidad de la empresa (logotipo, colores, tipografías, tono) para cualquier soporte, del papel a las redes sociales. El design system traduce esa identidad a interfaces digitales y la convierte en piezas concretas que diseño y desarrollo reutilizan. Tampoco es solo una librería de componentes: la librería es una de sus partes.

Los design tokens son la base: las decisiones de diseño más pequeñas guardadas como variables con nombre. En lugar de repetir un código de color en cada pantalla, se define un «color principal», un «color de error», una escala de tamaños de texto o unos espaciados estándar. El grupo de la comunidad del W3C dedicado a los design tokens publicó en octubre de 2025 la primera versión estable de un formato común para intercambiarlos entre herramientas.

Sobre los tokens se construyen los componentes: botones, campos de formulario, tarjetas, tablas, menús o avisos, cada uno con sus estados (normal, al pasar el ratón, desactivado, con error). Y las guías de uso explican cuándo se usa cada componente, cómo se combinan, cómo se redactan los textos de la interfaz y qué contraste necesitan los colores para que todo el mundo pueda leerlos.

Un design system vive en dos sitios. En la herramienta de diseño, normalmente Figma, como una biblioteca de componentes y variables. Y en el código, como componentes de la interfaz y variables de estilo que el equipo de desarrollo usa al programar. Su valor real aparece cuando los dos coinciden: lo que se diseña en Figma es exactamente lo que ya está programado.

Los ejemplos más conocidos son públicos, como Material Design de Google, Carbon de IBM o Polaris de Shopify. Son sistemas enormes, pensados para muchos productos y equipos; una pyme no necesita algo de ese tamaño, pero sí el mismo principio.

El primer beneficio es la coherencia de marca. Sin un sistema, cada página nueva introduce pequeñas diferencias: un azul ligeramente distinto, un botón con otras esquinas, títulos de otro tamaño. Ninguna parece grave por separado, pero juntas hacen que la web transmita descuido, aunque el visitante no sepa explicar por qué. Con un sistema, todas las pantallas parecen de la misma empresa porque están hechas con las mismas piezas.

El segundo es la velocidad. Cuando los componentes ya existen, diseñar y desarrollar una página o una funcionalidad nueva consiste sobre todo en combinarlos, no en empezar de cero. Y el tercero es el mantenimiento: si la empresa cambia su color principal o ajusta su tipografía, el cambio se hace en un sitio y se aplica en todo el producto.

Evita la inconsistencia, que es el síntoma más visible. Evita también la deuda de diseño: la acumulación de variantes y excepciones que nadie decidió de forma consciente (cinco tipos de botón, tres grises para el mismo texto) y que encarecen cada cambio posterior, porque hay que revisar caso por caso.

Y evita la lentitud de las decisiones repetidas. Sin reglas escritas, cada pantalla reabre las mismas preguntas sobre cómo es un botón o qué tamaño tiene un título. Con un design system esas preguntas se responden una vez, incluida la accesibilidad: el contraste y los tamaños se revisan en el sistema y no en cada página.

Se asocia el design system a aplicaciones con cientos de pantallas, pero la web de una pyme también lo necesita, aunque sea en una versión pequeña. Es la diferencia entre una web que se ve profesional el día de su lanzamiento y una que lo sigue pareciendo después de dos años de cambios. Por eso forma parte de cualquier proyecto de diseño y desarrollo web bien planteado.

En Devyond partimos de una regla sencilla. Si el cliente ya tiene un design system, trabajamos con él. Si no lo tiene, lo creamos a partir de su branding: tomamos su identidad visual y la convertimos en un sistema con el que después se diseña y se desarrolla la web.

Ese sistema puede ser mínimo: la paleta de colores con sus usos, cómo son los botones y cómo son los títulos y los textos. Para una web corporativa puede bastar con eso y unos pocos componentes más. Lo que no hacemos nunca es prescindir de él, porque sin sistematizar el diseño no hay coherencia de marca y la web no proyecta bien.

El sistema crece cuando crece lo que sostiene. Ocurre cuando la web se convierte en un producto (una aplicación web, un panel de gestión o un portal de clientes con decenas de pantallas), cuando trabajan en él varios equipos o proveedores, cuando la empresa tiene varias marcas o productos que deben parecer de la misma familia, o cuando aparecen necesidades nuevas, como un modo oscuro.

En esos casos se añaden más componentes, patrones para situaciones complejas (tablas con filtros, formularios largos, estados vacíos y de error), documentación más detallada y un control de versiones para saber qué cambió y cuándo.

El primero es construir un design system enorme antes de tener producto: semanas de componentes que quizá nunca se usen. El segundo es lo contrario, no tener ninguno y confiar en que cada diseñador o desarrollador recuerde las reglas.

Partir de una librería de componentes existente es una opción legítima para ganar tiempo, siempre que se adapte a la marca. Una web que parece una plantilla genérica no diferencia a la empresa.

El punto de partida es la marca: logotipo, colores, tipografías y tono. Si la empresa no tiene una identidad visual definida, conviene resolverla antes o a la vez, porque el sistema la traduce, no la sustituye.

Después se definen los tokens: la paleta con usos concretos (principal, secundario, fondos, textos, éxito, aviso y error), la escala tipográfica y los espaciados. Sobre ellos se diseñan los componentes básicos con todos sus estados. Y, sobre todo, el sistema se aplica en pantallas reales y se ajusta: un design system se valida usándolo, no en una página de muestra.

Diseñamos en Figma y el sistema acompaña al prototipo desde el principio, como parte de nuestro servicio de diseño UX/UI. Como somos también el equipo que desarrolla, los componentes que se diseñan en Figma tienen su equivalente en el código, y lo que se aprueba en el diseño es lo que se construye.

El sistema llega también al gestor de contenidos. En una web a medida con un gestor organizado por bloques, el equipo del cliente crea páginas nuevas combinando secciones que ya respetan el sistema, de modo que la web puede crecer sin perder la coherencia.

Un design system no se termina: se mantiene. La regla práctica es que los cambios se hagan en el sistema y no en una página suelta. Si hace falta un componente nuevo, se diseña como parte del sistema, se documenta y se programa una vez, y desde ese momento está disponible para todo el producto.

Un design system reúne los tokens, los componentes y las guías de uso de un producto digital para que todas sus pantallas sean coherentes y se diseñen y desarrollen más rápido. No es exclusivo de las grandes empresas: puede ser mínimo, pero siempre conviene sistematizar el diseño, porque de eso depende que la marca se perciba igual en cada página.

Si tu web o tu aplicación ha crecido sin un sistema detrás, o vas a empezar una nueva, en nuestro servicio de diseño UX/UI creamos el design system a partir de tu marca y lo llevamos hasta el código.

Lo ideal es definirlo al principio del proyecto. Si la web ya existe, también se puede ordenar a partir de lo que hay: se hace inventario de colores y componentes, se eligen los que se quedan y se aplican de forma progresiva.