Design System, Foundations, Variables y Tokens
- 1 Foundations o Styles
- 2 Component Library
- 3 Design System
- 3.1 Beneficios
- 4 Design Tokens
- 4.1 Anatomía de los Design Tokens
- 4.2 Beneficios de los tokens
- 4.3 Organización
- 4.3.1 Primitive Tokens
- 4.3.2 Semantic Tokens
- 4.3.3 Component-specific Tokens
- 4.3.4 Ejemplo
- 5 Local Styles
- 6 Documentación del Design System
- 7 Exportar nuestro Design System a un repositorio web
- 8 Plugins
- 9 Recursos adicionales
CURSO: Design Systems - Espacio UX
Elaboró: María José González
Fecha de elaboración: 28 oct 2025
Foundations o Styles
Los style guides o foundations son como el núcleo del design system, porque apartir de las foundations se van a crear todas las demás. Es un conjunto de estándares que definen la apariencia de los elementos y el tono general. Se centran en el lenguaje visual de un producto: cómo deben verse, comportarse y sentirse las cosas.
Normalmente incluye:
- Colores,
- Tipografía
- Iconos
- Espaciados
- Brand guidelines.
Por qué son importantes:
- Aseguran consistencia visual y funcional en todo el producto.
- Facilitan la colaboración entre diseño y desarrollo.
- Hacen que los tokens y componentes sean coherentes entre sí.
- Permiten escalar el diseño sin perder identidad.

Component Library
Estas contienen elementos de interfaz de usuario predefinidos y reutilizables, y sirven como recurso integral para que tanto diseñadores como desarrolladores aprendan e implementen elementos de interfaz de usuario específicos. Además de que puede incluir componentes individuales, diseños y plantillas y se centran en cómo deben comportarse los activos en el producto.
Incluyen:
- Nombre del componente: un nombre de componente de interfaz de usuario específico y único, para evitar malentendidos entre diseñadores y desarrolladores.
- Descripción: una explicación clara de qué es este elemento y cómo se utiliza normalmente, acompañada ocasionalmente de recomendaciones y advertencias para mayor contexto y claridad.
- Atributos: variables o ajustes que se pueden realizar para personalizar o adaptar el componente a necesidades específicas (por ejemplo, color, tamaño, forma, texto).
- Estado: valores predeterminados recomendados y los consiguientes cambios en la apariencia

Design System
Un Design System es todo el ecosistema del producto digital. Reúne los principios, reglas, procesos y recursos que garantizan coherencia y eficiencia en el diseño y desarrollo. No se trata de una entrega única, sino de un conjunto de estándares, componentes y patrones reutilizables que evolucionan constantemente junto con el producto, la visión y los valores de la organización.
Incluye:
- Aspectos técnicos: especificaciones de desarrollo y compatibilidad.
- Documentación: guías de uso, convenciones, buenas prácticas.
- Design Tokens: variables que definen colores, tipografías, espaciados, etc.
- Procesos: flujos de trabajo, revisiones y mantenimientos.
- Nomenclatura: sistema de nombres coherente para los elementos.
¿Cómo se conforma?

Beneficios
Los design systems, cuando se implementan correctamente, pueden proporcionar muchos beneficios a un equipo de diseño:
Maximiza la efectividad: La principal ventaja de los design systems es su capacidad para replicar diseños con rapidez mediante el uso de componentes y elementos prediseñados. Los equipos pueden reutilizar los mismos elementos una y otra vez, lo que reduce recursos y el riesgo de inconsistencias no deseadas. Además de que acelera el trabajo, se reduce el tiempo en tareas repetitivas y ahorra muchos costos.
Más tiempos para cosas importantes: Al crear y reutilizar ciertos elementos y componentes, los diseñadores pueden dedicar menos tiempo a perfeccionar el aspecto visual y más a resolver problemas más complejos.
Se crea un lenguaje unificado: Proporciona a los equipos una visión y lenguaje compartido que lleva a una mejor comprensión y proyectos más consistentes.
Crea una coherencia visual: Los design systems proporcionan una única fuente de componentes, patrones y estilos, unificando las experiencias para que sean visualmente coherentes y parezcan formar parte del mismo ecosistema. Además, cualquier cambio de imagen o rediseño visual importante puede gestionarse a gran escala mediante el sistema de diseño.
Design Tokens
Son un método para gestionar propiedades y valores de un diseño dentro de un Design System. Cada token almacena una pieza de información con valores que representan decisiones de diseño de forma centralizada y reutilizable. Estos valores incluyen elementos de la interfaz y se aplican en todo el producto: web, móvil o aplicaciones. Para facilitar su uso, cada token recibe un nombre único y fácil de recordar.
Puedes pensar en los tokens como las unidades más pequeñas del diseño, los “bloques de construcción” que permiten crear componentes y elementos más grandes de manera consistente. En términos de Atomic Design, funcionan como subátomos que ayudan a mantener la uniformidad visual y agilizan el desarrollo de la interfaz en distintas plataformas.
Piezas que podemos tokenizar:
- Colores: primarios, secundarios, de fondo, texto, botones, estados (hover, activo).
- Tipografía: familias de fuentes, tamaños, pesos, estilos.
- Espaciado: márgenes, padding, gutters.
- Bordes y contornos: radios, grosor.
- Sombras y elevaciones: box shadows, sombras de texto, profundidad visual.
- Opacidades y transparencias: niveles de transparencia para colores, fondos u overlays.
- Duraciones y animaciones: tiempos de transición, velocidad, easing.
- Íconos y assets: rutas o referencias a iconos, ilustraciones o imágenes usadas en el sistema.
Anatomía de los Design Tokens
Los tokens están diseñados para ser flexibles y consistentes, permitiendo un lenguaje común entre diseño y desarrollo. Cada token incluye:
- Valor: el dato que representa - Ejemplo:
#FBD302o16px. - Token: identificador único del token. - Ejemplo:
yellow/400,Border/Hover,spacing-small. - Componente: indica a qué propiedad de diseño pertenece: Ejemplo:
color,font-size,spacing.



Beneficios de los tokens
Con los token de diseño conseguimos:
- Uso del mismo lenguaje. Mejora la comunicación entre equipos.
- Archivos sincronizados. Una única fuente oficial, consistencia en todas las plataformas.
- Foundations solidas. Un sistema de diseño estable mejora los productos.
- Mantenimiento fácil. Edita en un solo lugar, actualiza todo a la vez.
- Consistencia de producto. Crear nuevos productos, mantener la uniformidad y gestionar una marca es cada vez más accesible, rápido y económico con un sistema de jerarquía visual.
- Menos fricción entre diseño y desarrollo. Significa que se gastan menos recursos, como tiempo y dinero.
Notas rápidas:
- Utilizar Design Tokens forma parte de una metodología que es completamente agnóstica: no importa con qué lenguaje se programe. Se almacenan en un JSON o YAML y puede emplearse en cualquier proyecto.
- JSON: (JavaScript Object Notation), es un formato ligero para almacenar y transportar datos, muy usado para enviar información entre un servidor y una aplicación web, o entre diferentes sistemas.
Organización
Primitive Tokens
Definen los valores puros como colores, tamaños o tipografías, sin contexto de uso. Aquí no se indica para qué se usa un color o un tamaño específico; solo se definen los valores brutos, la materia prima del sistema visual. Por ejemplo, los tokens primitivos de color incluirían todos los colores utilizados en tu producto. Mientras que los tokens primitivos de espaciado, incluirían todos los valores de padding, margin y espaciados. Son sólo de referencia y proporcionan la base para otros tokens, por lo que NO los aplicarías directamente a los elementos de tu diseño.
Ejemplo:
#FBD302o16px.
➡️ Únicamente comunican el “qué”.
Semantic Tokens
Nos dan contexto, significado o intención sobre cómo, propósito y dónde debe de utilizarse el token. Usan los Primitive Tokens como base, pero los renombran según su función en la interfaz.
Por ejemplo el tokenbackground/accenthace referencia a un token primitivo blue/500 adquiere el valor que se le asigne.
Si mañana cambias el color azul por otro, no necesitas modificar cada componente; solo actualizas el Semantic Token. Estos tokens viven dentro de cada componente (botón, tarjeta, input...) y conectan el diseño global con la implementación.
➡️ Comunican el “cómo”.
Component-specific Tokens
Estos tokens se aplican directamente a los componentes, usando los Semantic Tokens para definir sus estilos. Permiten que cada componente tenga sus propios valores, manteniendo consistencia con el sistema global. Son más detallados y utilizados en su mayoría en design systems mucho más grandes, entonces no siempre pueden utilizarse.
➡️ Comunican el “dónde”.
Ejemplo

Primitive Token: Con nuestro valor hexadecimal creamos un primitive token, en este caso blue/500. Si cambias de color este token, se propaga a todos los demás tokens a los que esté referenciado.
Semantic Token: Este color lo podemos referir a distintos elementos, escenarios o componentes, como puede ser border/hover,background/accent ,icon/primary.
Component tokens: Reciben el valor del token semántico para aplicarlo a un componente específico (e.g., Serch/active, button/primary).
¿Por qué no usamos Blue/500 en todo y listo?
Si en algún momento es necesario cambiar solo el valor específico de alguno de los componentes, por ejemplo el border/hoverde los inputs, sería mucho más trabajo y tiempo. Por eso teniendo el Semantic Token, lo único que sería necesario hacer en este caso es referirlo a un color diferente, como en este caso es el naranja. Así se agiliza mucho más los cambios en los componentes o en el design system.

Primitive Token: Agregamos un nuevo primitive token, como sería el orange/500.
Semantic Token: Si queremos cambiar el solo el color de losborder/hoverya solo referenciamos este semantic token a nuestro nuevo primitive token (orange/500).
Component tokens: Automáticamente los componentes o elementos en los que utilizamos el semantic token como Serch/active, se cambiará a este nuevo color.
Local Styles
Son estilos que se crean dentro de un archivo de Figma y que representan propiedades de diseño como colores, tipografías, sombras o grids. Cada estilo se aplica a elementos individuales o grupos de elementos dentro del archivo, permitiendo mantener consistencia visual de forma rápida. Por ejemplo, puedes definir un color primario Blue/500, un estilo de texto Heading 1 o una sombra específica, y luego aplicarlos a botones, títulos o tarjetas dentro del mismo archivo.
A diferencia de los tokens, en styles si podemos agregar valores compuestos, como son los gradientes de color y valores múltiples rellenos o varios efectos de sombra.
Diferencias entre Local Styles y Design Tokens:
- Tokens son variables abstractas que representan valores de diseño puros (colores, tamaños, tipografías, espacios) y pueden ser reutilizadas a través de múltiples archivos, componentes e incluso exportadas a código. Por ejemplo, un token
color-primarypuede mapearse a un botón, un icono o un fondo en distintos contextos sin cambiar su valor base. - Local Styles son la implementación concreta de un valor en Figma; no abstraen el valor, sino que lo aplican directamente a un objeto.

Variables
Las variables permiten almacenar valores reutilizables dentro de un proyecto, facilitando la consistencia y el mantenimiento del diseño. A diferencia de los estilos locales, las variables pueden referenciar otras variables, lo que permite crear estructuras más complejas y escalables dentro del sistema de diseño.
Además, admiten múltiples modos o themes (como light y dark mode), lo que simplifica la adaptación visual del producto a diferentes contextos.
Una buena práctica es utilizar una nomenclatura intuitiva y semántica, de modo que cada variable refleje claramente su propósito o función dentro de la interfaz.
En comparación con los estilos, las variables ofrecen mayor flexibilidad y organización, ya que pueden aplicarse a distintos elementos y facilitar el handoff con desarrollo gracias a su sintaxis basada en código, lo que las convierte en una herramienta más potente para equipos multidisciplinarios.

Tipos de Variables
Cuando creamos las variables tenemos 4 tipos:
- Colores
- Números
- Cadenas de texto (string)
- Boolean

Cuándo crear una nueva colección
Podemos crear tantas colecciones de variables como queramos. El momento para crear colecciones separadas puede depender de las necesidades de tu sistema, proyecto, equipo, etc. Aunque una colección de variables agrupa variables que comparten un mismo contexto o propósito.
Crear una nueva colección tiene sentido cuando:
-
Cambia el contexto de uso
- Por ejemplo, una colección para Design Tokens (colores, espaciados, tipografía) y otra para Componentes (botones, inputs, tarjetas). Así evitas mezclar valores base con variables de aplicación.
- Otra separación común, es hacerlo para diferenciar entre un conjunto de colores de marca y los colores del sistema.
-
Necesitas diferentes themes
- Si tu proyecto incluye modo claro/oscuro, brands distintas o productos dentro de un mismo sistema, cada combinación puede tener su propia colección (por ejemplo: “App Light”, “App Dark”, “Marketing Site”).
-
Separación por plataforma o tecnología
- Cuando el mismo sistema se implementa en distintas plataformas (iOS, Android, Web), puedes crear una colección por plataforma para mantener coherencia sin duplicar trabajo.
-
Organización por equipo o flujo de trabajo
- Si varios equipos colaboran (UI, Dev, Marketing), cada uno puede tener su propia colección para no interferir con las variables del resto.
-
Necesitas gestionar permisos o versiones independientes
- Crear una nueva colección permite publicar, actualizar o compartir variables sin afectar otras áreas del sistema.
En resumen
Una buena estructura de colecciones no se nota hasta que todo crece.
- Divide por tipo (color, spacing, etc.)
- Separá primitivo de semántico
- Agrupá por modo o tema si lo necesitás
- Hazlo escalable desde el día uno
Crear colecciones bien pensadas es como diseñar buenos cimientos: No se ven, pero sostienen todo.
Design Token vs Variable
Pero, ¿cuál es la diferencia entre un design token y una variable?
-
Design Tokens (El Concepto Universal):
- Son el lenguaje universal o la metodología para estandarizar las decisiones de diseño (colores, espaciado, tipografía).
- Actúan como la fuente única de verdad entre el diseño y el código.
- Son independientes de la herramienta; se definen y luego se exportan como archivos de datos (JSON, CSS) para ser consumidos en cualquier plataforma (Figma, Sketch, React, iOS, etc.).
-
Figma Local Variables (El Método de Implementación en la Herramienta):
- Son la herramienta nativa que Figma ofrece para crear, organizar y aplicar esos Design Tokens dentro del software.
- Son el método actual para implementar la filosofía de los Design Tokens de forma eficiente en Figma, permitiendo lógica avanzada
-
En resumen:
-
Los Tokens son la especificación o la idea.
-
Las Variables (en Figma) son la implementación o la caja de herramientas para manejar esas especificaciones dentro del archivo de diseño.
Tabla comparativa: Local Styles vs Variables vs Design Tokens
| Aspecto | Local Styles | Variables | Design Tokens |
|---|---|---|---|
| Definición | Son valores guardados localmente (como colores, tipografía o efectos) que se aplican directamente a los elementos del diseño. | Son contenedores de valores reutilizables que pueden referenciar otras variables y adaptarse a distintos modos o contextos. | Son la representación estandarizada en código de los valores del sistema de diseño (colores, espaciados, tipografías, etc.). |
| Estructura | Simples, no pueden hacer referencia entre sí. | Pueden ser jerárquicas o anidadas, ya que una variable puede depender de otra. | Basadas en JSON u otros formatos legibles por código, organizadas en niveles (primitive, semantic, component). |
| Modos / Themes | No soportan modos. Cada estilo es único. | Soportan múltiples modos o temas (dark/light, brand A/B, etc.). | Se pueden generar múltiples tokens según los modos definidos en Figma. |
| Reutilización | Reutilizables pero limitados a un tipo de estilo (color, text, effect). | Reutilizables y más flexibles, aplicables a distintos tipos de propiedades. | Reutilizables a nivel de desarrollo y diseño, garantizan consistencia entre ambos. |
| Relación con código | No tienen conexión directa con código; se exportan manualmente. | Tienen sintaxis similar al código, lo que mejora el handoff con desarrollo. | Son el puente directo con el código, ya que pueden exportarse a repositorios o librerías de desarrollo. |
| Organización | Se agrupan por tipo (color, text, effect, grid). | Se agrupan en colecciones y grupos personalizados. | Se agrupan en niveles de abstracción dentro del sistema (foundations, semantic, component). |
| Ventajas | Fáciles de usar, ideales para proyectos pequeños. | Mayor flexibilidad, escalabilidad y control sobre temas. | Total coherencia entre diseño y código; base de los Design Systems maduros. |
| Limitaciones | No admiten referencias ni temas. | No tienen exportación directa como tokens sin plugin o API. | Requieren configuración técnica y mantenimiento entre diseño y desarrollo. |
Documentación del Design System
¿Por qué documentar?
Debemos asegurarnos de que todo esté documentado para que otras persoans sepan cómo usar el sistema. Debemos documentar todo, recordando que no estámos diseñando para nosotros nada más, sino para un grupo de personas. También es necesario crear un proceso para actualizar y mantener el design system a lo largo del tiempo.
¿Qué incluye?
Incluye entre otras cosas, la nomenclatura de componentes y sus descripciones de cómo se comportan, specs, estados, variantes, etc.
También se pueden incluir ejemplos del uso correcto e incorrecto de un patrón.
También podemos anticiparnos
La documentación efectiva anticipa a las necesidades de los usuarios.
Por ejemplo, debemos documentar y diseñar los posibles caminos que el usuario pueda tomar como: mensajes de error, links (a dónde llevan), alertas, pantallas emergentes de contenido, de carga, estados, etc.
¿Dónde ubicar la documentación?
Dónde se encuentra la documentación y qué tan fácil es encontrarla, puede afectar su efectividad.
Se puede encontrar en:
- Sitios web dedicados (para productos masivos, un ejemplo sería Material Design)
- Figma (si es un proyecto pequeño)
- En ambas, que tengan tanto un sitio web y por ahí, puedan acceder al figma.
Es mucho mejor comunicar con historias y no con matices
Es importante presentarlo de una forma la documentación accesible para que todos en el equipo lo entiendan.



Exportar nuestro Design System a un repositorio web
Para almacenar nuestros componentes, variantes, design tokens etc. Un sitio web para almacenar todo nuestro design system y que a su vez se actualice al mismo tiempo.
Exportar JSON al Dev Team
Exportar JSON significa sacar los design tokens (colores, tipografías, espaciados, sombras, etc.) y/o otras definiciones de diseño desde la herramienta de diseño o de documentación del design system y generar archivos JSON que el equipo de desarrollo pueda consumir automáticamente en su código (web, iOS, Android, paquetes npm, etc.). Esto evita hand-offs manuales, mantiene una sola fuente de verdad y reduce errores de sincronía entre diseño y código. Utilizando un plugin puedes actualizar desde figma, y se actualiza también el repositorio web.
Plugins
Tokens Studio: Te permite organizar tus tokens, importar y exportar a otros archivos o a JSON file.
Styles to Variables: Ya no añades manualmente todos tus estilos en su lugar, usa este plugin para dedicar más tiempo a jugar con alias, modos ya actualizar los componentes de tu sistema de diseño.
https://www.figma.com/community/plugin/1253669344925342575/styles-to-variables
Color shades: Una forma fácil de crear gama de colores primitivos para tus proyectos.
https://www.figma.com/es-la/comunidad/plugin/929607085343688745/color-shades
Recursos adicionales
https://www.designsystems.com/https://m3.material.io/foundationshttps://www.youtube.com/watch?v=m7kUGmNkPoc&t=1196s&pp=ugMGCgJlcxABugUEEgJlc8oFBnRva2Vuc9gHAQ%3D%3Dhttps://uxdesign.cc/naming-design-tokens-347f630ba4f9https://gestalt.pinterest.systems