Respuesta corta: un design system es el conjunto de decisiones de diseño reutilizables de un producto (colores, tipografía, espaciado, iconos, componentes y las reglas para usarlos), compartido entre diseño y desarrollo para que todo lo que se construye sea coherente y más rápido de hacer. A una startup le compensa crear uno en cuanto tiene más de un diseñador o desarrollador tocando la interfaz, o más de 10–15 pantallas; antes de eso basta con una base mínima de tokens y una docena de componentes.
Mucha gente asocia "design system" a los sistemas enormes de Google, IBM o Shopify, con equipos dedicados y webs de documentación. Una startup no necesita eso. Necesita un sistema pequeño, útil y vivo que haga que el producto parezca uno solo y que cada pantalla nueva cueste menos. Esta guía explica cómo lo planteamos en Pleya Studio en proyectos como Mainder, donde el design system fue la base de 24 pantallas rediseñadas y 8 módulos nuevos.
¿Qué es exactamente un design system?
Un design system tiene tres capas:
- Fundamentos o tokens: las decisiones más básicas, con nombre. Colores (
color.text.primary,color.bg.subtle,color.status.danger), tipografías y escalas de tamaño, espaciados, radios de borde, sombras, duraciones de animación. - Componentes: piezas de interfaz construidas con esos tokens. Botones, inputs, selects, tablas, tarjetas, etiquetas, modales, menús, navegación… cada uno con sus variantes (primario, secundario) y estados (hover, foco, deshabilitado, error, carga).
- Patrones y reglas: cómo se combinan los componentes para resolver problemas habituales (un formulario, una tabla con filtros, un estado vacío, una confirmación destructiva) y cuándo usar cada cosa.
Y, muy importante, existe a la vez en diseño y en código: los mismos nombres, las mismas variantes y los mismos valores en Figma y en la librería de componentes del producto.
Design system, guía de estilo y librería de componentes: diferencias
| Guía de estilo | Librería de componentes | Design system | |
|---|---|---|---|
| Qué es | Documento con logo, colores y tipografía | Conjunto de componentes reutilizables (en Figma o en código) | Tokens + componentes + reglas, sincronizados entre diseño y código |
| Para quién | Marca y marketing | Diseño o desarrollo | Todo el equipo de producto |
| Responde a | ¿Cómo se ve la marca? | ¿Qué piezas tengo? | ¿Cómo construimos interfaces coherentes y rápido? |
Una guía de estilo es parte de la identidad de marca; si estás en ese punto, tienes más contexto en nuestro servicio de identidad visual en la home. Un design system la traduce a producto.
¿Cuándo necesita una startup un design system?
Señales de que ha llegado el momento:
- El producto tiene más de 10–15 pantallas y empiezan a aparecer variantes del mismo componente.
- Hay más de una persona diseñando o maquetando la interfaz.
- Desarrollo pregunta lo mismo una y otra vez: qué gris, qué margen, qué botón.
- Cada funcionalidad nueva tarda más de lo que debería porque se diseña desde cero.
- Vas a rediseñar el producto o lanzar una nueva aplicación (por ejemplo, móvil además de web).
- Ventas o inversores perciben el producto como poco sólido por las inconsistencias visuales.
Señales de que todavía no:
- Estás validando si el producto tiene sentido y cambias de dirección cada semana.
- El producto tiene cinco pantallas y lo hace una persona.
Incluso en ese caso, conviene empezar con tokens y una librería de componentes base (por ejemplo, partiendo de una librería de código abierta) para no acumular deuda visual.
¿Qué beneficios tiene un design system?
- Velocidad: diseñar y construir una pantalla nueva es combinar piezas que ya existen.
- Coherencia: el producto parece uno solo, aunque lo construyan diez personas.
- Calidad: los estados difíciles (errores, cargas, accesibilidad, foco de teclado) se resuelven una vez y bien.
- Menos discusiones: las decisiones ya están tomadas y documentadas.
- Onboarding más rápido de nuevos diseñadores y desarrolladores.
- Cambios globales baratos: cambiar un color de marca o un radio de borde es tocar un token, no cien pantallas.
Cómo crear un design system en 6 pasos
1. Haz un inventario de la interfaz actual
Haz capturas de cada pantalla del producto y agrupa lo que se repite: todos los botones juntos, todos los inputs juntos, todas las tablas juntas. El resultado suele ser revelador: es habitual encontrar siete tonos de gris, cinco tamaños de botón y tres estilos de tabla. Este inventario es lo que te dice qué componentes necesitas y cuáles sobran.
2. Define los tokens
Empieza por lo mínimo:
- Color: una paleta base (marca, neutros, estados) y, encima, tokens semánticos que describen el uso, no el color:
text-primary,text-secondary,bg-surface,border-subtle,status-success. Así podrás tener modo oscuro o cambiar la marca sin tocar componentes. - Tipografía: una escala corta (6–8 tamaños) con pesos e interlineados definidos.
- Espaciado: una escala basada en 4 u 8 píxeles.
- Radios, sombras y bordes: dos o tres valores de cada.
- Movimiento: duraciones y curvas de animación estándar.
3. Diseña los componentes base
Prioriza los que más se usan. Para casi cualquier SaaS, la primera tanda es: botón, enlace, input, textarea, select, checkbox, radio, switch, etiqueta o badge, avatar, tooltip, tabla, tarjeta, modal, menú desplegable, pestañas, navegación lateral, cabecera de página, estado vacío y notificación (toast).
Para cada componente define variantes, tamaños y estados. Un botón sin su estado de carga o deshabilitado no está terminado.
4. Llévalo a código desde el principio
Un design system que solo existe en Figma se desincroniza en semanas. Construye los componentes en código con los mismos nombres y propiedades que en diseño, y que los tokens vivan en un único sitio (por ejemplo, variables CSS o un archivo de configuración) del que beban diseño y código.
En nuestros proyectos más recientes diseñamos directamente en código con ayuda de IA: el sistema se construye como componentes reales y el prototipo del producto usa esos mismos componentes. Así el design system y el producto son lo mismo desde el día uno. Es lo que hicimos con el prototipo navegable de Mainder.
5. Documenta lo justo
La documentación útil es breve: para cada componente, cuándo usarlo, cuándo no, sus variantes y un ejemplo. Es mejor tener diez componentes bien documentados que cincuenta sin explicar. Una página interna o un Storybook es suficiente para empezar.
6. Define quién lo mantiene y cómo se cambia
Sin un responsable, un design system se degrada. Decide:
- Quién aprueba componentes nuevos o cambios.
- Cómo se proponen (una petición sencilla basta).
- Cómo se versionan y comunican los cambios a desarrollo.
En una startup, normalmente es el diseñador de producto con un desarrollador frontend de referencia.
Errores que vemos a menudo
- Empezar por la documentación en lugar de por los componentes que el producto necesita ya.
- Crear componentes "por si acaso" que nadie usa.
- Tokens con nombres de color (
blue-500) en lugar de nombres de uso (action-primary), que hacen imposible cambiar la marca o añadir modo oscuro. - Diseño y código con nombres distintos para lo mismo.
- Olvidar la accesibilidad: contraste, tamaños mínimos de toque, foco visible y navegación por teclado.
- Tratarlo como un proyecto con fin. Un design system es un producto interno que evoluciona con el producto.
¿Cuánto cuesta crear un design system?
Depende del punto de partida:
- Base mínima (tokens + 15–20 componentes en diseño y código): de 3 a 6 semanas.
- Design system completo como parte de un rediseño de producto: se integra en el proyecto, como explicamos en el proceso de rediseño UX/UI de un SaaS.
- Mantenimiento: una parte del tiempo del equipo de diseño y frontend de forma continua.
La inversión se recupera en la velocidad de cada funcionalidad nueva. Si tu equipo construye varias pantallas al mes, el ahorro es visible en pocos sprints.
Design system también para la web de marketing
El mismo principio aplica a tu web: variables de color y tipografía, componentes reutilizables (secciones, tarjetas, botones, CTAs) y reglas de uso. En Framer y Webflow trabajamos así para que el equipo de marketing pueda crear páginas nuevas, como una landing page de campaña, sin romper la coherencia visual de la marca.
Ejemplo: el design system de un SaaS de reclutamiento
En el rediseño de Mainder el design system tenía que resolver un producto con mucha información: listas de posiciones con pipeline, fichas de candidato, búsquedas con IA, una bandeja de mensajes con varios canales, un calendario y paneles de analítica. Algunas decisiones que tomamos:
- Neutros con mucho rango. En un producto que se usa todo el día, la mayor parte de la interfaz es gris, blanco y negro. Definimos una escala de neutros amplia para separar fondos, superficies, bordes y textos sin recurrir al color.
- Color reservado para estados. Rojo para lo vencido o urgente, ámbar para lo que está a punto de vencer, verde para lo completado y un color de marca para la acción principal. Así una alerta destaca de verdad.
- Tablas como componente de primer nivel. Con variantes de densidad, columnas fijas, celdas con avatar, etiquetas, puntuaciones y acciones por fila. En un SaaS B2B, la tabla es probablemente el componente más importante.
- Componentes específicos de IA. Bloques que muestran qué criterios ha extraído la IA de una búsqueda y permiten editarlos, para que el usuario confíe en el resultado y pueda corregirlo.
- Navegación lateral agrupada por tareas (herramientas de IA, reclutamiento y ventas, gestión) en lugar de por módulos técnicos.
El resultado fue un sistema que sirvió para rediseñar 24 pantallas y crear 8 módulos nuevos con coherencia total, y que el equipo de desarrollo puede reutilizar en cada funcionalidad futura.
Design system e IA
La IA está cambiando la forma de construir interfaces, y un buen design system es lo que hace que funcione bien. Cuando una herramienta de IA genera una pantalla, lo hace mucho mejor si tiene un conjunto de componentes y tokens con nombres claros que reutilizar, en lugar de inventar estilos nuevos en cada pantalla. Un design system bien definido convierte la IA en un acelerador; sin él, la IA multiplica las inconsistencias.
Herramientas para crear y mantener un design system
- Figma para el diseño: variables para los tokens, componentes con propiedades y variantes, y librerías compartidas entre archivos.
- Código: variables CSS o un archivo de tokens compartido, una librería de componentes en el framework del producto (React, Vue…) y, si el equipo crece, un catálogo como Storybook para ver cada componente aislado.
- Sincronización: herramientas que exportan los tokens de Figma a código, para que un cambio de color no dependa de copiar valores a mano.
- Documentación: una página interna sencilla; lo importante es que esté donde el equipo trabaja.
Preguntas frecuentes
¿Qué incluye un design system?
Tokens de diseño (color, tipografía, espaciado, radios, sombras, movimiento), una librería de componentes con sus variantes y estados, patrones de uso y una documentación breve, todo ello sincronizado entre la herramienta de diseño y el código.
¿Puedo usar un design system de código abierto?
Sí, y para muchas startups es el mejor punto de partida. Puedes partir de una librería de componentes accesible ya existente y personalizar los tokens con tu marca. Lo que no puedes subcontratar es la decisión de qué componentes y patrones necesita tu producto.
¿Qué son los design tokens?
Son las decisiones de diseño más básicas guardadas con un nombre: un color, un tamaño de texto, un espaciado. Los componentes usan tokens en lugar de valores sueltos, de modo que cambiar un token actualiza todo el producto.
¿Cuánto tarda en crearse un design system?
Una base útil, con tokens y los 15–20 componentes principales en diseño y código, lleva de 3 a 6 semanas. A partir de ahí crece con el producto.
¿Necesito un design system si mi web está hecha en Framer?
Para la web de marketing, sí conviene trabajar con variables y componentes reutilizables, que Framer soporta de forma nativa. No hace falta la documentación formal de un sistema de producto, pero sí la disciplina de reutilizar.
¿Quién debe mantener el design system?
En una startup, el diseñador de producto con un desarrollador frontend de referencia. Lo importante es que haya un responsable claro y un proceso sencillo para proponer cambios.
Fuentes
- Brad Frost: Atomic Design: el método de referencia para construir design systems por componentes.
- U.S. Web Design System: un design system público y documentado, buen ejemplo de componentes, tokens y guías.
- Nielsen Norman Group: 10 heurísticas de usabilidad: los principios con los que se audita una interfaz.
Siguiente paso
Si tu producto está creciendo y la interfaz empieza a no ser coherente, agenda una reunión. Revisamos tu producto y te decimos qué base de design system necesitas ahora y qué puede esperar.
