Llevas meses añadiendo pantallas al producto. El equipo de diseño es distinto al que empezó el proyecto. Los botones no tienen el mismo radio en todos los flujos. El color primario varía según quién lo implementó. Y cada nueva funcionalidad tarda el doble de lo que debería porque nadie sabe exactamente qué componentes ya existen y cuáles hay que hacer desde cero.
Lo que describes no es un problema de disciplina del equipo. Es un problema de infraestructura. Y la infraestructura que falta tiene nombre: sistema de diseño.
En este artículo: qué es realmente un sistema de diseño —más allá de la definición de manual—, qué no es, y cómo saber si tu proyecto está en el punto donde tiene sentido plantear uno.
Qué es un sistema de diseño y qué no es
Un sistema de diseño es el conjunto de decisiones de diseño documentadas y los componentes de interfaz construidos a partir de ellas, diseñados para ser reutilizados de forma consistente en un producto digital.
No es solo una librería de componentes en Figma. No es un moodboard. No es la guía de marca. Un sistema de diseño vive en dos capas al mismo tiempo: el diseño (Figma, Sketch, lo que uses) y el código (los componentes reales implementados). Si solo existe en una de las dos, es un prototipo de sistema, no el sistema.
Cuando en nuestro trabajo de diseño UX/UI planteamos un sistema de diseño, siempre lo definimos con el equipo de desarrollo desde el principio. Un sistema que solo el diseñador conoce no escala. Un sistema que no tiene tokens conectados al código es decorativo.
Los tres componentes reales de un sistema de diseño
Los tokens son las decisiones atómicas: el color primario, el radio de borde de los botones, la escala tipográfica. Los componentes son la implementación de esas decisiones en piezas reutilizables. La documentación es lo que permite que un desarrollador nuevo entienda el sistema sin necesitar que el diseñador le explique nada.
Sin los tres, tienes partes de un sistema. Con los tres, tienes un sistema.
Cuándo un sistema de diseño tiene sentido y cuándo no
La tentación habitual es pensar que todo proyecto necesita un sistema de diseño. No es así. Un sistema tiene coste de construcción y coste de mantenimiento. Si el proyecto no lo justifica, estás invirtiendo en infraestructura que nadie va a usar.
| Señal | Sistema necesario | Puede esperar |
|---|---|---|
| Tamaño del producto | Múltiples flujos, secciones y tipos de página | Web informativa de 5-10 páginas |
| Equipo | 2+ diseñadores o 2+ desarrolladores frontend | Una sola persona diseña y desarrolla |
| Frecuencia de cambios | Iteraciones continuas, nuevas funciones cada mes | Proyecto estático que no va a evolucionar |
| Consistencia actual | Inconsistencias visibles entre secciones | El producto es reciente y coherente |
| Horizonte del producto | Producto propio con roadmap a 2+ años | MVP en validación, el modelo puede cambiar |
| ¿Cuándo plantearlo? | Antes del segundo sprint de diseño, no después | Cuando el producto esté validado y estabilizado |
Para Klapper, nuestro producto propio de venta de entradas, construimos el sistema de diseño en paralelo al primer desarrollo de la app. No porque fuera obligatorio, sino porque sabíamos que el producto iba a tener web, app iOS, app Android y panel de administración. Sin sistema desde el principio, la coherencia entre plataformas habría costado el doble de corregir después.
El error más caro: construir el sistema demasiado tarde
El momento en que más duele no tener un sistema de diseño no es al principio del proyecto. Es cuando llevas 18 meses en producción, el equipo ha rotado, hay tres versiones distintas del componente de tarjeta repartidas por el código y cada cambio global requiere tocar veinte sitios distintos.
Retroadaptar un sistema a un producto existente es posible. Pero cuesta entre dos y cuatro veces más que haberlo construido desde el principio. Y durante el proceso de migración, el equipo no puede avanzar al ritmo habitual porque está resolviendo deuda de diseño acumulada.
¿Tu equipo tarda más en asegurarse de que algo es consistente que en construirlo? Eso ya es el coste del sistema que no tienes.
Cómo empezar sin construir el sistema completo desde el día uno
No tienes que construir el sistema de diseño completo antes de lanzar nada. Hay una estrategia incremental que funciona mejor para proyectos que están creciendo:
Paso 1 — Define los tokens primero. Color, tipografía, espaciado. Son las decisiones que más duelen cambiar después porque están en todas partes. Documentarlos desde el principio tiene coste cero comparado con el coste de cambiarlos en cien sitios distintos.
Paso 2 — Añade componentes por prioridad de uso, no por completitud. El botón primario, el formulario, la tarjeta de contenido. Los componentes que aparecen en todos los flujos. No los exóticos que aparecen en una pantalla específica.
Paso 3 — Documenta al construir, no después. La documentación que se escribe al final de un sprint nadie la escribe. La que se escribe mientras se decide el comportamiento de un componente existe y es útil.
Preguntas frecuentes sobre sistemas de diseño
¿Cuánto tiempo lleva construir un sistema de diseño desde cero?
Depende del alcance del producto y la profundidad del sistema. Para un producto digital de tamaño medio, una base funcional —tokens + 15-20 componentes clave + documentación básica— lleva entre 4 y 8 semanas. Un sistema completo para un producto grande puede llevar varios meses. Lo importante es que sea incremental y que empiece a usarse antes de estar «completo».
¿Necesito Figma para tener un sistema de diseño?
Figma es la herramienta más usada y tiene las mejores funcionalidades para sistemas de diseño (variables, componentes, modos). Pero el sistema de diseño es el método, no la herramienta. Puedes construirlo con otras herramientas. Lo que no puedes hacer es tener el sistema solo en el código o solo en diseño: tienen que estar conectados.
¿Un sistema de diseño es lo mismo que una guía de marca?
No. La guía de marca define la identidad visual: logo, colores corporativos, tipografía, tono de comunicación. Un sistema de diseño traduce esas decisiones en componentes de interfaz implementables en un producto digital. Son complementarios, no sinónimos. Una empresa puede tener guía de marca sin sistema de diseño, y viceversa.
¿Cuándo es demasiado pronto para construir un sistema de diseño?
Cuando el producto todavía está en fase de validación y el modelo de negocio puede cambiar de forma sustancial. Construir un sistema para un MVP que vas a pivotar es construir infraestructura para una dirección que puede no existir en tres meses. Primero valida. Luego sistematiza.
