Unidad de contenido — Definiciones y Casos de estudio
Cuando hablamos de Design Systems, existe una tendencia a reducirlos a su manifestación más visible: una biblioteca de componentes reutilizables, un repositorio de código, un archivo de Figma con elementos prediseñados. Sin embargo, esta visión es profundamente limitada. Lamine y Cheng (2022), en su estudio empírico sobre la práctica de los design systems, proponen una definición más compleja: un design system es un "user interaction design and development approach" que requiere sintetizar conocimiento distribuido entre múltiples equipos y disciplinas para crear herramientas que soporten prácticas de creación, mantenimiento y uso.
Lo que descubrieron estos investigadores es que los design systems operan simultáneamente en tres niveles que raramente se hacen explícitos. El primero es el nivel técnico, el más evidente: el código que escribimos, los componentes que construimos, las variables de diseño que definimos, la documentación que generamos. Este es el nivel que vemos, con el que interactuamos directamente. Pero debajo de él existe un nivel epistemológico, que tiene que ver con el conocimiento compartido sobre qué constituye "buen diseño" en una organización particular. Este nivel no se documenta en archivos README; emerge de conversaciones, de decisiones tomadas en reuniones, de debates sobre si un botón debe tener bordes redondeados o cuadrados. Es el conjunto de criterios implícitos que los equipos han acordado —o asumido— sobre cómo debe verse y comportarse un producto.
El tercer nivel, quizás el más ignorado y el más determinante, es el nivel político. Este nivel define la estructura de poder que determina quién decide qué entra al sistema, cómo evoluciona, quién lo mantiene, quién tiene voz en los debates de diseño. Cuando un diseñador propone un nuevo componente, ¿quién aprueba su inclusión? Cuando dos equipos necesitan variantes incompatibles del mismo componente, ¿quién arbitra? Cuando el sistema necesita evolucionar, ¿quién decide la dirección?
La interacción entre estos tres niveles genera lo que podríamos llamar la primera tensión estructural de los design systems: para tener éxito, un sistema requiere simultáneamente rigidez técnica (para garantizar consistencia) y flexibilidad organizacional (para lograr adopción). Un sistema demasiado rígido sofoca la creatividad y genera resistencia; uno demasiado flexible pierde su razón de ser. La mayoría de los fracasos documentados en la literatura provienen de optimizar solo uno de estos niveles ignorando los otros dos. Se construye una arquitectura técnica impecable sin considerar la cultura organizacional que debe adoptarla, o se establece un modelo de gobernanza sin proveer las herramientas técnicas que lo hagan viable.
Es necesario establecer una distinción conceptual fundamental. Una biblioteca de componentes es esencialmente una colección: elementos disponibles para usar, como libros en un estante. Puedes tomarlos, usarlos, ignorarlos. No hay reglas inherentes sobre cómo deben combinarse o cuándo deben aplicarse. Es un recurso pasivo.
Un design system, en cambio, es un conjunto activo de reglas que gobiernan la composición de un producto. Tuite (2017) lo describe como un sistema normativo que incluye cuatro tipos de reglas. Primero, las reglas constitutivas, que definen qué elementos existen: qué variables de estilo son válidas, qué componentes están disponibles, qué cuenta como parte del sistema. Segundo, las reglas regulativas, que especifican cómo deben usarse estos elementos: cuándo usar un botón primario versus uno secundario, cómo combinar colores, qué patrones aplicar en qué contextos. Tercero, las reglas evolutivas, que gobiernan cómo el sistema cambia en el tiempo: procesos de gobernanza, versionado, deprecación de elementos obsoletos. Y cuarto, las reglas culturales, que explican por qué el sistema existe: qué valores de diseño defiende, qué problemas busca resolver, qué visión de la experiencia de usuario promueve.
Esta distinción tiene consecuencias prácticas profundas. Puedes tener una biblioteca sin sistema: componentes acumulados sin criterio unificador, una colección ad-hoc que creció orgánicamente. Pero no puedes tener un sistema sin biblioteca, porque las reglas necesitan manifestación concreta. Un sistema que solo existe en documentos o presentaciones pero no en código ejecutable no es un sistema, es una aspiración.
En el corazón de todo design system existe una paradoja que no puede resolverse, solo gestionarse. Ken Skistimas (2020), diseñador en GE, la formula con claridad desconcertante: "Strictly enforcing consistency might not result in the best experience for the end users and would certainly hurt adoption of the system". En otras palabras, el objetivo central del sistema —garantizar consistencia— puede ser exactamente lo que impide su éxito.
Esta paradoja se despliega en múltiples niveles. A nivel del diseñador individual, el sistema busca eliminar decisiones arbitrarias, crear límites claros, establecer convenciones. La promesa es que, al reducir el espacio de decisión, los diseñadores pueden enfocarse en problemas más importantes que el espaciado de un botón. Pero el diseño, por definición, requiere discernimiento situado: la capacidad de leer un contexto específico y tomar decisiones apropiadas para ese contexto. Un sistema muy restrictivo transforma diseñadores en ejecutores mecánicos de reglas, eliminando exactamente el tipo de juicio que hace valioso el trabajo de diseño. La pregunta que emerge es: ¿cómo mantener autonomía creativa dentro de restricciones sistémicas?
A nivel de producto, la paradoja se intensifica. Productos diferentes tienen necesidades legitimamente diferentes. Una aplicación médica para profesionales de la salud tiene requerimientos distintos a una red social para adolescentes, aunque ambos pertenezcan a la misma organización. Un sistema demasiado rígido, diseñado para un contexto específico, no sirve bien a contextos diversos. Pero un sistema demasiado flexible, que permite infinitas variaciones, pierde su razón de ser: si todo es configurable, si cualquier decisión puede ignorarse, ¿qué consistencia estamos garantizando?
Existe también una paradoja temporal que atraviesa todo el ciclo de vida del sistema. El sistema debe ser estable para que los equipos confíen en él y construyan sobre él. Si cambia constantemente, nadie invertirá en adoptarlo porque el costo de mantenerse actualizado es prohibitivo. Pero el sistema también debe ser evolutivo para no volverse obsoleto. Las tecnologías cambian, las necesidades de los usuarios evolucionan, las capacidades de las plataformas se expanden. Un sistema que no cambia se convierte en lastre. Cambiar poco genera rigidez; cambiar mucho genera inestabilidad. No hay punto medio estable.
La literatura profesional ha documentado distintos intentos de resolver —o más precisamente, de gestionar— esta paradoja a través de modelos de gobernanza. Cada modelo distribuye el poder de decisión de manera diferente, y cada uno tiene sus propios compromisos.
El modelo centralizado concentra el control en un equipo único que actúa como guardián del sistema. Este equipo decide qué entra, qué sale, cómo evoluciona el sistema. La ventaja es obvia: consistencia total, calidad controlada, visión coherente. Pero los problemas son igualmente evidentes. Este modelo crea un cuello de botella inevitable: todos los cambios deben pasar por el equipo central, lo que genera demoras, frustraciones, listas de espera interminables. Además, fomenta una dinámica de "nosotros versus ellos" donde los equipos de producto sienten que el sistema les está siendo impuesto desde arriba, sin consideración por sus necesidades específicas. La falta de ownership distribuido significa que cuando el equipo central está sobrecargado o carece de recursos, todo el sistema se estanca.
El modelo federado intenta resolver estos problemas distribuyendo la autoridad: múltiples equipos pueden contribuir al sistema bajo lineamientos compartidos. Esto genera ownership distribuido y mayor adaptabilidad; los equipos sienten que el sistema es suyo porque participan activamente en su construcción. Pero la coherencia se vuelve difícil de mantener. Cuando diez equipos diferentes pueden proponer componentes, ¿cómo garantizamos que todos sigan los mismos principios? Las decisiones se vuelven lentas porque requieren consenso entre múltiples stakeholders con intereses diversos.
El modelo mixto intenta un balance: componentes core centralizados (aquellos que son críticos para la identidad del sistema) y componentes periféricos federados (extensiones específicas por contexto). En teoría, esto combina lo mejor de ambos mundos: control donde importa, flexibilidad donde es necesaria. En la práctica, la complejidad de gestión es considerable, y los límites entre "core" y "periférico" son inevitablemente ambiguos y políticamente cargados.
Lo crucial es entender que ningún modelo resuelve la paradoja. Solo la gestionan. La elección del modelo no es técnica sino política: refleja cómo una organización decide distribuir el poder de decisión sobre el diseño de sus productos. Y esa elección tiene consecuencias profundas para quién puede participar, qué voces son escuchadas, y qué tipo de innovación es posible.
Existe una distinción que rara vez se hace explícita pero que determina el destino de todo design system: la diferencia entre un sistema vivo y un sistema muerto. La metáfora biológica es deliberada. Un sistema muerto es aquel que técnicamente existe —hay repositorio de código, hay documentación, quizás incluso hay un sitio web impresionante— pero que ha perdido su vitalidad. Los síntomas son reconocibles para cualquiera que haya trabajado en organizaciones grandes.
Primero, la documentación existe pero nadie la usa realmente. Los diseñadores tienen el link guardado en favoritos pero nunca lo abren. Los desarrolladores saben que existe pero trabajan copiando y pegando código de proyectos anteriores. Segundo, cuando el sistema se usa, se usa por obligación más que por convicción. Algún manager decidió que todos los proyectos deben usar el design system, así que los equipos lo adoptan formalmente pero lo hackean constantemente, agregando estilos custom, sobrescribiendo variables, creando workarounds para las limitaciones que encuentran. Tercero, el sistema no evoluciona con las necesidades reales del producto. Sigue documentando patrones que nadie usa mientras ignora problemas que todos enfrentan. Y cuarto, hay componentes que "nadie se atreve a tocar": código heredado tan complejo o frágil que modificarlo es considerado demasiado arriesgado.
Un sistema vivo, en contraste, exhibe características diferentes. Ramotion (2026) identifica tres señales vitales. Primero, existe un proceso deliberado de evolución: el sistema no solo agrega nuevos componentes, también depreca y elimina aquellos que han dejado de ser útiles. Como un organismo, metaboliza lo nuevo y elimina lo obsoleto. Segundo, hay feedback loops funcionando: canales explícitos y de bajo costo para que los usuarios del sistema reporten problemas, propongan mejoras, señalen inconsistencias, sin temor a represalias o burocracia prohibitiva. Y tercero, el equipo del sistema monitorea métricas de salud: qué porcentaje de pantallas están construidas exclusivamente con componentes del sistema, cuál es la tasa de override (cuánto los equipos modifican componentes en lugar de usarlos tal cual), cuál es la tasa de contribución (cuántos equipos proponen mejoras o nuevos componentes).
El indicador más crítico, sin embargo, es intangible: la confianza entre el sistema y los equipos que lo usan. Cuando esta confianza desaparece —cuando los equipos sienten que el sistema es un obstáculo más que una ayuda, cuando creen que sus necesidades son ignoradas, cuando experimentan que reportar problemas no lleva a ningún lado— entonces, como señala Ramotion, "even the most advanced architecture turns into just another library that no one wants to use". Un sistema sin confianza es un sistema muerto, independientemente de cuán sofisticada sea su arquitectura técnica.
La evolución de un design system enfrenta un problema estructural que no tiene solución técnica: cada cambio significativo potencialmente "rompe" todo lo que depende del sistema. La comunidad de desarrollo de software ha desarrollado convenciones de versionado semántico (major.minor.patch) que los design systems han adoptado, pero con implicaciones específicas al contexto de diseño.
Un cambio major es aquel que rompe compatibilidad: renombrar una variable de color que cientos de componentes usan, eliminar un componente que está presente en docenas de pantallas, cambiar fundamentalmente la API de un componente existente. Un cambio minor agrega nueva funcionalidad sin romper la existente: una nueva variante de botón, un nuevo estado de un componente, una nueva escala de espaciado que se suma a las existentes. Un cambio patch corrige errores o mejora documentación sin afectar funcionalidad.
El problema es que cada update mayor crea lo que podríamos llamar una "onda de ruptura": potencialmente rompe decenas o cientos de pantallas que dependen del sistema. Esto genera un conjunto de incentivos perversos que conspiran contra la salud del sistema. Los equipos de producto evitan actualizar porque el costo de migración es alto y el beneficio inmediato es bajo —si algo funciona, ¿para qué tocar? Así acumulan deuda técnica, quedándose en versiones antiguas del sistema. El equipo del sistema, viendo que nadie actualiza, evita hacer cambios necesarios porque romper compatibilidad es políticamente costoso y genera fricción. Así el sistema se estanca, manteniendo decisiones obsoletas solo por compatibilidad. Y eventualmente, algunos equipos frustrados crean versiones paralelas no oficiales del sistema, generando fragmentación.
Este no es un problema que pueda resolverse con mejor arquitectura de código o documentación más clara. Es fundamentalmente un problema de coordinación organizacional: requiere procesos claros de migración, documentación detallada de breaking changes, y crucialmente, recursos dedicados para actualización. Requiere que alguien, en algún nivel de la organización, tenga la autoridad y los recursos para decir: "Vamos a invertir tiempo actualizando, aunque no agregue funcionalidad visible". Sin ese soporte organizacional, la deuda técnica es inevitable.
La paradoja: Un design system es valioso solo si se usa ampliamente, pero la adopción amplia es el mayor desafío.
Razones estructurales del rechazo:
El círculo vicioso: Baja adopción → Sistema no mejora → Equipos lo evitan más → Baja adopción
Solución parcial: Soporte C-level explícito. Delivery Hero logró adopción mostrando a stakeholders que el sistema reducía tiempo de entrega en 57% con cero deuda técnica (Jabeen, citada en UXPin, 2023). El design system requiere hacer visible su valor en términos del negocio, no solo en términos de diseño.
Tensión irresoluble: La documentación debe ser:
No existe un "estándar de la industria" para documentación de design systems. Cada organización debe inventar su propio formato. Esto genera alto costo cognitivo: diseñadores/desarrolladores que trabajan con múltiples sistemas deben aprender múltiples "idiomas" de documentación.
En organizaciones grandes, el design system debe servir:
El dilema:
Solución parcial observada (Lullabot, 2024): Sistemas con "capas de abstracción":
Aún así, la documentación de qué usar cuándo se vuelve exponencialmente compleja.
Los design systems no son puramente técnicos ni puramente sociales. Son sistemas socio-técnicos donde:
Esta perspectiva viene de la teoría de sistemas organizacionales aplicada a diseño (Wheatley, 2006; Morgan, 2015).
Los design systems exhiben propiedades de sistemas complejos:
Emergencia: El comportamiento del sistema no es predecible desde sus componentes individuales. Una librería de 100 componentes bien diseñados puede generar productos inconsistentes si la cultura organizacional no acompaña.
Retroalimentación: Loops positivos (más uso → más mejoras → más uso) y negativos (rigidez → menos adopción → menos recursos → más rigidez) coexisten.
Adaptación: El sistema debe evolucionar con su entorno (tecnologías, necesidades de usuarios, cultura organizacional). Un sistema que no cambia, muere.
Auto-organización: En sistemas federados, emergen prácticas y convenciones que no fueron explícitamente diseñadas por el equipo core.
El Diseño Atómico (Frost, 2017) y los Design Systems no son lo mismo, pero están íntimamente relacionados:
La metáfora química de Frost (átomos → moléculas → organismos → templates → páginas) proporciona un vocabulario jerárquico para pensar cómo se construyen interfaces desde sus elementos más básicos. Pero Frost mismo reconoce que esta metodología debe insertarse en un sistema mayor que incluya cultura organizacional, principios de diseño y procesos de trabajo (Frost, 2017, capítulo sobre "Design Systems").
Diseño Atómico responde:
Design System responde:
En la práctica: Muchos design systems exitosos (como Material Design) usan internamente lógicas similares al Diseño Atómico para organizar componentes, pero su éxito no depende de la metodología de construcción sino de:
El concepto de Style Palette (Tuite, 2017) —que definieron como el conjunto de valores globales para todas las propiedades CSS customizables— es exactamente el nivel de "átomos visuales" del Diseño Atómico:
La diferencia es que el Style Palette enfatiza que estos valores no deben inventarse durante el diseño de componentes, sino predefinirse antes. Esta disciplina (no crear valores nuevos ad-hoc) es lo que distingue trabajar con un sistema de trabajar sin él.
Tuite es explícito: "When we're finished, not a single style should exist in our product that has not been predefined in our global style palette" (2017). Esta es una regla del sistema, no solo una práctica del diseño atómico.
Frost mismo reconoce que la metáfora tiene límites:
Problema 1: La jerarquía no siempre es clara. ¿Un componente de navegación complejo con sub-menús es un organismo o un template? La metáfora química sugiere jerarquías claras que no siempre existen en interfaces complejas.
Problema 2: No aborda gobernanza. El Diseño Atómico no dice nada sobre quién decide si un nuevo "átomo" se agrega al sistema, o cómo se resuelven conflictos cuando dos equipos necesitan versiones incompatibles de una "molécula".
Problema 3: No considera evolución temporal. La metodología se enfoca en construcción inicial, no en mantenimiento a largo plazo. ¿Qué pasa cuando un "átomo" debe cambiar después de que existen 50 "moléculas" que dependen de él?
Por eso, Diseño Atómico es una herramienta útil dentro de un Design System, pero no es suficiente para construir un Design System completo. Se necesitan además: principios de diseño, modelo de gobernanza, procesos de versionado, métricas de adopción y documentación organizacional.
En lugar de enseñar design systems como "conjunto de mejores prácticas", propongo abordarlos como objetos de estudio crítico:
Material Design es probablemente el design system más influyente de la última década. Su éxito no radica solo en su calidad estética, sino en decisiones estructurales deliberadas.
Carbon es el design system open source de IBM, lanzado en 2017. Representa un enfoque diferente a Material: menos metafórico, más pragmático.
Enfoque enterprise: Carbon está diseñado para aplicaciones empresariales complejas (dashboards, herramientas de administración, productos SaaS), no para consumer apps. Esto se refleja en:
Sistema de theming robusto: Carbon fue diseñado desde el inicio para soportar múltiples "themes" (light, dark, high contrast) sin reconstruir componentes. Material Design incorporó esto recién en Material 3.
Accesibilidad como restricción de diseño: Todos los componentes deben cumplir WCAG 2.1 AA como mínimo. Esto no es aspiracional, es requisito de aceptación.
| Aspecto | Material Design | IBM Carbon |
|---|---|---|
| Metáfora central | Material físico | Ninguna (pragmático) |
| Audiencia primaria | Consumer apps, mobile-first | Enterprise apps, desktop-first |
| Estética | Expresiva, colorida | Neutral, funcional |
| Accesibilidad | Recomendada | Obligatoria (WCAG 2.1 AA+) |
| Gobernanza | Centralizada (Google) | Federada (IBM + comunidad) |
| Diferenciación | Difícil (todo "se ve a Material") | Más flexible para branding |
1. El sistema debe resolver problemas reales del contexto:
2. La documentación es tan importante como el código:
3. Open source ≠ falta de control:
4. Multi-plataforma es requisito, no lujo:
5. La evolución es inevitable, el versionado es esencial:
Tesis central: Un design system debe comenzar definiendo un Style Palette exhaustivo ANTES de diseñar componentes. El Style Palette contiene todos los valores posibles para cada propiedad CSS que acepta valores custom.
PASO 1: Definir valores globales
Para cada categoría, crear escala completa de valores:
Color:
Typography:
Spacing:
Otros valores:
PASO 2: Implementar como CSS Custom Properties
:root {
/* Colors */
--color-primary-500: #0066FF;
--color-gray-100: #F8F9FA;
--color-gray-900: #212529;
/* Typography */
--font-size-sm: 0.875rem;
--font-size-base: 1rem;
--font-size-lg: 1.25rem;
/* Spacing */
--space-2: 0.5rem;
--space-4: 1rem;
--space-6: 1.5rem;
/* Shadows */
--shadow-sm: 0 1px 3px rgba(0,0,0,0.12);
--shadow-md: 0 4px 6px rgba(0,0,0,0.16);
}PASO 3: Principio de "No New Styles"
Una vez definido el Style Palette, ningún componente debe introducir valores nuevos. Solo mapear valores existentes.
Correcto:
.button {
padding: var(--space-4) var(--space-6);
background: var(--color-primary-500);
border-radius: 4px;
box-shadow: var(--shadow-sm);
}Incorrecto (introduce valor ad-hoc):
.button {
padding: 14px 20px; /* ← No está en el spacing scale */
background: #0055CC; /* ← No está en la paleta */
}PASO 4: Documentar decisiones
Cada valor debe tener justificación:
--color-primary-500
actualiza todo el sistemaEste enfoque es dogmático. Habrá casos excepcionales donde necesites "romper la escala". La clave es:
Contexto: Curso práctico de 7 horas construyendo un design system para un sitio web espacial (space tourism). Enfoque en implementación técnica real.
CSS Reset personalizado:
box-sizing: border-box globalCustom Properties para todo el sistema:
:root {
/* Colors con nomenclatura semántica */
--clr-dark: 230 35% 7%;
--clr-light: 231 77% 90%;
--clr-white: 0 0% 100%;
/* Typography: familias y escalas */
--ff-serif: "Bellefair", serif;
--ff-sans: "Barlow Condensed", sans-serif;
--fs-900: clamp(5rem, 8vw + 1rem, 9.375rem);
--fs-800: 3.5rem;
--fs-700: 1.5rem;
/* ... */
}Nota: Usa valores HSL sin hsl() para poder manipularlos (ej:
hsl(var(--clr-dark) / 0.5) para transparencia).
Utility classes (enfoque Tailwind-like):
.bg-dark { background-color: hsl(var(--clr-dark)); }
.text-white { color: hsl(var(--clr-white)); }
.fs-900 { font-size: var(--fs-900); }
.uppercase { text-transform: uppercase; }Debate: ¿utility classes vs. componentes semánticos? Powell argumenta que para design systems, utilities dan máxima flexibilidad sin crear CSS específico por componente.
Tipografía responsiva con clamp():
--fs-900: clamp(5rem, 8vw + 1rem, 9.375rem);Esto crea tamaños fluidos: mínimo 5rem, máximo 9.375rem, escalando con viewport.
Spacing consistente:
.flow > * + * para espaciado vertical
entre elementos--flow-space modificable por contexto
Componentes con variantes:
Ejemplo botón:
.button {
/* Estilos base */
display: inline-grid;
padding: 2em;
border-radius: 50%;
/* ... */
}
.button[data-variant="large"] {
font-size: 2rem;
padding: 3em;
}Usa data attributes para variantes en lugar de clases adicionales (más semántico).
Grid container responsivo:
.grid-container {
display: grid;
column-gap: var(--container-gap, 2rem);
grid-template-columns:
minmax(2rem, 1fr)
repeat(2, minmax(0, 40rem))
minmax(2rem, 1fr);
}
/* Uso: elementos se colocan en columnas nombradas */
.grid-container > * {
grid-column: 2; /* contenido principal */
}No es "add-on", está integrado desde el inicio:
Skip to content link:
.skip-to-content {
position: absolute;
z-index: 9999;
background: hsl(var(--clr-white));
padding: 1em 2em;
transform: translateY(-100%);
transition: transform 250ms ease-in;
}
.skip-to-content:focus {
transform: translateY(0);
}Tabs con ARIA:
<div role="tablist" aria-label="crew member list">
<button role="tab" aria-selected="true">Commander</button>
<button role="tab" aria-selected="false">Specialist</button>
</div>
<div role="tabpanel"><!-- contenido --></div>Estilos responden a aria-selected:
[role="tab"][aria-selected="true"] {
color: hsl(var(--clr-white));
}Focus management: Estados de focus visibles y estilizados consistentemente.
Navegación responsiva con JavaScript mínimo:
Tabs funcionales con JavaScript:
@media para desktop<nav>, <button>, no
<div> clickeable)Ambos coinciden en principio fundamental: definir sistema de valores primero, construir componentes después.
Frost, B. (2017). Atomic Design. Pittsburgh: Brad Frost. Disponible en: https://atomicdesign.bradfrost.com/
Lamine, Y., & Cheng, J. (2022). Understanding and Supporting the Design Systems Practice. En Proceedings of the 2022 CHI Conference on Human Factors in Computing Systems. arXiv:2205.10713
Lullabot (2024). The Unique Challenges of Design Systems at Scale. Disponible en: https://www.lullabot.com/articles/unique-challenges-design-systems-scale
Morgan, G. (2015). Images of Organization (edición actualizada). Thousand Oaks: SAGE Publications.
Powell, K. (2022). How to Create and Implement a Design System with CSS. freeCodeCamp. Disponible en: https://www.freecodecamp.org/news/how-to-create-and-implement-a-design-system-with-css/
Ramotion (2026). Design System Guide. Chapter 8: Maintenance and Evolution. Disponible en: https://www.ramotion.com/blog/design-system-guide-chapter-8-maintenance-and-evolution/
Skistimas, K. (2020). Balancing Flexibility and Consistency in Design Systems. GE Design/Medium. Disponible en: https://medium.com/ge-design/balancing-flexibility-and-consistency-in-design-systems-c24cd0a9da16
Tuite, C. (2017). How to construct a design system. freeCodeCamp. Disponible en: https://www.freecodecamp.org/news/how-to-construct-a-design-system-864adbf2a117/
UXPin (2023). 5 Key Design System Challenges and Lessons Learned. Disponible en: https://www.uxpin.com/studio/blog/key-design-system-challenges/
Wheatley, M. (2006). Leadership and the New Science: Discovering Order in a Chaotic World. San Francisco: Berrett-Koehler Publishers.