Design System: checklist para decidir cuándo crear uno

Hace dos años trabajé en una startup que decidió arrancar con un design system desde el día uno. El resultado: tres meses perdidos en componentes que nunca usamos y un producto que llegó tarde al mercado.

El design system se convirtió en la solución mágica para todos los problemas de producto. El problema es que, como cualquier herramienta, tiene su momento y su lugar.

Cuándo SÍ necesitás un design system

Tu equipo tiene más de 3 diseñadores

Con un diseñador, las inconsistencias son mínimas. Con dos, se pueden coordinar. Con tres o más, empiezan los quilombos: botones con 4 estilos diferentes, spacing que no coincide, colores que "se ven parecidos" pero no son iguales.

Un design system acá no es lujo, es supervivencia.

Tenés múltiples productos o plataformas

Si estás manteniendo una app web, mobile y tal vez una landing, necesitás coherencia visual entre todas. Los usuarios pasan de una plataforma a otra y esperan reconocer tu marca.

Sin design system, cada plataforma evoluciona por su lado y terminás con tres identidades visuales distintas.

Tu codebase tiene componentes duplicados

Abrís el proyecto y ves: Button.jsx, ButtonPrimary.jsx, CTA.jsx, SubmitButton.jsx. Todos hacen básicamente lo mismo con pequeñas variaciones.

Este es el momento perfecto para un design system. Ya tenés los componentes, solo necesitás unificarlos y documentarlos.

El equipo de desarrollo pide especificaciones constantemente

"¿Cuánto padding tiene este botón?" "¿Este gris es el mismo que usamos en la sidebar?" "¿El modal va centrado o un poco más arriba?"

Cuando estas preguntas se repiten semanalmente, un design system las elimina de una.

Cuándo NO necesitás un design system

Sos un equipo de 1-2 personas

Con equipos chicos, el overhead de mantener un design system supera los beneficios. La comunicación es directa, las decisiones son rápidas, y las inconsistencias se resuelven al toque.

Tu tiempo está mejor invertido en validar el producto con usuarios reales.

Tu producto está en fase de discovery

Si todavía estás validando la idea, experimentando con diferentes flujos, o pivoteando cada dos semanas, un design system te va a frenar.

Necesitás flexibilidad para cambiar todo rápido, no componentes rígidos que hay que actualizar cada vez que pivoteás.

No tenés recursos para mantenerlo

Un design system abandonado es peor que no tener ninguno. Los componentes se vuelven obsoletos, aparecen bugs que nadie arregla, y el equipo vuelve a crear soluciones ad-hoc.

Si no podés dedicar al menos 20% del tiempo de alguien a mantenerlo, no lo hagas.

Tu stack tecnológico va a cambiar pronto

¿Estás migrando de React a Vue? ¿Pensando en reescribir todo en Next.js? Un design system implementado en la tecnología vieja se convierte en deuda técnica.

Esperá a tener el stack definitivo antes de invertir en componentes.

Checklist de decisión: ¿arranco con un design system?

Respondé SÍ o NO a cada pregunta:

• Tenemos 3+ diseñadores en el equipo
• Manejamos múltiples productos/plataformas
• Hay componentes visuales duplicados en el código
• Los developers preguntan specs constantemente
• Tenemos tiempo dedicado para mantenerlo (20%+ de alguien)
• Nuestro stack tecnológico está estabilizado
• El producto pasó la fase de discovery/validación inicial
• Hay presupuesto para herramientas (Figma, Storybook, etc.)

Resultado:

• 6-8 SÍ: Arrancá ya, lo necesitás
• 4-5 SÍ: Evaluá en 3-6 meses
• 0-3 SÍ: Enfocate en otras prioridades

Cómo empezar (si decidiste que sí)

Arrancá con un inventario

No inventes desde cero. Auditá lo que ya tenés:

1. Sacá screenshots de todos los componentes actuales
2. Agrupá los similares (todos los botones juntos, todos los modals, etc.)
3. Identificá patrones: qué funciona bien y qué está roto

Definí el alcance mínimo

No hagas un design system de 200 componentes. Arrancá con lo básico:

• Colores (primary, secondary, grays, states)
• Tipografía (3-4 tamaños máximo)
• Spacing (sistema de 8px funciona para el 90%)
• Botones (primary, secondary, destructive)
• Inputs básicos

Elegí las herramientas correctas

Para diseño: Figma con bibliotecas compartidas Para código: Storybook si tenés tiempo, documentación simple si no Para tokens: CSS custom properties o Tailwind

No te compliques con herramientas fancy al principio. Un Google Doc bien organizado es mejor que un Notion súper elaborado que nadie mantiene.

Los errores más comunes (y cómo evitarlos)

Error 1: Hacer todo perfecto desde el vamos

Yo caí en esta. Pasé semanas definiendo 47 variantes de botones que nunca usamos. Mejor hacer los 3 botones que necesitás ahora y expandir después.

Error 2: No involucrar a desarrollo

Un design system que los developers no adoptan es papel pintado. Involucralos desde el diseño, que opinen sobre la implementación, que se sientan parte.

Error 3: Documentar de más al principio

La documentación perfecta se vuelve obsoleta rápido. Arrancá con lo mínimo: cómo usar cada componente y cuándo no usarlo.

Cuándo revisar la decisión

Evaluá cada 6 meses si tu design system sigue teniendo sentido:

• ¿El equipo creció o se achicó significativamente?
• ¿Cambió la complejidad del producto?
• ¿Está siendo usado realmente?
• ¿Los beneficios superan el costo de mantenimiento?

No hay vergüenza en pausar o discontinuar un design system que no aporta valor. Es mejor ser honest que mantener algo por inercia.

La decisión de crear un design system no es permanente. Es una herramienta que tenés que evaluar como cualquier otra: ¿resuelve un problema real que tenés ahora?

Preguntas frecuentes

¿Puedo usar un design system de terceros como Material UI?

Sí, especialmente si estás empezando. Material UI, Ant Design o Chakra UI te dan una base sólida. Podés customizarlos después cuando sepas mejor qué necesitás.

¿Cuánto tiempo lleva implementar un design system básico?

Con un equipo dedicado, entre 4-8 semanas para tener algo funcional. Sin dedicación full-time, puede llevar 3-6 meses. Por eso es crítico tener recursos asignados.

¿Qué hago si ya empecé uno y no lo estamos usando?

Pará, evaluá por qué no se usa (¿muy complejo? ¿no resuelve problemas reales?) y simplificá. A veces es mejor volver atrás y empezar más chico.