NUCBA - Formación profesional digital

El problema de empezar desde cero cada vez

Hace unas semanas, charlando con un frontend de un equipo de producto, me contaba algo que escucho seguido: "Estoy creando los mismos componentes que ya hice el mes pasado, pero con pequeñas diferencias que ahora no recuerdo por qué eran necesarias".

Es el síntoma clásico de no tener un design system. Cada feature nueva se convierte en una ruleta: ¿este botón va con border-radius de 4px o 8px? ¿El azul primario era #3B82F6 o #2563EB? ¿La tipografía de este heading era font-weight 600 o 700?

Un design system no es una colección bonita de componentes para mostrar en el portfolio. Es tu forma de no volverte loco manteniendo consistencia visual mientras escalás un producto.

Qué es realmente un design system

Un design system es la documentación viva de las decisiones de diseño de tu producto, implementada como código reutilizable. Incluye:

Design tokens: los valores primitivos (colores, tipografías, espaciados)
Componentes: elementos de UI reutilizables con sus variantes
Patrones: combinaciones de componentes que resuelven problemas específicos
Documentación: cómo y cuándo usar cada elemento

La clave está en "documentación viva". No es un PDF que nadie lee, sino código que usás todos los días.

Design tokens: la base de todo

Los design tokens son las decisiones más básicas convertidas en variables. En lugar de usar valores hardcodeados, definís un sistema:

:root {
  /* Colores */
  --color-primary-50: #eff6ff;
  --color-primary-500: #3b82f6;
  --color-primary-900: #1e3a8a;
  
  /* Espaciados */
  --space-xs: 0.25rem;  /* 4px */
  --space-sm: 0.5rem;   /* 8px */
  --space-md: 1rem;     /* 16px */
  --space-lg: 1.5rem;   /* 24px */
  
  /* Tipografía */
  --font-size-sm: 0.875rem;
  --font-size-base: 1rem;
  --font-size-lg: 1.125rem;
  --line-height-tight: 1.25;
  --line-height-normal: 1.5;
}

Esto te permite cambiar el azul primario en toda la aplicación modificando una sola variable. Y más importante: obliga a tu equipo a usar valores consistentes.

Construyendo componentes reutilizables

Un componente de design system no es solo HTML y CSS bonito. Necesita manejar todas las variantes que vas a necesitar:

// Button.jsx
const Button = ({ 
  variant = 'primary', 
  size = 'md', 
  disabled = false, 
  children,
  ...props 
}) => {
  const baseClasses = 'font-medium rounded-md transition-colors';
  
  const variantClasses = {
    primary: 'bg-blue-600 text-white hover:bg-blue-700',
    secondary: 'bg-gray-200 text-gray-900 hover:bg-gray-300',
    outline: 'border border-gray-300 text-gray-700 hover:bg-gray-50'
  };
  
  const sizeClasses = {
    sm: 'px-3 py-1.5 text-sm',
    md: 'px-4 py-2 text-base',
    lg: 'px-6 py-3 text-lg'
  };
  
  return (
    <button
      className={`
        ${baseClasses}
        ${variantClasses[variant]}
        ${sizeClasses[size]}
        ${disabled ? 'opacity-50 cursor-not-allowed' : ''}
      `}
      disabled={disabled}
      {...props}
    >
      {children}
    </button>
  );
};

La magia está en pensar todas las variantes que vas a necesitar desde el principio. ¿Botones de diferentes tamaños? ¿Estados de loading? ¿Con íconos? Mejor resolver eso una vez que resolver pedacitos cada vez que aparece un caso nuevo.

Documentación que realmente sirve

La documentación de un design system tiene que responder preguntas concretas:

Cuándo usar: "Usá el botón primary para la acción principal de cada vista"
Cuándo NO usar: "No uses botones primary para acciones destructivas"
Variantes disponibles: ejemplos visuales de cada configuración
Props y API: qué parámetros acepta cada componente

Herramientas como Storybook te permiten documentar componentes con ejemplos interactivos:

// Button.stories.js
export default {
  title: 'Components/Button',
  component: Button,
};

export const Primary = {
  args: {
    variant: 'primary',
    children: 'Click me',
  },
};

export const AllVariants = () => (
  <div className="space-x-4">
    <Button variant="primary">Primary</Button>
    <Button variant="secondary">Secondary</Button>
    <Button variant="outline">Outline</Button>
  </div>
);

Adoptando design systems sin morir en el intento

El error más común es querer crear el design system perfecto desde día uno. Mejor enfoque:

Empezá con lo que tenés: auditá los componentes que ya usás y estandarizá los más frecuentes
Design tokens primero: definí colores, espaciados y tipografías antes que componentes
Un componente por vez: convertí a design system los elementos que más duplicás
Iterá con feedback: usá el componente en proyectos reales y ajustá según lo que te pida el equipo

El costo real de no tener design system

Sin design system, tu producto crece con inconsistencias que se acumulan:

Tiempo de desarrollo: cada feature nueva requiere decisiones de diseño desde cero
Deuda técnica: código CSS duplicado y estilos hardcodeados por todas partes
Experiencia de usuario: interfaces inconsistentes que confunden al usuario
Onboarding: nuevos developers tardan más en entender las convenciones

Un design system bien implementado recupera la inversión inicial en pocas semanas.

Herramientas que te simplifican la vida

No necesitás crear todo desde cero. Estas herramientas te dan una base sólida:

Tailwind CSS: utility classes que funcionan como design tokens
Headless UI: componentes accesibles sin estilos predefinidos
Storybook: documentación interactiva de componentes
Figma: diseño y handoff con design tokens
Style Dictionary: generación automática de tokens para múltiples plataformas

Escalando tu design system

Un design system maduro no solo incluye componentes básicos, sino patrones más complejos:

Layouts: grids, sidebars, headers que se comportan consistentemente
Estados: loading, error, empty states estandarizados
Micro-interacciones: animaciones y transiciones reutilizables
Temas: soporte para modo oscuro, branding personalizado

Pero llegás ahí paso a paso, no de una vez.

Tener un design system no significa que tu producto va a verse aburrido o igual a todos. Significa que vas a tomar decisiones de diseño una vez y implementarlas de forma consistente. Al final, los usuarios van a agradecer la predictibilidad, y vos vas a agradecer no reinventar la rueda cada lunes.

Preguntas frecuentes

¿Cuándo conviene empezar un design system? Cuando tenés al menos 3-4 vistas en tu producto y notás que estás duplicando componentes. Antes de eso, probablemente sea overkill.

¿Puedo usar un design system de terceros? Sí, bibliotecas como Material UI, Ant Design o Chakra UI son buenas bases. Pero vas a necesitar customizarlas para que reflejen tu marca y necesidades específicas.

¿Cómo convenzo al equipo de adoptar design system? Mostrá el tiempo que se pierde duplicando trabajo y la cantidad de bugs visuales que aparecen por inconsistencias. Un prototipo rápido con componentes reutilizables suele ser más convincente que cualquier presentación.

Design Systems: el antídoto contra la ruleta visual