La mayoría de los design systems fracasan por la misma razón: se construyen como un ejercicio aparte, se admiran durante una semana y luego se abandonan sin hacer ruido la primera vez que llega una fecha de entrega. El archivo cría una página de "Componentes" que nadie abre mientras las pantallas reales del producto están llenas de instancias desvinculadas y códigos hexadecimales puestos una sola vez.
Esta es la versión que uso en el trabajo real con clientes: lo bastante pequeña como para construirla en unos días, lo bastante estricta como para que siga aguantando tres meses después, y estructurada de forma que un desarrollador pueda mapearla sobre Tailwind o una biblioteca de componentes sin adivinar.
Empieza con una auditoría, no con un archivo en blanco
Antes de definir nada, coge las pantallas que ya existen y extrae cada color, cada estilo de texto y cada valor de espaciado en uso. En un producto que ha diseñado más de una persona, el resultado suele ser once grises, siete tamaños de fuente que se diferencian en uno o dos píxeles y tres alturas de botón. Ese inventario es el brief del sistema. No estás inventando una escala de la nada; estás decidiendo cuáles de los valores existentes sobreviven.
Fusiona sin piedad. Dos grises que se diferencian en un dos por ciento de luminosidad son un solo gris. Un tamaño de cuerpo de 15px y uno de 16px son un solo tamaño de cuerpo. Cada valor que conservas es una decisión que alguien tiene que volver a tomar en cada pantalla futura, así que cuanto más pequeño sea el conjunto, más rápido es de usar el sistema, y la rapidez de uso es lo único que determina si la gente lo usa de verdad.
Anota los valores que sobreviven como una lista plana antes de tocar las variables de Figma. Si no puedes justificar un valor en voz alta en una sola frase, no entra.
Tres niveles de tokens, y no más
Las variables de Figma hacen tentador construir un grafo de tokens elaborado. Resístete. Tres niveles cubren casi cualquier producto: primitivos, semánticos y el reducido número de overrides a nivel de componente que de verdad no puedes expresar de forma semántica.
Los primitivos son valores en bruto con nombres sin significado: de grey/100 a grey/900, blue/500, space/4. Los semánticos describen la intención y apuntan a los primitivos: surface/default, surface/raised, text/primary, text/muted, border/subtle, action/primary. Los componentes solo reciben su propio token cuando un valor es verdaderamente local, como la altura concreta de la celda de tu date-picker.
La razón de ser del nivel intermedio son los temas. Cuando un cliente pide dark mode, añades un segundo modo en la colección semántica y lo remapeas a primitivos distintos. Nada de la biblioteca de componentes cambia, porque ningún componente referencia grey/800 directamente; referencia surface/raised. Si tus componentes apuntan a primitivos, el dark mode es una reconstrucción en lugar de un remapeo.
Nombra los tokens en el orden categoría/rol/variante, todo en minúsculas, con barras para agrupar. Se lee bien en la barra lateral de Figma y se convierte de forma limpia en los objetos anidados que espera un tema de Tailwind o un archivo de propiedades personalizadas de CSS.
Escalas de tipografía y espaciado que puedes defender
Una escala tipográfica de seis a ocho pasos basta para la mayoría de las interfaces: display, niveles de encabezado del uno al tres, body, small y caption. Cada paso debería ser visiblemente distinto del que tiene al lado. Si tienes que entornar los ojos para diferenciar dos tamaños, uno de ellos es decoración, no jerarquía.
Define la altura de línea como parte del estilo, no como un override por instancia. El texto largo pide en torno a 1.5 o 1.6; los encabezados piden de 1.05 a 1.2. Incorpora también el tracking en los tamaños grandes: la tipografía display casi siempre necesita un espaciado entre letras negativo que el texto de cuerpo no.
Para el espaciado, elige una base de 4px y usa una escala limitada: 4, 8, 12, 16, 24, 32, 48, 64. Eso se corresponde uno a uno con el espaciado por defecto de Tailwind, lo que significa que un desarrollador nunca tiene que escribir un valor arbitrario como p-[13px]. Si un layout solo funciona a 13px, el problema suele ser el layout.
Una regla que ahorra más discusiones que ninguna otra: el espaciado comunica agrupación. Los elementos que van juntos tienen menos espacio entre sí que el hueco que los separa del siguiente grupo. La mayoría de las interfaces "desordenadas" no están mal estilizadas, simplemente están espaciadas de forma uniforme.
Componentes: propiedades en lugar de un muro de variantes
Un botón con cuarenta variantes para cada combinación de tamaño, estilo, icono y estado es un componente en el que nadie encuentra nada. Usa en su lugar las propiedades de componente: una propiedad de variante para el estilo, otra para el tamaño, propiedades booleanas para los slots de icono y propiedades de instance swap para los propios iconos. Cuatro propiedades describen esas mismas cuarenta combinaciones y siguen siendo legibles.
Nombra esas propiedades igual que el front-end nombrará sus props: size, variant, state, disabled, leadingIcon. Cuando el panel de propiedades de Figma y la firma de props de React usan las mismas palabras, las conversaciones de handoff dejan de ser una tarea de traducción. No cuesta nada en tiempo de construcción y da beneficios en cada ticket posterior.
Construye cada componente con auto layout, incluidos los que parecen no necesitarlo, y define el comportamiento de redimensionado de forma deliberada: fill para todo lo que deba estirarse, hug para todo lo que se dimensione según su contenido. El auto layout es lo más parecido que tiene Figma a flexbox, así que un componente bien maquetado en el archivo es un componente que ya ha respondido a las preguntas de layout del desarrollador.
Diseña también los estados que la gente olvida: hover, focus, disabled, loading y la versión con texto lo bastante largo como para que se ajuste a varias líneas. Un componente que solo existe en su estado ideal no es un componente de sistema, es una ilustración de uno.
Documentación que vive en el archivo
Nadie lee un sitio de documentación aparte para una biblioteca de ocho componentes. Pon la orientación donde ocurre el trabajo: rellena el campo de descripción de cada componente y cada estilo, porque aparece en el panel de assets y en Dev Mode justo cuando alguien está decidiendo qué usar.
Añade una página con frames emparejados de lo que se debe y lo que no se debe hacer para los componentes que más se usan mal: normalmente botones, campos de formulario y estados vacíos. Un par de capturas de pantalla pequeñas resuelven una duda más rápido que un párrafo.
Mantén una breve página de changelog al principio del archivo con fechas y entradas de una línea. En un proyecto de cliente esto es además tu rastro de pruebas: cuando alguien pregunta por qué cambió un color en marzo, la respuesta lleva diez segundos.
Por último, usa branching para cualquier cosa estructural. Renombrar una colección de variables o reestructurar un componente en el archivo principal a mitad de sprint rompe las instancias en vivo de todos los archivos de producto, y quien se entera es siempre un desarrollador en el peor momento.
Cómo saber si el sistema funciona de verdad
Un sistema funciona si diseñar una pantalla nueva se siente como componer bloques existentes en lugar de dibujar formas nuevas. La prueba de verdad llega dos meses después del lanzamiento: comprueba cuántos componentes del archivo son instancias sin desvincular, cuántos colores salen de la paleta de tokens y si un nuevo miembro del equipo puede construir una pantalla sin preguntar dónde encontrar el botón primario.
Si las respuestas son altas, el sistema está cumpliendo su función. Si no, elimina la mitad de los tokens y vuelve a intentarlo.
