Cómo Construir un Sistema de Diseño en Figma (Paso a Paso)

Construye un sistema de diseño de Figma completando nueve pasos en orden: audita la interfaz de usuario existente, crea un archivo de biblioteca dedicado, define capas de tokens primitivos y semánticos como Variables, ensambla componentes principales que se vinculen a esos tokens, gobierna las variantes con Propiedades de Componentes, documenta dentro del archivo, publica la biblioteca de equipo, asigna un propietario y exporta tokens al código. Esa secuencia no es estilística - cada fase depende de la anterior, y los dos modos de fallo más costosos (componentes construidos antes de los tokens, bibliotecas sin un propietario nombrado) provienen ambos de saltarse los pasos anteriores. Los equipos que siguen el orden lanzan una primera versión utilizable en dos a cuatro semanas y la amplían de forma incremental desde allí.

Flujos relacionados: Que es un sistema de diseno en Figma, Guia de design tokens de Figma, y Mejores practicas del sistema de diseno.

El error más común que vimos al auditar sistemas de diseño en Atomize fue componentes construidos antes de que existiera la capa de tokens. Un equipo pasaría semanas elaborando una biblioteca de componentes exhaustiva - auto-layout cuidadoso, variantes completas, documentación reflexiva - y luego intentaría añadir Variables y Modos encima. En ese punto cada relleno de componente es un valor hex codificado. La migración no es solo tediosa; es una fuente de regresiones, porque volver a vincular rellenos un componente a la vez sin verificación automatizada significa que algunos rellenos se pierden, y el desajuste solo surge cuando un cambio de modo produce un componente visualmente roto. Los tokens primero no es una preferencia estilística; previene una clase costosa de reelaboración.

Paso 1: Auditar la Interfaz de Usuario Actual

Una auditoría exhaustiva previene el error más costoso del sistema de diseño: descubrir una divergencia de valores no documentada después de que los componentes ya están construidos. Sin un inventario, los equipos construyen inconscientemente sobre una base fracturada - tres botones primarios casi idénticos, cuatro tonos de gris informales - y cada componente que añaden bloquea más esa inconsistencia. En Atomize, las auditorías habitualmente detectan 30-60 valores de color distintos donde los equipos esperaban menos de quince. Recoge cada hex, tamaño de fuente, truco de espaciado y radio de borde de los archivos de producción antes de escribir una sola Variable.

Usa un lienzo de Figma para recopilar capturas de pantalla lado a lado. Una hoja de cálculo simple que cuenta valores únicos (cuántos azules, cuántas variantes de botón) hace visible el alcance. Prioriza por radio de explosión: la navegación, los formularios y los componentes de retroalimentación aparecen en casi todas las pantallas - estabiliza esas bases primero.

Paso 2: Crear el Archivo de Biblioteca Dedicado

Separar el sistema de diseño en su propio archivo de Figma es la decisión estructural que hace que cada paso posterior sea tratable. Cuando los maestros viven dentro de los archivos de producto, el camino de actualización se rompe en el momento en que se une un segundo equipo de producto - no hay una fuente única desde la que publicar. Un archivo de biblioteca dedicado con una estructura de página predecible (Fundamentos, Componentes, Patrones, Documentación, Archivo) da a cada colaborador un modelo mental compartido y mantiene limpio el flujo de trabajo de publicación. Sin esta separación, la gobernanza no tiene nada que gobernar.

• Fundamentos - Variables (tokens), estilos de texto, estilos de color, estilos de efecto.
• Componentes - todos los componentes maestros publicados, organizados por categoría (Acciones, Entradas, Navegación, Retroalimentación, Visualización de datos).
• Patrones - composiciones a nivel de pantalla y layouts reutilizables.
• Documentación - frames de hacer/no hacer, diagramas de anatomía, notas de espaciado, directrices de contribución.
• Archivo - componentes obsoletos mantenidos durante una ventana de migración antes de la eliminación.

Los archivos de producto se mantienen aguas abajo y consumen instancias. Nunca construyas maestros dentro de un archivo de producto; en el momento en que lo haces, el camino de actualización se rompe.

Paso 3: Definir Tokens con Variables de Figma

Los tokens definidos como Variables de Figma antes de construir cualquier componente son lo que hace que el tema, el cambio de marca y los layouts multimodo sean alcanzables sin tocar los rellenos de los componentes. Un enfoque de capa única - componentes que se vinculan directamente a valores hex en bruto - funciona hasta la primera solicitud de modo oscuro o cambio de marca, en cuyo punto cada relleno debe actualizarse manualmente. El modelo de dos capas (primitivas para escalas en bruto, semánticas para alias basados en roles) significa que un cambio de tema cambia una colección y se propaga instantáneamente. En Atomize, vimos que los equipos redujeron el tiempo de cambio de marca de días a menos de una hora después de migrar a esta estructura. Define primero las primitivas, luego las semánticas, luego vincula los componentes exclusivamente a las semánticas.

Colecciones primitivas

Escalas en bruto sin significado de producto: ‘Primitivas - Color’ (gray/50-950, blue/100-900, red, green), ‘Primitivas - Espacio’ (4, 8, 12, 16, 24, 32, 48, 64 como variables Numéricas), ‘Primitivas - Radio’ (0, 4, 8, 12, 9999). Restringe la edición a los propietarios del sistema.

Colecciones semánticas

Alias de roles de interfaz: ‘Semántica - Color’ con background/default → gray/50 (Claro) / gray/950 (Oscuro), text/primary → gray/950 / gray/50, interactive/default → blue/600, interactive/destructive → red/600. Los componentes se vinculan solo a estas semánticas - eso es lo que hace que los cambios de tema y los cambios de marca sean sobrevivibles sin tocar un solo componente.

Tipografía

Variables Numéricas para tamaño de fuente (12, 14, 16, 20, 24, 32) e interlineado. Emparéjalas con estilos de texto para presets completos (body/md, heading/lg) que referencian los tamaños primitivos para que cambiar la escala base se propague automáticamente.

Paso 4: Construir Componentes Principales

Los componentes construidos sobre una capa de tokens completa son los únicos que sobreviven intactos a un cambio de tema o de marca. Sin tokens en su lugar primero, cada relleno es un valor codificado - y cada uno se convierte en una actualización manual en el momento en que la paleta de marca cambia. El conjunto principal (Botón, pila de Entrada, Controles de selección, Superficie, Navegación, Retroalimentación, Átomos de soporte) cubre el 80% de las pantallas de producto; cada componente usa auto-layout con todos los rellenos, trazos, radios, gaps y padding vinculados a una Variable. Los valores codificados son donde los temas se rompen.

• Botón - variantes de jerarquía (primario, secundario, fantasma, destructivo); variantes de estado (predeterminado, hover, foco, deshabilitado, cargando); props para icono y etiqueta.
• Pila de entrada - etiqueta, campo, texto de sugerencia, mensaje de error como unidad de anatomía de formulario real.
• Controles de selección - casilla de verificación, radio, interruptor, select/desplegable.
• Superficie - tarjeta con relleno configurable y encabezado/pie de página opcional.
• Navegación - barra superior y/o carril lateral dependiendo de la forma de tu producto.
• Retroalimentación - toast, alerta en línea, banner en las cuatro severidades (info, éxito, advertencia, error).
• Átomos de soporte - insignia, etiqueta, avatar.

El paso de vinculación que los equipos más frecuentemente omiten en los componentes principales es el padding. En las auditorías de componentes de Atomize, los rellenos y trazos se vinculan a Variables durante la construcción porque un color incorrecto es visualmente obvio. Los valores de padding se escriben una vez y nunca se revisan - cayendo silenciosamente de la escala de tokens a medida que el sistema de espaciado evoluciona. Un botón con una tokenización de color perfecta y cuatro valores de padding escritos manualmente no responderá a un cambio de modo de Densidad y producirá una salida CSS incorrecta en la primera exportación de tokens. Vincula cada lado de padding y gap a una Variable Numérica antes de publicar.

Paso 5: Variantes vs Propiedades de Componentes

Usar Propiedades de Componentes para booleanos e intercambios de instancias en lugar de multiplicar variantes mantiene el conjunto de componentes lo suficientemente pequeño como para mantenerlo a largo plazo. Las variantes codifican diferencias significativas de layout o jerarquía - primario vs fantasma es una distinción estructural real - pero una variante separada para cada combinación de icono-presente / icono-ausente multiplica el recuento de maestros sin añadir valor de diseño. En la práctica, un Botón con 4 variantes de jerarquía y propiedades booleanas para icono, cargando y ancho completo cubre casi todas las necesidades del producto; la misma cobertura solo via variantes requeriría más de 40 maestros. Menos maestros significa menos frames para actualizar cuando un token o regla de espaciado cambia.

Un botón con 3 variantes de jerarquía × 5 variantes de estado = 15 componentes para mantener actualizados. Tres variantes más propiedades es casi siempre suficiente.

Cuándo usar variantes vs propiedades de componentes

Paso 6: Documentar en el Archivo

La documentación en el archivo se usa; la documentación en una wiki no. Cuando la guía de uso, las notas de accesibilidad y los ejemplos de hacer/no hacer viven en una página de Notion o Confluence separada, los colaboradores dejan de consultarlos bajo presión de plazos - la separación añade fricción exactamente en el momento en que más importa la claridad. Las descripciones de componentes, las descripciones de Variables y una página de Docs dedicada en Figma mantienen la orientación relevante a un clic del componente que se está usando. Los equipos que usan Atomize informan de menos tickets de mal uso después de migrar la documentación al propio archivo de biblioteca.

• Descripción del componente - una frase sobre el propósito; cuándo usar / cuándo no usar; notas de accesibilidad (rol ARIA requerido, comportamiento del teclado); enlace al código.
• Descripción de Variable - intención semántica, par de contraste (ej. ‘text/primary sobre background/default: 7:1 WCAG AAA’), aviso de obsolescencia si aplica.
• Página de Docs - diagramas de anatomía con notas de espaciado, frames de hacer/no hacer, notas de interacción para patrones complejos.
• Anotaciones de frame - usa las herramientas de medición de Figma para indicar los valores de padding, gap y radio para que los desarrolladores no tengan que adivinar.

Paso 7: Publicar la Biblioteca de Equipo

Publicar es lo que convierte un archivo de Figma bien estructurado en un sistema compartido - es el momento en que la biblioteca se vuelve consumible por cada equipo de producto. Hasta la publicacion, incluso un archivo perfectamente organizado no tiene influencia en toda la organizacion; despues de la publicacion, las instancias en los archivos de producto permanecen vinculadas y las actualizaciones aparecen como cambios de biblioteca que los consumidores pueden aceptar en contexto. Ve a Recursos (Shift + I), haz clic en el icono de biblioteca y publica con una descripcion clara de lo que se incluye. Cada publicacion necesita un changelog corto publicado en Slack o Notion el mismo dia: que se anadio, que cambio, que se rompio y como migrar. Una actualizacion de biblioteca sin comunicacion es un ticket de soporte esperando suceder.

Paso 8: Gobernanza y Contribuciones

Un propietario nombrado es la variable única que más determina si una biblioteca publicada se mantiene actualizada o deriva hacia la obsolescencia. Sin uno, las solicitudes de contribución se acumulan sin revisión, los renombrados de tokens ocurren informalmente y la biblioteca gradualmente diverge de la producción - un patrón que Atomize ha visto repetirse en equipos de todos los tamaños. Asigna la propiedad antes de la primera publicación, establece un único camino de admisión (un formulario o plantilla de Notion, no solicitudes ad-hoc de Slack) y usa ramas de Figma para cualquier cambio que pueda romper el trabajo de diseño abierto. Un modelo de gobernanza ligero lleva una hora configurarlo y evita meses de deriva.

• Camino de admisión único - un formulario o plantilla de Notion, no solicitudes ad-hoc de Slack.
• Refactorizaciones arriesgadas en rama - renombrado de tokens, reestructuraciones de layout, consolidación de variantes.
• Poda regular - auditoría trimestral para deprecar componentes no utilizados con una ventana de migración.
• Anunciar el mismo día - publicación en Slack o Notion con cada publicación de biblioteca.

Paso 9: Conectar Tokens al Código

Los tokens que solo existen en Figma significan que ingeniería mantiene un conjunto paralelo, y la deriva entre diseño y código está garantizada. Los nombres de tokens que los componentes referencian en Figma deben resolver los mismos valores en la base de código - de lo contrario, el sistema tiene dos fuentes de verdad y ninguna es autoritativa. La especificacion del Grupo Comunitario de Design Tokens del W3C (DTCG) estandariza el formato JSON de tokens para que las exportaciones puedan alimentar cualquier canalizacion compatible con DTCG sin parsers personalizados, como las que genera Style Dictionary. Atomize exporta Variables a JSON, propiedades personalizadas CSS o TypeScript para que el repositorio importe un artefacto que rastrea cada lanzamiento de biblioteca; cuando el sistema publica, el archivo de tokens tambien se actualiza.

Errores que Deshacen el Trabajo

• Componentes antes de tokens - el costo de tema y cambio de marca se multiplica con cada valor codificado.
• Alcance excesivo el día uno - lanza tokens más cinco componentes más una publicación, luego amplía según el uso real.
• Componentes no documentados - la tasa de mal uso escala con el tamaño del equipo y el tiempo desde la publicación.
• Sin propietario nombrado - las bibliotecas sin mantenedor derivan hacia la inconsistencia en meses.
• Sistema solo de diseño - los tokens que nunca llegan al código significan que ingeniería mantiene un conjunto paralelo.

Lectura Relacionada

• ¿Qué Es un Sistema de Diseño en Figma? - conceptos, componentes, tokens y cuándo empezar
• Design Tokens de Figma: La Guía Completa - Variables, capas primitiva/semántica, modos y DTCG
• Coverage Audit vs Valores No Tokenizados - puntuación de vinculación vs deriva de literales; ejecutar antes de la auditoría de contraste
• Encontrar Valores No Tokenizados en Figma - audita la vinculación antes de publicar la librería
• Plugins de Figma para Tokens, Git Sync y Flujos de Trabajo de Diseño - elegir entre plugins de exportación, sincronización Git y changelog
• Mejores Prácticas del Sistema de Diseño de Figma - gobernanza, accesibilidad, nomenclatura y adopción

Veredicto final - Construir un Sistema de Diseño en Figma

Un sistema de diseño de Figma construido en el orden correcto - auditoría, tokens, componentes, gobernanza, sincronización de código - se acumula con cada lanzamiento en lugar de acumular deuda. Los dos modos de fallo que deshacen el trabajo son componentes construidos sin tokens y una biblioteca sin un propietario nombrado; ambos son errores de secuenciación, no técnicos. Empieza con el mínimo viable (tokens semánticos, cinco componentes principales, biblioteca publicada, propietario nombrado, exportación de tokens), lánzalo en dos a cuatro semanas y crécelo basándote en el uso real. El sistema es un producto; trátalo como tal.