Cómo Construyo Sistemas de Diseño de Producción Con Figma Make
El mes pasado abrí el dashboard de un cliente y conté cinco tonos diferentes de azul. Tres estilos de botones que cumplían el mismo propósito. Dos componentes de tarjeta completamente diferentes ubicados uno al lado del otro en la misma página. La aplicación funcionaba bien. Simplemente parecía como si cuatro diseñadores diferentes hubieran construido cada uno una cuarta parte sin hablar nunca entre ellos.
Eso es lo que pasa cuando te saltas el sistema de diseño.
He entregado proyectos sin uno. Al principio de mi carrera, pensaba que los sistemas de diseño eran una carga — algo que los equipos empresariales con departamentos de diseño dedicados necesitaban, no los desarrolladores independientes o las pequeñas agencias que construyen rápido. Estaba equivocado, y cada proyecto que construí sin uno eventualmente me castigó por ello. Las inconsistencias se cuelan lentamente. Un border radius ligeramente diferente aquí. Un peso de fuente que no coincide allá. Para el tercer mes, la interfaz parece una colcha de retazos cosida por un comité, y cada nueva funcionalidad requiere que tomes cincuenta micro-decisiones que deberían haberse tomado una sola vez.
El problema nunca fue la motivación. El problema fue el tiempo. Construir un sistema de diseño apropiado desde cero toma días — catalogar colores, definir escalas tipográficas, diseñar estados de componentes, documentar reglas de espaciado. Días que no tenía en plazos ajustados.
Entonces encontré un flujo de trabajo que reduce ese plazo de días a horas usando Figma Make, y cambió cómo abordo cada nuevo proyecto. La trampa es que la salida generada por IA es un punto de partida, no una línea de meta, y la brecha entre "generado" y "listo para producción" es donde la mayoría de los sistemas de diseño de las personas se desmoronan. Te mostraré exactamente dónde vive esa brecha y cómo cerrarla, pero primero — el paso de preparación que el 90% de los tutoriales omiten por completo.
El Trabajo Antes del Trabajo
Esto es lo que veo que los desarrolladores hacen mal constantemente: abren Figma, se quedan mirando un lienzo en blanco y empiezan a diseñar. Sin referencias. Sin inventario de componentes. Sin una imagen clara de qué páginas realmente necesitan.
Eso es como escribir código sin requisitos. Producirás algo, pero probablemente no será lo que el proyecto necesita.
Antes de tocar cualquier herramienta de diseño, construyo tres cosas:
Un inventario de páginas. Cada pantalla que la aplicación necesita, listada. No wireframeada, no diseñada — solo nombrada y descrita. "Dashboard — muestra KPIs, feed de actividad reciente y botones de acción rápida." "Configuración — edición de perfil de usuario, preferencias de notificación, gestión de cuenta." "Tabla de datos — filtrable, ordenable, con edición en línea y acciones en lote."
Esto suena básico porque lo es. Pero he visto a equipos saltarse esto y terminar diseñando páginas que no necesitan mientras olvidan páginas que sí necesitan.
Un censo de componentes. Para cada página del inventario, listo cada componente de UI que esa página requiere. El dashboard necesita: tarjetas de estadísticas, elementos del feed de actividad, botones de acción, una barra de navegación, una barra lateral. La tabla de datos necesita: encabezados de tabla, columnas ordenables, paginación, chips de filtro, modales de edición, estados vacíos, skeletons de carga.
Escribir esta lista te obliga a ver patrones antes de haber diseñado nada. Las tarjetas de estadísticas y las celdas de la tabla de datos ambas necesitan tipografía consistente. Los chips de filtro y los botones de acción ambos necesitan estados definidos. El censo de componentes es donde el alcance de tu sistema de diseño se vuelve visible.
Un mood board con propósito. No un tablero de Pinterest de interfaces bonitas. Una colección estructurada de referencias visuales organizadas por tipo de componente y disposición de página. Uso mucho mobin.com para esto — agrega ejemplos reales de UI de cientos de empresas, así que estás referenciando diseños de producción, no arte conceptual.
Mis mood boards están organizados en secciones: "Referencias de navegación," "Referencias de disposición de tablas," "Referencias de componentes de tarjetas," "Referencias de disposición de dashboard." Cada sección tiene 4-6 capturas de pantalla mostrando diferentes enfoques del mismo componente o patrón de disposición.
Este trabajo de preparación toma aproximadamente una hora. Ahorra diez horas más adelante. Cuando eventualmente le pido a Figma Make que genere páginas, las instrucciones son lo suficientemente específicas como para producir una salida útil en el primer intento en lugar del tercero.
Esa especificidad lo es todo cuando trabajas con herramientas de diseño con IA. Déjame mostrarte por qué.
Generando Páginas de UI Que No Parecen Generadas por IA
Figma Make es una herramienta de generación de diseño impulsada por IA que vive dentro de Figma. Describes lo que quieres y produce archivos de diseño editables — layouts, componentes, páginas completas. La calidad de la salida varía desde "sorprendentemente buena" hasta "necesita retrabajo significativo" dependiendo enteramente de cómo la prompteas.
Mi flujo de trabajo genera páginas en una secuencia específica porque cada página construye contexto para la siguiente.
Navegación primero. La barra de navegación o barra lateral aparece en cada página, así que establece el tono visual para toda la aplicación. Prompteo a Figma Make con referencias de mi mood board: "Genera una navegación lateral con estas secciones: Dashboard, Proyectos, Analíticas, Equipo, Configuración. Referencia de estilo: [descripción de los ejemplos del mood board que me gustaron]. Incluye estados colapsado y expandido."
La primera generación generalmente acierta con la estructura y acierta en un 70% con el estilo. Ajusto colores, modifico el espaciado y refino las opciones de iconos manualmente. Esto toma aproximadamente quince minutos y produce un componente de navegación que reutilizaré en cada página.
Dashboard segundo. Con el componente de navegación establecido, la página del dashboard tiene un ancla visual. Mi prompt incluye los componentes específicos de mi censo: "Genera una página de dashboard con: 4 tarjetas de estadísticas KPI en la parte superior, un feed de actividad en la columna izquierda, un panel de acciones rápidas a la derecha, y un gráfico mostrando tendencias semanales. Usa el estilo del componente de navegación ya establecido."
Figma Make produce un layout con estructura real — no una cuadrícula genérica, sino un arreglo pensado que generalmente solo necesita un reposicionamiento menor. Las tarjetas de estadísticas vienen con una jerarquía de información sensata. El feed de actividad tiene un espaciado razonable entre elementos.
Páginas con muchos datos tercero. Las tablas son donde la mayoría de los diseños generados por IA tropiezan, porque las tablas tienen más estados que cualquier otro componente: predeterminado, hover, seleccionado, editando, cargando, vacío, error, filtrado, ordenado ascendente, ordenado descendente. Prompteo cada estado explícitamente.
"Genera una página de tabla de datos con: encabezados de columna ordenables, estados hover de fila, modo de edición en línea para la columna 'estado', una barra de filtro con filtros activos estilo chip, paginación con selector de tamaño de página, un estado vacío para cero resultados, y un estado de skeleton de carga."
Esto produce múltiples artboards en Figma — uno para cada estado. No todos son perfectos, pero tener los estados generados como punto de partida ahorra un tiempo enorme comparado con construir cada uno manualmente.
Tarjetas, modales y componentes secundarios al final. Para este punto, el lenguaje visual está establecido a través de la navegación, el dashboard y las páginas de tabla. Los componentes secundarios heredan ese lenguaje naturalmente.
Algo de lo que quiero ser honesto: Figma Make no produce diseños de producción pixel-perfect. Produce primeros borradores sólidos. Los layouts son consistentes. Las relaciones entre componentes tienen sentido. La jerarquía visual generalmente es correcta. Pero los detalles — valores exactos de padding, elecciones específicas de peso de fuente, variaciones sutiles de color entre estados interactivos — esos necesitan refinamiento humano.
Dedico aproximadamente el 30% de mi tiempo de diseño generando con Figma Make y el 70% refinando. Esa proporción puede sonar como si la IA no estuviera ahorrando mucho, pero considera: el 30% reemplaza lo que solía ser el 60-70% del cronograma (crear layouts iniciales desde cero). La fase de refinamiento es más rápida y enfocada porque estás puliendo, no construyendo.
Las páginas están listas. Ahora viene la parte que la mayoría de la gente hace al revés.
Construyendo el Sistema de Diseño Después de las Páginas (No Antes)
Esto va a sonar contraintuitivo. La sabiduría convencional dice: construye tu sistema de diseño primero, luego diseña las páginas usando esos componentes del sistema. Ese es el enfoque de libro de texto, y para equipos grandes con ingenieros de sistemas de diseño dedicados, funciona.
Para desarrolladores independientes y equipos pequeños, he encontrado que el orden opuesto funciona mejor. Diseña las páginas primero (con asistencia de IA), luego extrae el sistema de diseño de los patrones que emergen.
¿Por qué? Porque diseñar las páginas primero te da contexto de uso del mundo real. Ves qué componentes realmente aparecen en múltiples páginas (esos van al sistema) versus cuáles son únicos (esos no). Ves qué valores de color realmente usaste repetidamente versus cuáles fueron acentos de una sola vez. El sistema de diseño se convierte en un reflejo de necesidades reales, no una biblioteca especulativa de componentes que podrías usar algún día.
Después de que mis páginas están refinadas, prompteo a Figma Make para generar lo que llamo un Sistema de Diseño Mínimo Viable (MVDS):
"Basándote en las páginas de UI que he creado, genera un sistema de diseño que incluya: paleta de colores con valores primario, secundario, neutro, éxito, advertencia y error; escala tipográfica con niveles de encabezado H1-H6, texto de cuerpo, subtítulos y etiquetas; escala de espaciado; valores de border radius; y componentes principales — botones (primario, secundario, ghost, destructivo) con todos los estados (predeterminado, hover, activo, deshabilitado, cargando), campos de entrada (predeterminado, enfocado, error, deshabilitado), tarjetas, badges, tamaños de avatar y estilos de celda de tabla."
La salida del MVDS de Figma Make es genuinamente útil. No completa, pero útil. Los colores coinciden con los que realmente usé en los diseños de página. La escala tipográfica refleja las relaciones reales entre encabezados. Los componentes tienen el ADN visual correcto.
Lo que le falta — y esto es predecible — son los casos límite. Cajas de alerta, notificaciones toast, estados vacíos, patrones de carga, componentes de filtro, variantes de paginación, estructuras de modales con diferentes tipos de contenido. Estos necesitan un segundo pase de generación.
"Extiende el sistema de diseño con: componentes de alerta (info, éxito, advertencia, error con variantes descartables y persistentes), notificaciones toast, spinners de carga y pantallas skeleton, ilustraciones de estado vacío, paginación con números de página y variantes de cargar más, shells de modal para diálogos de confirmación y modales de formulario, y menús desplegables con búsqueda."
Este segundo pase produce un sistema más detallado, pero aquí va una advertencia práctica: los sistemas de diseño muy detallados pueden ser demasiado grandes para la importación directa en algunas herramientas de desarrollo. Si planeas empujar esto a un codebase a través de la exportación de código de Figma, divide el sistema en partes — fundamentos (colores, tipografía, espaciado), componentes principales (botones, inputs, tarjetas) y componentes complejos (tablas, modales, navegación) — e importarlos por separado.
Aprendí esto después de una importación fallida que crasheó mi entorno de desarrollo porque el archivo de design tokens tenía 3,000 líneas. Dividirlo en partes lo arregló inmediatamente.
Del Diseño al Código Sin Perder la Cabeza
Aquí es donde el flujo de trabajo se bifurca, y qué camino tomes depende de la configuración de tu equipo.
Camino A: Exportación directa de código para desarrolladores independientes.
Figma Make puede generar código de salida a partir de tus diseños. Para proyectos de React, Vue o HTML/CSS vanilla, esto ahorra tiempo legítimamente — obtienes código de componentes que coincide con tu diseño visual sin traducir manualmente píxeles a CSS.
Pero — y esto es crítico — el código generado tendrá valores hardcodeados en todas partes. color: #3B82F6 en lugar de var(--color-primary). font-size: 16px en lugar de var(--text-body). padding: 24px en lugar de var(--space-6).
Entregar valores hardcodeados es deuda técnica disfrazada de velocidad. El momento en que un cliente dice "¿podemos hacer el color primario un poco más oscuro?" estarás haciendo un buscar y reemplazar en cincuenta archivos en lugar de cambiar una variable.
Antes de enviar cualquier código de Figma Make a tu repositorio, ejecuta un pase de refactorización para convertir los valores hardcodeados en design tokens. Prompteo a Figma Make para esto explícitamente: "Refactoriza este código de componente para usar CSS custom properties para todos los valores de color, tipografía, espaciado y border radius. Genera un archivo de design tokens correspondiente que defina estas variables."
La salida necesita revisión — la IA a veces crea tokens redundantes o nombra mal las variables — pero maneja el 80% de la conversión correctamente. El 20% restante es limpieza manual rápida.
Pro tip: Establece tu convención de nomenclatura de tokens antes del pase de refactorización e inclúyela en el prompt. "Usa el formato --color-[nombre-semántico] para colores, --text-[nombre-tamaño] para tipografía, --space-[número-escala] para espaciado." Una nomenclatura consistente desde el inicio previene el caos de nomenclatura de tokens más adelante.
Camino B: Handoff de Figma para equipos.
Si trabajas con otros desarrolladores o un equipo de diseño, el camino de exportación de código crea conflictos de merge y confusión de propiedad. En su lugar, mantén todo en Figma como la fuente de verdad.
Organiza tu archivo de Figma con una estructura clara:
- Página 1: Sistema de Diseño — fundamentos y componentes
- Página 2: Pantallas de UI — todas las páginas de la aplicación
- Página 3: Estados de Componentes — documentación de estados interactivos
- Página 4: Notas de Handoff — anotaciones para desarrolladores
Comparte el archivo de Figma con tu equipo. Itera colaborativamente. Cuando los diseños estén finalizados, los desarrolladores pueden usar las herramientas de inspección de Figma o Figma MCP para reconstruir los componentes en el framework de su elección con el sistema de diseño como referencia.
Este camino es más lento pero produce menos dolores de cabeza de integración en equipos de varias personas. El sistema de diseño vive en un solo lugar, todos referencian la misma fuente, y los cambios se propagan a través del archivo de Figma en lugar de a través de PRs de código.
Uso el Camino A para mis proyectos en solitario y trabajo con clientes donde soy el único desarrollador. Uso el Camino B para proyectos de agencia en Ramlit donde múltiples desarrolladores necesitan implementar los mismos diseños. Ambos funcionan. Ninguno es universalmente mejor.
Los Errores Que Sigo Viendo (Incluyendo los Míos)
Déjame ahorrarte algo de dolor catalogando los fracasos que he experimentado y observado.
Error 1: Tratar la salida de la IA como final. He visto a desarrolladores exportar el código generado por Figma Make directamente a producción sin un pase de refinamiento. La UI funciona pero se siente extraña — espaciado inconsistente, relaciones de color ligeramente incorrectas, componentes que no terminan de alinearse entre sí. El diseño generado por IA es un borrador. Siempre un borrador. La fase de refinamiento no es un pulido opcional; es donde el diseño se vuelve profesional.
Error 2: Construir demasiado sistema de diseño demasiado temprano. Mi primer intento de un MVDS incluía 47 variantes de componentes. Usé 12 de ellas en el proyecto real. Las otras 35 quedaron sin usar, desordenando el sistema y confundiendo el archivo de design tokens. Empieza mínimo. Agrega componentes cuando una página realmente los necesite, no cuando imagines que una página futura podría necesitarlos.
Error 3: Saltarse el mood board. Cuando tengo prisa, siento la tentación de saltarme la recopilación de inspiración e ir directamente a promptear. La calidad de la salida baja notablemente. Figma Make funciona significativamente mejor cuando tus prompts referencian patrones visuales específicos: "tabla con encabezados fijos como Notion" versus "genera una tabla." El mood board no es decoración — es ingeniería de prompts para IA visual.
Error 4: Ignorar los estados responsive. Figma Make genera layouts de escritorio por defecto. Si tu aplicación necesita layouts para móvil o tablet — y en 2026, lo necesita — necesitas promptear explícitamente para esos breakpoints. Yo genero escritorio primero, luego prompteo: "Crea variantes responsive de esta página para tablet (768px) y móvil (375px), ajustando el layout mientras mantienes los mismos estilos de componentes." Las variantes móviles generalmente necesitan más ajuste manual que las de escritorio, pero partir de un layout generado supera partir de la nada.
Error 5: Olvidar el modo oscuro. Si tu aplicación soporta modo oscuro — y cada vez más, los usuarios lo esperan — genera tus design tokens con ambos valores, claro y oscuro, desde el inicio. Adaptar el modo oscuro retroactivamente a un sistema de tokens existente es doloroso. Lo sé porque lo he hecho tres veces, y cada vez juré que me acordaría de incluirlo desde el principio. Finalmente lo hice en el cuarto proyecto.
Qué Cambia Cuando Trabajas de Esta Forma
Después de usar este flujo de trabajo en ocho proyectos durante seis meses, las diferencias medibles son claras.
El tiempo de handoff de diseño a desarrollo se redujo aproximadamente un 60%. Los mayores ahorros vinieron de eliminar la fase del lienzo en blanco. Partir de layouts generados por IA y estados de componentes en lugar de artboards vacíos comprime la fase creativa sin sacrificar calidad — siempre y cuando inviertas en la fase de refinamiento.
La consistencia de la UI mejoró en cada proyecto. Incluso el MVDS — la versión mínima — impone suficiente consistencia para eliminar la apariencia de "construido por un comité". Los clientes lo notan. He tenido dos clientes separados comentar que la interfaz se siente "más pulida de lo esperado" en proyectos donde usé este flujo de trabajo. No pueden articular qué es diferente, pero sienten la coherencia.
La reutilización de componentes entre proyectos se volvió práctica. Cuando tus sistemas de diseño siguen la misma estructura de tokens y convención de nomenclatura, los componentes del Proyecto A se transfieren al Proyecto B con un ajuste mínimo. Mi componente de botón, mi componente de tarjeta, mis estilos de tabla — han sido refinados a lo largo de ocho proyectos. Cada iteración es mejor que la anterior, y levantar la base visual para un nuevo proyecto toma horas en lugar de días.
La conversación de diseño con los clientes cambió. Antes de este flujo de trabajo, las revisiones tempranas de diseño frecuentemente se trataban de arreglar inconsistencias: "Estas dos páginas no se sienten como la misma app." Ahora las conversaciones se enfocan en preguntas estratégicas: "¿Debería el dashboard priorizar el feed de actividad o los KPIs?" Eso es un uso mucho más productivo del tiempo de todos.
Las victorias rápidas aparecen en el primer proyecto — generación de páginas más rápida, salida más consistente. El beneficio compuesto aparece alrededor del tercer o cuarto proyecto, cuando tus componentes refinados y convenciones de tokens establecidas comienzan a pagar dividendos recurrentes.
Los Sistemas de Diseño Son Infraestructura, No Decoración
Hay un cambio de mentalidad enterrado en todo este flujo de trabajo que quiero hacer explícito, porque es lo que más tardé en internalizar.
Un sistema de diseño no es un entregable agradable que creas con fines de documentación. Es infraestructura. Es la base sobre la que se sostiene cada decisión visual en tu aplicación. Cuando la base es sólida, cada página que construyes encima es más rápida, más consistente y más fácil de mantener. Cuando la base falta, cada página es un proyecto de construcción aislado con sus propias reglas.
Las herramientas de IA como Figma Make han hecho que construir esa infraestructura sea dramáticamente más rápido. Lo que solía ser una inversión de varios días — y por lo tanto fácil de saltarse bajo la presión de los plazos — ahora es unas pocas horas de trabajo enfocado. El cálculo de costo-beneficio ha cambiado. Saltarse el sistema de diseño ya no ahorra un tiempo significativo, pero la deuda que crea es exactamente la misma que siempre fue.
Mi desafío para ti es específico: elige tu próximo proyecto — el que está en tu pipeline ahora mismo. Antes de escribir una sola línea de código frontend, dedica una mañana a este flujo de trabajo. Recopila tu inspiración. Genera tus páginas. Extrae tu MVDS. Configura tus design tokens.
Cuando empieces a construir la UI con esa base debajo de ti, presta atención a lo diferente que se siente. Presta atención a cuántas decisiones ya están tomadas. Presta atención a lo rápido que te mueves cuando no estás reinventando el espaciado y las opciones de color en cada componente.
¿Esa sensación? Eso es lo que se siente entregar con un sistema. Y una vez que lo has sentido, no volverás a la colcha de retazos.
Trabajemos Juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (builds personalizados e integraciones): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
