Cómo crear un sistema de diseño desde cero

Antes de diseñar nada nuevo, necesitas entender qué tienes. Una auditoría visual consiste en recopilar capturas de todos los componentes, estilos y patrones que existen en tus productos actuales. Herramientas como el plugin de Figma "Design Lint" o simplemente recorrer cada pantalla con capturas organizadas son un buen punto de partida.

El objetivo no es juzgar, sino cuantificar: ¿cuántas variantes de botón existen? ¿Cuántos tonos de gris se usan? ¿Hay tres modales distintos que hacen lo mismo? Esta radiografía revela la deuda de diseño acumulada y establece las prioridades para el sistema.

Los design tokens son las decisiones atómicas de tu sistema: colores, tipografías, espaciados, radios de borde, sombras, duraciones de animación. Son la base sobre la que se construye todo lo demás. Definirlos bien desde el principio evita refactorizaciones costosas más adelante.

Organiza los tokens en dos niveles: primitivos (los valores crudos, como #1A73E8 o 16px) y semánticos (su significado contextual, como color-primary o spacing-md). Los tokens semánticos son los que usarán diseñadores y desarrolladores en el día a día, y los que permiten soportar temas (dark mode, marcas múltiples) sin cambiar componentes.

Con los tokens definidos, llega el momento de construir los componentes. Empieza por los más utilizados y transversales: botones, campos de formulario, tipografía, iconos, cards y contenedores de layout. No intentes cubrir todo el catálogo de una vez.

Cada componente debe diseñarse en Figma (o tu herramienta de diseño) y codificarse en paralelo. La paridad entre diseño y código es fundamental: si el componente en Figma tiene cuatro variantes, el componente en código debe tener las mismas cuatro. Usa props claras, estados bien definidos (default, hover, active, disabled, error) y documenta cada decisión.

La documentación es lo que convierte una librería de componentes en un sistema de diseño. Sin ella, los equipos no saben cuándo usar un componente, cómo combinarlo con otros, ni qué alternativas existen. La documentación debe vivir junto al código, no en un PDF olvidado en Confluence.

Para cada componente, documenta: propósito, variantes disponibles, props/API, ejemplos de uso correcto e incorrecto, consideraciones de accesibilidad y relación con otros componentes. Herramientas como Storybook, Supernova o ZeroHeight permiten generar documentación viva directamente desde el código.

Un sistema de diseño sin gobernanza es una librería que se queda obsoleta. El modelo de gobernanza define quién puede proponer cambios, cómo se revisan, quién los aprueba y cómo se versionan y comunican. Sin este proceso, el sistema se fragmenta rápidamente.

Los modelos más habituales son: centralizado (un equipo dedicado gestiona todo), federado (cada equipo contribuye siguiendo unas reglas) e híbrido (un equipo core mantiene los fundamentos y los equipos de producto contribuyen componentes específicos). El modelo federado o híbrido suele funcionar mejor en organizaciones grandes porque distribuye la responsabilidad.

El mayor riesgo de un sistema de diseño no es técnico, sino organizacional: que nadie lo use. Para evitarlo, involucra a los equipos consumidores desde el principio. Recoge su feedback, prioriza los componentes que más necesitan, y haz que usar el sistema sea más fácil que no usarlo.

Mide la adopción de forma objetiva: porcentaje de componentes del sistema vs componentes custom en cada producto, tiempo medio de desarrollo de nuevas pantallas, y número de inconsistencias reportadas. Estas métricas justifican la inversión y guían la evolución del sistema.