De Prompt a Componente: Mi Workflow de Figma a Código con IA

¿Cuántas horas has pasado con Figma en una pantalla y el editor en otra, traduciendo píxeles a CSS? "Esto parece un flex con gap-4", "este color será el brand-500", "este padding... ¿16 o 20?". Ese ejercicio de traducción manual — lento, repetitivo y propenso a errores — es exactamente lo que este workflow de Figma a código con IA elimina.

Hoy mi proceso es otro. Diseño en Figma, conecto el archivo con Claude Code a través de Figma MCP, y obtengo componentes que ya hablan el idioma de mi stack. No código genérico de tutorial, sino código que usa mis tokens, mis componentes base y mis convenciones. Lo que antes tardaba 2 horas de traducción mecánica, ahora son 15 minutos de revisión y ajuste fino.

No es magia. Es un pipeline con cuatro pasos claros. Te explico exactamente cómo funciona, cuándo brilla y dónde tiene límites.

El workflow completo: de Figma a componente en cuatro pasos

El flujo es lineal: Figma → Figma MCP → Claude Code → Componente de producción.

Cada paso tiene una responsabilidad concreta:

1. Figma — Diseñar con estructura que la IA pueda leer
2. Figma MCP — Extraer el contexto de diseño (tokens, jerarquía, propiedades)
3. Claude Code — Adaptar ese contexto a tu stack real
4. Tú — Revisar, refinar y decidir qué se queda

El humano toma las decisiones. La IA elimina la traducción mecánica — la parte que más tiempo consume y menos valor aporta.

Frame 47
  Rectangle 12
  Text 8
  Group 3
    Rectangle 14
    Text 9

hero-section
  background-gradient
  heading-primary
  cta-container
    cta-button
    cta-label

Paso 1: Diseñar en Figma con estructura (la base de todo)

Este es el paso que más gente subestima. Si tu archivo de Figma es un caos de frames sin nombres, con auto-layout inconsistente y colores hardcodeados, la IA va a generar caos equivalente. Basura entra, basura sale.

Lo que hago diferente:

• Nombrar las capas con intención. No "Frame 427" sino "card-header", "price-badge", "cta-primary". Los nombres de las capas se convierten directamente en nombres de componentes y sus partes.
• Usar auto-layout en todo. Auto-layout no es solo para que Figma se comporte bien — es información semántica. Un frame con auto-layout vertical, gap de 16 y padding de 24 le dice a la IA exactamente qué layout generar.
• Design tokens reales. Colores como variables, tipografía como estilos, espaciado consistente. Si usas #3B82F6 suelto en vez de tu variable brand-500, la IA no puede mapear al token correcto.
• Componentes con variantes. Un botón con variantes (primary, secondary, ghost) se traduce limpiamente a props. Un botón con 6 frames desconectados se traduce a 6 bloques de código duplicado.

La regla es simple: si un humano no puede entender tu archivo de Figma, una IA tampoco.

Paso 2: Figma MCP extrae el contexto de diseño

Aquí pasa lo interesante a nivel técnico. Figma MCP es un servidor que conecta tu archivo de Figma directamente con Claude Code a través del Model Context Protocol.

Cuando uso get_design_context, no estoy haciendo un screenshot. Estoy extrayendo datos estructurados:

• Jerarquía de componentes — qué frame contiene qué, cómo se anidan los elementos
• Propiedades de layout — dirección, gap, padding, alignment, constraints
• Tokens de diseño — colores (como variables, no hex sueltos), tipografía, sombras, bordes
• Variantes y estados — hover, active, disabled, cada variante del componente
• Texto real — el contenido, no Lorem Ipsum

Es la diferencia entre darle a un desarrollador una captura de pantalla y darle un archivo de especificaciones completo. El MCP le da al agente la misma información que verías en el panel de inspección de Figma, pero en un formato que puede procesar programáticamente.

Paso 3: Claude Code adapta el diseño a tu stack

Aquí es donde este workflow se separa de cualquier "Figma to code" genérico. Claude Code no genera React genérico — genera código que encaja en tu proyecto.

¿Por qué? Porque tiene acceso al contexto de tu codebase. Sabe que:

• Usas Tailwind CSS v4 con variables CSS en OKLCh
• Tu sistema de diseño tiene un componente Button con variantes específicas
• Los colores se referencian como bg-brand-500, no como bg-blue-500
• El spacing sigue una escala de 4px
• Los componentes usan "use client" solo cuando hay interactividad real

Esto no es configuración manual. Claude Code lee tu CLAUDE.md, tus archivos de configuración, tus componentes existentes. Y cuando recibe el contexto de Figma, hace el mapeo automáticamente.

<div style={{ padding: "24px", background: "#fff" }}>
  <img style={{ borderRadius: "8px" }} />
  <div style={{ color: "#1a1a1a" }}>Título</div>
  <div style={{ color: "#666" }}>Descripción</div>
</div>

La diferencia no es cosmética — es la diferencia entre código que necesitas reescribir y código que puedes usar directamente.

Paso 4: Revisar, refinar y enviar a producción

Ningún código generado debería ir directo a producción sin revisión. Pero hay una diferencia enorme entre revisar código que necesitas reescribir al 80% y código que necesita ajustes al 10%.

Mi checklist de revisión:

1. ¿Usa los componentes correctos? Si generó un <div> donde debería haber un <Button>, lo corrijo
2. ¿Los tokens son correctos? A veces mapea un color similar pero no el exacto
3. ¿La responsividad tiene sentido? Figma es estático, el código necesita adaptarse
4. ¿La accesibilidad está cubierta? Roles ARIA, contraste, navegación por teclado
5. ¿Los estados interactivos funcionan? Hover, focus, animaciones de transición

Estos ajustes son incrementales, no reescrituras. El 80-90% del trabajo mecánico ya está hecho. Tu tiempo se invierte en decisiones que requieren criterio humano, no en traducción mecánica.

Cuándo funciona y cuándo tiene límites

Este workflow brilla con:

• Componentes de UI estructurados — Cards, formularios, navegación, dashboards. Todo lo que tiene estructura clara y repetible.
• Design systems establecidos — Si ya tienes tokens y componentes base, la IA los reutiliza de forma consistente.
• Iteración rápida — Necesitas probar 3 variantes de un componente: generar las 3 y elegir es más rápido que construir cada una a mano.
• Prototipado funcional — De concepto en Figma a prototipo interactivo en horas, no días.

Tiene límites con:

• Animaciones complejas — Micro-interacciones elaboradas, transiciones multi-paso, animaciones basadas en scroll. Figma no captura esta información y la IA tiene que adivinar.
• Layouts experimentales — Si tu diseño rompe convenciones (grids irregulares, overlapping creativo), la IA tiende a "normalizarlo".
• Lógica de negocio — El workflow cubre diseño a UI. La lógica de datos, validación y estado sigue necesitando implementación deliberada.
• Archivos de Figma desordenados — Si tus frames se llaman "Frame 1", "Copy of Frame 1 (2)", el output va a ser igual de caótico. Basura entra, basura sale.

Cómo preparar Figma para que la IA entienda tu diseño

Después de meses con este workflow, estos son los patrones que más diferencia hacen:

Nombres semánticos, siempre. hero-section, pricing-card, nav-primary — no Frame 427. Los nombres se convierten en nombres de componentes y variables.

Auto-layout como lenguaje. Cada frame debería tener auto-layout. La dirección, el gap y el padding son información directa para el CSS. Un frame sin auto-layout es un position: absolute esperando a ocurrir.

Variables de color, no hex sueltos. Si tu Figma usa variables de color, el MCP puede mapearlas a tus tokens CSS. Si usa colores hardcodeados, la IA tiene que adivinar.

Componentes con variantes limpias. Un componente con variantes bien definidas (size: sm/md/lg, variant: primary/secondary) se traduce directamente a props de TypeScript.

Un frame = un componente. Si puedes señalar un frame y decir "esto es un componente independiente", la IA puede extraerlo limpiamente. Si tu "componente" está repartido en 3 frames desconectados, el resultado va a ser fragmentado.

Texto real, no placeholder. "Lorem ipsum" le quita contexto a la IA. Contenido real — aunque sea aproximado — ayuda al agente a inferir el propósito de cada elemento.

En la práctica: un ejemplo real

La semana pasada necesitaba una tarjeta de pricing con tres tiers para un proyecto de cliente. En Figma, diseñé la estructura: tres variantes (basic, pro, enterprise) con auto-layout, tokens de color, y nombres semánticos en cada capa.

Conecté el archivo con Figma MCP, le pedí a Claude Code que generara el componente, y en menos de 10 minutos tenía un PricingCard con variantes tipadas, responsive, usando mis tokens de Tailwind y mis componentes Badge y Button existentes. Los ajustes que hice: cambiar un border-radius y ajustar el spacing en mobile. Dos líneas.

Ese mismo componente, construido a mano leyendo las specs en Figma, me habría tomado entre 45 minutos y una hora. No estoy exagerando — cronometré ambos procesos durante un mes.

El diseño se vuelve más valioso, no menos

La narrativa de "la IA va a reemplazar a los diseñadores" es un marco simplista para una realidad más interesante. Lo que este workflow elimina es la capa de traducción — esas horas de mirar Figma y escribir mecánicamente el CSS equivalente. Eso no es diseñar. Eso no es desarrollar. Es trabajo mecánico.

Lo que queda es el trabajo que realmente importa:

• Decisiones de diseño — qué layout comunica mejor la jerarquía, cómo guiar la atención, qué interacción se siente natural
• Decisiones de arquitectura — cómo estructurar componentes para que escalen, qué abstraer, qué mantener simple
• Decisiones de producto — qué construir, para quién, y por qué

Cuando la traducción desaparece, el diseño ocupa más espacio, no menos. Y eso es bueno para todos.

Este es el cuarto artículo de la serie. El primero fue sobre las herramientas que uso. El segundo sobre por qué fallan y cómo arreglarlo. El tercero sobre cómo construir un sistema de skills. Este cierra el puente entre diseño y desarrollo — el punto donde la IA más fricción puede eliminar.