Design Systems no son para todos: cuándo crear uno en serio

La industria está obsesionada con los design systems. Cada startup de 3 personas quiere el suyo, cada diseñador junior habla de "escalar el diseño" y cada PM piensa que un design system va a resolver sus problemas de consistencia.

Pero acá está la realidad: la mayoría de los equipos no necesitan un design system. Y cuando lo hacen mal, pierden más tiempo del que ahorran.

Te voy a mostrar cuándo realmente necesitás uno y cuándo es mejor enfocarte en otras cosas.

Cuándo NO necesitás un design system

Equipos pequeños (menos de 15 personas)

Si tenés un equipo de desarrollo de menos de 15 personas, un design system probablemente sea overkill. Con ese tamaño:

• La comunicación es directa
• Los cambios se coordinan fácil
• La inconsistencia se soluciona en 5 minutos de Slack
• El overhead de mantener un sistema es mayor al beneficio

En vez de un design system, mejor:

• Usá una librería de componentes existente (Material UI, Ant Design, Chakra)
• Definí 2-3 reglas básicas de espaciado y tipografía
• Hacé code reviews enfocados en consistencia

Productos en fase de discovery

Si todavía estás validando tu producto, creando prototipos y pivoteando cada mes, un design system te va a frenar. En esta etapa necesitás velocidad y flexibilidad, no consistencia.

Lo que sí podés hacer:

• Usar wireframes de baja fidelidad
• Prototipar rápido con herramientas como Whimsical
• Mantener un documento simple con decisiones de UX (no de UI)

Cuando no tenés recursos para mantenerlo

Un design system abandonado es peor que no tener ninguno. Si no podés dedicar al menos 20% del tiempo de una persona a mantenerlo, no lo hagas.

Un design system mal mantenido genera:

• Componentes desactualizados
• Documentación mentirosa
• Fragmentación del equipo
• Pérdida de confianza en las herramientas internas

Cuándo SÍ necesitás un design system

Múltiples productos o plataformas

Acá es donde los design systems brillan. Si tenés:

• Una app web y mobile
• Un dashboard admin y una landing
• Múltiples productos bajo la misma marca
• Diferentes equipos trabajando en paralelo

Un design system te va a ahorrar tiempo real. Cada componente que definís una vez se puede reutilizar en todos lados.

Equipos de más de 20 personas

Cuando el equipo crece, la comunicación se vuelve más compleja. Un design system actúa como un lenguaje común que reduce la necesidad de coordinación constante.

Indicadores de que necesitás sistematizar:

• Los diseñadores preguntan "¿cómo era que hacíamos los botones?"
• Los devs implementan el mismo componente de forma diferente
• QA reporta inconsistencias visuales frecuentes
• Los stakeholders notan diferencias entre secciones del producto

Producto maduro con patrones claros

Si tu producto ya pasó las primeras iteraciones y tenés patrones de interacción establecidos, un design system te ayuda a escalar.

Señales de que estás listo:

• Identificaste los 10-15 componentes que más usás
• Tenés reglas claras de espaciado y tipografía
• Los usuarios ya se acostumbraron a ciertos patterns
• Las nuevas features siguen patrones existentes

Cómo empezar (si realmente lo necesitás)

1. Auditoría de componentes existentes

Antes de crear algo nuevo, mirá lo que ya tenés. Capturá screenshots de:

• Todos los botones que usás
• Formularios y inputs
• Cards y contenedores
• Navegación y menús

Vas a encontrar más variaciones de las que esperás. El objetivo es consolidar, no documentar el caos.

2. Empezá con lo mínimo viable

No trates de definir todo de una. Empezá con:

Tokens básicos:

/* Colores principales */
--primary: #2563eb;
--secondary: #64748b;
--success: #16a34a;
--error: #dc2626;

/* Espaciado */
--space-xs: 4px;
--space-sm: 8px;
--space-md: 16px;
--space-lg: 24px;
--space-xl: 32px;

3-5 componentes core:

• Button
• Input
• Card
• Typography
• Layout containers

3. Documentá el "por qué", no solo el "cómo"

Cada decisión de diseño debe tener un contexto. En vez de solo mostrar cómo usar un componente, explicá:

• Cuándo usarlo
• Cuándo NO usarlo
• Qué problema resuelve
• Ejemplos de uso correcto e incorrecto

4. Hacelo evolutivo

Un design system no se define de una vez y para siempre. Establecé un proceso para:

• Proponer nuevos componentes
• Modificar existentes
• Deprecar patrones obsoletos
• Revisar periódicamente su uso

Errores comunes que arruinan design systems

Crear componentes demasiado específicos

Un ProductCardWithPriceAndRating no es reutilizable. Mejor crear componentes granulares que se combinen:

// Mal
<ProductCardWithPriceAndRating />

// Bien
<Card>
  <Image />
  <Typography variant="title" />
  <PriceDisplay />
  <Rating />
</Card>

Obsesionarse con la perfección

El mejor design system es el que se usa, no el más bonito. Preferí algo funcional e imperfecto que algo teórico y pulido.

No involucrar a desarrollo desde el inicio

Si los desarrolladores no participan en la creación del sistema, no lo van a adoptar. Asegurate de que sea técnicamente viable y fácil de implementar.

Falta de governance

Sin alguien que tome decisiones finales, el design system se convierte en un free-for-all donde cada uno agrega lo que se le ocurre.

La decisión final

Antes de crear un design system, preguntate:

1. ¿Tengo al menos 2 productos diferentes que podrían compartir componentes?
2. ¿Mi equipo es lo suficientemente grande como para que la coordinación sea un problema?
3. ¿Puedo dedicar tiempo consistente a mantenerlo?
4. ¿Mi producto ya tiene patrones establecidos?

Si respondiste "no" a más de una pregunta, probablemente no necesites un design system todavía.

Y está bien. Hay muchas formas de mantener consistencia sin la complejidad de un sistema formal. A veces una simple style guide de una página es más útil que un design system completo.

Lo importante es ser honesto sobre dónde está tu equipo y qué problemas realmente necesitás resolver.