Pierdi la cuenta de cuántas veces un diseñador me ha entregado un hermoso archivo de Figma y me ha dicho: "Debería ser bastante sencillo de construir, ¿verdad?" Y claro, la sección hero se ve lo suficientemente simple. Pero luego empiezas a profundizar en el comportamiento receptivo, estados hover que no fueron completamente especificados, espaciado que cambia entre frames, y un sistema de diseño que existe en la cabeza del diseñador pero en ningún lugar en el código. La brecha entre una maqueta de Figma y un sitio web Next.js de producción es donde los proyectos se descarrilan.

Después de construir docenas de proyectos de Figma a Next.js en Social Animal, he desarrollado opiniones firmes sobre qué funciona y qué no. Esta guía te lleva a través de todo el proceso — no la versión teórica, sino la versión desordenada y del mundo real donde los diseños no son perfectos, los stakeholders cambian de opinión, y necesitas enviar algo que realmente funcione bien en producción.

Figma to Next.js: The Complete Guide to Turning Designs Into Code

Tabla de Contenidos

Por qué Next.js para proyectos de Figma a Código

Podrías convertir diseños de Figma en HTML plano. Podrías usar Astro, Remix, o SvelteKit. Entonces, ¿por qué Next.js?

Algunas razones que importan en la práctica:

  • El modelo de componentes React se mapea directamente a componentes de Figma. Los diseñadores piensan en componentes. React piensa en componentes. Esta alineación no es trivial — significa que tu árbol de componentes en código puede reflejar la jerarquía de componentes en Figma, lo que hace que el mantenimiento sea mucho más fácil.
  • App Router con Server Components te da la flexibilidad de renderizado que tanto sitios de marketing como aplicaciones web necesitan. ¿Páginas estáticas? ¿Contenido dinámico renderizado en servidor? ¿Interactividad del lado del cliente? Tú eliges por ruta.
  • La optimización de imágenes está integrada. El componente next/image maneja imágenes receptivas, carga perezosa y conversión de formato — cosas que de otra manera consumirían horas de tu tiempo de construcción.
  • El ecosistema es masivo. Lo que sea que el diseño requiera — autenticación, formularios, animaciones, integración con CMS — hay una solución bien mantenida en el ecosistema de Next.js.

Usamos Next.js para la mayoría de nuestros proyectos de desarrollo de CMS headless exactamente por estas razones. Si tienes curiosidad sobre cuándo Astro podría ser una mejor opción (pista: sitios con mucho contenido y interactividad mínima), consulta nuestra página de desarrollo con Astro.

Auditoría del archivo Figma antes de escribir código

Este es el paso que la mayoría de los desarrolladores omiten, y es el paso que más tiempo ahorra. Antes de escribir una sola línea de JSX, dedica 30-60 minutos auditando el archivo Figma.

Qué verificar

  • Uso de Auto Layout. Si el diseñador utilizó Auto Layout consistentemente, tu vida se vuelve dramáticamente más fácil. Auto Layout se mapea casi 1:1 a flexbox. Si no lo hizo, estarás adivinando el espaciado y comportamiento receptivo.
  • Consistencia de componentes. ¿Los botones están realmente usando un componente compartido, o el diseñador creó 14 variantes de botón ligeramente diferentes en frames? Abre el panel de Assets y verifica.
  • Estilos nombrados y variables. Las Figma Variables (lanzadas en 2023, ampliamente adoptadas en 2025) deben definir colores, espaciado, tipografía y radios de borde. Si existen, la extracción de tokens de diseño está mayormente automatizada. Si no, señálalo antes de empezar a construir.
  • Frames receptivos. ¿El diseño incluye puntos de quiebre para móvil, tablet y escritorio? Si es solo escritorio, necesitas una conversación con el diseñador antes de proceder.
  • Estados faltantes. Hover, focus, active, disabled, loading, error, empty — verifica si los componentes interactivos tienen todos sus estados diseñados. Usualmente no los tienen. Haz una lista.

La conversación de entrega

Siempre programo una llamada de 30 minutos con el diseñador antes de comenzar la implementación. Compartimos pantalla el archivo Figma y revisamos:

  1. Qué componentes son reutilizables vs. únicos
  2. Cómo debería funcionar el comportamiento receptivo (no asumas — pregunta)
  3. Cualquier animación o transición que tengan en mente
  4. Contenido que vendrá de un CMS vs. hardcoded

Esta única reunión elimina el 80% del ir y venir que típicamente plaga los proyectos de diseño a código.

Figma to Next.js: The Complete Guide to Turning Designs Into Code - architecture

Extrayendo Design Tokens de Figma

Los design tokens son el puente entre Figma y código. Colores, escalas de tipografía, unidades de espaciado, radios de borde, sombras — estos necesitan ser extraídos sistemáticamente, no adivinados.

Extracción manual (proyectos pequeños)

Para proyectos más pequeños, usaré Figma's Dev Mode (incluido en planes pagos de Figma a $25/asiento/mes en 2025) para inspeccionar valores directamente. Abre Dev Mode, haz clic en cualquier elemento, y obtendrás valores exactos en píxeles, colores y propiedades de fuente.

Luego mapeo estos a configuración de Tailwind CSS o propiedades CSS personalizadas:

// tailwind.config.ts
import type { Config } from 'tailwindcss'

const config: Config = {
  theme: {
    extend: {
      colors: {
        brand: {
          50: '#f0f4ff',
          100: '#dbe4ff',
          500: '#4c6ef5',
          600: '#3b5bdb',
          700: '#364fc7',
          900: '#1c2d7a',
        },
        surface: {
          primary: '#ffffff',
          secondary: '#f8f9fa',
          tertiary: '#f1f3f5',
        },
      },
      fontFamily: {
        sans: ['Inter', 'system-ui', 'sans-serif'],
        display: ['Cal Sans', 'Inter', 'system-ui', 'sans-serif'],
      },
      spacing: {
        '18': '4.5rem',
        '88': '22rem',
      },
      borderRadius: {
        'xl': '1rem',
        '2xl': '1.5rem',
      },
    },
  },
}

export default config

Extracción automatizada (proyectos más grandes)

Para sistemas de diseño más grandes, usa la Figma Variables API o herramientas como Tokens Studio (anteriormente Figma Tokens) para exportar design tokens en un formato estructurado. Tokens Studio puede exportar a formato Style Dictionary, que luego transformas en configuración de Tailwind, variables CSS, o ambas.

El pipeline se ve así:

Figma Variables → Tokens Studio → Style Dictionary → tailwind.config.ts + globals.css

Esta automatización se paga a sí misma la primera vez que el diseñador actualiza un color y necesitas propagarlo a través de la base de código.

Configurando la arquitectura de tu proyecto Next.js

Aquí está la estructura del proyecto con la que comienzo en cada construcción de Figma a Next.js:

src/
├── app/
│   ├── layout.tsx
│   ├── page.tsx
│   ├── globals.css
│   └── (routes)/
├── components/
│   ├── ui/           # Primitivos: Button, Input, Card, Badge
│   ├── layout/       # Header, Footer, Container, Section
│   ├── sections/     # Hero, Features, Testimonials, CTA
│   └── patterns/     # Compuestos: PricingCard, TeamMember
├── lib/
│   ├── utils.ts
│   └── fonts.ts
├── styles/
│   └── tokens.css    # Variables CSS de design tokens
└── types/
    └── index.ts

Decisiones de configuración clave

Enfoque de estilos: Tailwind CSS es mi predeterminado para proyectos Figma a código. El enfoque first-utility significa que puedo traducir directamente padding: 24px, gap: 16px, border-radius: 12px de Figma a p-6 gap-4 rounded-xl sin cambio de contexto. Si el proyecto requiere una librería de componentes como shadcn/ui, Tailwind es ya la base.

Carga de fuentes: Siempre usa next/font para auto-alojar fuentes. Aquí está mi configuración típica:

// lib/fonts.ts
import { Inter } from 'next/font/google'
import localFont from 'next/font/local'

export const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-inter',
})

export const calSans = localFont({
  src: '../assets/fonts/CalSans-SemiBold.woff2',
  variable: '--font-display',
  display: 'swap',
})

Server vs. Client Components: Predeterminado a Server Components. Solo añade 'use client' cuando realmente necesites APIs del navegador, controladores de eventos, o hooks de React. Una página de marketing típica podría tener 90% Server Components con pequeñas islas interactivas.

Construyendo la librería de componentes

Aquí es donde ocurre la mayoría del trabajo. Mi enfoque: trabaja de los componentes más pequeños hacia arriba.

Componentes atómicos primero

Comienza con lo que Figma llama "componentes" y lo que nosotros llamamos primitivos:

// components/ui/Button.tsx
import { cva, type VariantProps } from 'class-variance-authority'
import { cn } from '@/lib/utils'

const buttonVariants = cva(
  'inline-flex items-center justify-center rounded-xl font-medium transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-brand-500 focus-visible:ring-offset-2 disabled:pointer-events-none disabled:opacity-50',
  {
    variants: {
      variant: {
        primary: 'bg-brand-600 text-white hover:bg-brand-700',
        secondary: 'bg-surface-secondary text-gray-900 hover:bg-surface-tertiary',
        ghost: 'text-gray-600 hover:bg-surface-secondary hover:text-gray-900',
      },
      size: {
        sm: 'h-9 px-3 text-sm',
        md: 'h-11 px-5 text-sm',
        lg: 'h-13 px-7 text-base',
      },
    },
    defaultVariants: {
      variant: 'primary',
      size: 'md',
    },
  }
)

interface ButtonProps
  extends React.ButtonHTMLAttributes<HTMLButtonElement>,
    VariantProps<typeof buttonVariants> {}

export function Button({ className, variant, size, ...props }: ButtonProps) {
  return (
    <button
      className={cn(buttonVariants({ variant, size }), className)}
      {...props}
    />
  )
}

Observa cómo los nombres de variantes y tamaños se mapean directamente a lo que existe en Figma. Si el diseñador tiene un componente Button con variantes "Primary", "Secondary", y "Ghost" en Figma — tu código debería reflejar esos nombres exactos.

Componiendo secciones

Una vez que los primitivos están construidos, compónelos en secciones de página:

// components/sections/Hero.tsx
import { Button } from '@/components/ui/Button'
import { Container } from '@/components/layout/Container'

export function Hero() {
  return (
    <section className="py-24 md:py-32">
      <Container>
        <div className="mx-auto max-w-3xl text-center">
          <h1 className="font-display text-4xl tracking-tight text-gray-900 md:text-6xl">
            Convierte tus diseños en
            <span className="text-brand-600"> sitios web de producción</span>
          </h1>
          <p className="mt-6 text-lg leading-relaxed text-gray-600">
            Construimos sitios web rápidos y accesibles en Next.js desde tus archivos Figma.
          </p>
          <div className="mt-10 flex items-center justify-center gap-4">
            <Button size="lg">Empezar</Button>
            <Button variant="secondary" size="lg">Saber más</Button>
          </div>
        </div>
      </Container>
    </section>
  )
}

Herramientas de Figma a Código asistidas por IA en 2025

Hablemos del elefante en la habitación: herramientas de IA que afirman convertir Figma a código automáticamente. He probado todas las principales. Aquí está mi evaluación honesta.

Herramienta Mejor para Calidad de código Soporte de frameworks Precio (2025)
Fusion (Builder.io) Equipos usando CMS de Builder.io Buena — respeta sistemas de diseño React, Next.js, Vue Incluido en planes Builder.io ($50+/mo)
Kombai Usuarios de VS Code queriendo codificación asistida por IA Muy buena — genera planes editables React, Next.js, Angular Nivel gratuito + $20/mo Pro
Locofy.ai Prototipos rápidos y MVPs Decente — necesita limpieza React, Next.js, Gatsby Nivel gratuito + $8-25/mo
Anima Exportación responsiva de HTML/React Regular — estructural pero no lista para producción React, Vue, HTML Nivel gratuito + $39/mo
Plugin Figma to Code Fragmentos HTML rápidos Básica — buen punto de partida HTML, Tailwind Gratuito
v0 (Vercel) Generando UI desde descripciones Buena para componentes React, Next.js Nivel gratuito + $20/mo Pro

Mi perspectiva honesta

Ninguna de estas herramientas produce código que enviaría directamente a producción sin modificaciones significativas. Ni una sola. Aquí está el porqué:

  • Generan markup pero raramente entienden la arquitectura de componentes de tu proyecto
  • No saben nada sobre tus patrones de obtención de datos, integración con CMS, o estructura de API
  • A menudo producen CSS inflado o nombres de clases inconsistentes
  • Regularmente pierden requisitos de accesibilidad

Dónde las herramientas de IA realmente ayudan: Uso Kombai y v0 para generar scaffolding de componentes inicial, especialmente para layouts complejos. Obtener un punto de partida que sea 60-70% correcto ahorra tiempo real. También uso Cursor con capturas de pantalla de Figma pegadas como contexto para acelerar la implementación sección por sección.

El workflow que realmente funciona: IA genera un borrador aproximado → desarrollador humano reestructura, optimiza e integra → QA atrapa los problemas inevitables.

Si estás evaluando si hacer esto tú mismo o trabajar con una agencia, consulta nuestras capacidades de desarrollo Next.js para ver cómo manejamos el pipeline completo.

Manejando el diseño receptivo correctamente

Aquí es donde los proyectos Figma-a-código comúnmente se desmorona. El diseño tiene una maqueta de escritorio y una maqueta móvil. Tal vez una de tablet si tienes suerte. Pero el comportamiento real entre puntos de quiebre? Eso está en la cabeza de nadie.

Implementación primero móvil

Siempre codifica primero para móvil y agrega complejidad en puntos de quiebre más grandes:

<div className="grid grid-cols-1 gap-6 md:grid-cols-2 lg:grid-cols-3 lg:gap-8">
  {features.map((feature) => (
    <FeatureCard key={feature.id} {...feature} />
  ))}
</div>

Patrones receptivos comunes de Figma

Patrón de Figma Implementación CSS/Tailwind
Grid de 3 columnas → apila en móvil grid grid-cols-1 md:grid-cols-3
Lado a lado → pila invertida flex flex-col-reverse md:flex-row
Oculto en móvil hidden md:block
Tamaños de fuente diferentes text-2xl md:text-4xl lg:text-5xl
Desplazamiento horizontal en móvil flex overflow-x-auto md:grid md:grid-cols-4
Navegación → hamburguesa Componente cliente con alternancia de estado

Container Queries (El movimiento subestimado)

En 2025, container queries tienen excelente soporte de navegador (95%+ globalmente). Son perfectas para componentes que necesitan adaptarse basándose en el ancho de su padre en lugar del viewport:

@container (min-width: 400px) {
  .card-layout {
    flex-direction: row;
  }
}

Tailwind v4 tiene soporte nativo de container query con variantes @container.

Tipografía y espaciado: donde fallan la mayoría de proyectos

Estimaría que el 60% de las quejas "no se ve como el diseño" vienen por tipografía y espaciado, no por layout o colores.

Lista de verificación de tipografía

  • Peso de fuente: Figma muestra "Semi Bold" que es font-semibold (600), no font-bold (700). Fácil de equivocarse.
  • Altura de línea: Figma usa alturas de línea fijas (como 28px), Tailwind usa valores relativos (como leading-7). Convierte cuidadosamente.
  • Espaciado de letras: A menudo pasa desapercibido. El espaciado de letras -2% de Figma se traduce a tracking-tight.
  • Características de fuente: Algunos diseños usan características OpenType como números tabulares (font-variant-numeric: tabular-nums) o alternativas estilísticas. Verifica el panel de propiedades de texto de Figma.

Sistema de espaciado

Si el diseñador usó una cuadrícula de 8px (la mayoría lo hace en 2025), tu vida es fácil — la escala de espaciado predeterminada de Tailwind ya está basada en incrementos de 4px. p-4 = 16px, p-6 = 24px, p-8 = 32px.

Pero cuidado con el espaciado irregular. Si el diseño tiene 20px de padding en algún lugar, eso es p-5 en Tailwind (que es 20px). Si tiene 18px — y esto sucede más de lo que te gustaría — redondea al paso más cercano o extiende tu escala de espaciado.

Imágenes, iconos y pipeline de activos

Imágenes

Siempre usa next/image para imágenes raster:

import Image from 'next/image'

<Image
  src="/hero-image.webp"
  alt="Panel de control del producto mostrando analíticas"
  width={1200}
  height={800}
  priority  // Añade para imágenes sobre la línea de flotación
  className="rounded-2xl"
/>

Exporta imágenes desde Figma en resolución 2x para pantallas retina. Usa formato WebP. Para imágenes hero, típicamente exporto a 2400x1600 y dejo que next/image maneje el tamaño receptivo.

Iconos

No exportes iconos como imágenes. Usa una librería de iconos o SVGs en línea:

  1. Lucide React — mi opción predeterminada. Limpia, consistente, 1000+ iconos. Tree-shakeable.
  2. Heroicons — excelente si el diseño usa Heroicons (común con diseños de Tailwind UI).
  3. SVGs personalizados — para iconos específicos de marca, exporta desde Figma como SVG y crea componentes React.
import { ArrowRight, Check, X } from 'lucide-react'

<ArrowRight className="h-5 w-5" />

Animaciones e interacciones

El modo prototipo de Figma muestra transiciones e interacciones, pero traducir estas a código requiere interpretación.

Animaciones CSS-First

Para efectos hover simples y transiciones, mantente con CSS:

<button className="transform transition-all duration-200 hover:scale-105 hover:shadow-lg">
  Empezar
</button>

Framer Motion para animaciones complejas

Para animaciones activadas por desplazamiento, transiciones de página, o secuencias complejas:

'use client'

import { motion } from 'framer-motion'

export function FadeInSection({ children }: { children: React.ReactNode }) {
  return (
    <motion.div
      initial={{ opacity: 0, y: 20 }}
      whileInView={{ opacity: 1, y: 0 }}
      viewport={{ once: true, margin: '-100px' }}
      transition={{ duration: 0.5, ease: 'easeOut' }}
    >
      {children}
    </motion.div>
  )
}

Recuerda: esto tiene que ser un Client Component. Mantén el wrapper de animación delgado y pasa Server Components como children cuando sea posible.

Conectando a un CMS headless

La mayoría de sitios de marketing construidos desde diseños de Figma necesitan un CMS para al menos algo de contenido. Aquí es donde el desarrollo de CMS headless se vuelve crítico.

El patrón que uso más a menudo con Next.js App Router:

// app/blog/[slug]/page.tsx
import { getPostBySlug } from '@/lib/cms'
import { notFound } from 'next/navigation'

export async function generateStaticParams() {
  const posts = await getAllPosts()
  return posts.map((post) => ({ slug: post.slug }))
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPostBySlug(params.slug)
  if (!post) notFound()

  return (
    <article className="prose prose-lg mx-auto max-w-3xl">
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  )
}

Esto es un Server Component por defecto — sin 'use client' necesario. Los datos del CMS se obtienen en tiempo de compilación (con ISR para actualizaciones), dándote cargas de página rápidas y contenido fresco.

Aseguramiento de calidad y comparación de diseño

Aquí está mi lista de verificación de QA para cada proyecto Figma-a-Next.js:

  1. Comparación de superposición visual — Usa una herramienta como PixelSnap o la extensión del navegador "PerfectPixel" para superponer la exportación de Figma encima de tu página construida. Apunto a una coincidencia del 95%+, no pixel-perfect. La perfección de píxeles absoluta en todos los navegadores y tamaños de pantalla es un mito.

  2. Auditoría Lighthouse — Objetivo 90+ en las cuatro puntuaciones. Para nuestros proyectos, típicamente alcanzamos 95+ en Rendimiento, 100 en Accesibilidad, 100 en Mejores prácticas, y 100 en SEO.

  3. Pruebas entre navegadores — Chrome, Firefox, Safari (especialmente Safari — siempre es Safari). Prueba en dispositivos iOS reales, no solo en simulación de dispositivo móvil de Chrome DevTools.

  4. Navegación por teclado — Navega con pestaña a través de cada elemento interactivo. Los anillos de enfoque deben ser visibles y lógicos.

  5. Pruebas de estrés de contenido — ¿Qué sucede cuando un titular es 3x más largo que el placeholder? ¿Cuando una imagen tiene una relación de aspecto diferente? El contenido real del CMS romperá los diseños que solo funcionaron con lorem ipsum perfecto.

Optimización de rendimiento

Un hermoso diseño que obtiene una puntuación de 40 en Lighthouse es un fracaso. Aquí está lo que hago en cada proyecto:

  • Carga perezosa de imágenes bajo la línea de flotación (Next.js lo hace por defecto)
  • Precarga de fuentes críticas con next/font
  • Minimiza Client Components — cada límite de 'use client' agrega JavaScript
  • Usa importes dinámicos para componentes pesados: const Chart = dynamic(() => import('./Chart'), { ssr: false })
  • Optimiza scripts de terceros con next/script y strategy="lazyOnload"

Un sitio Next.js bien construido desde diseños de Figma debería obtener 90+ en Lighthouse sin esfuerzos de optimización heroica. Si estás obteniendo puntuaciones más bajas, probablemente tengas demasiados Client Components o imágenes no optimizadas.

Si estás buscando ayuda con un proyecto Figma-a-Next.js y quieres este tipo de resultados, echa un vistazo a nuestros precios o comunícate directamente.

FAQ

¿Cuánto tiempo tarda convertir un diseño Figma a un sitio web Next.js? Depende mucho de la complejidad del proyecto. Un sitio de marketing de 5 páginas con un sistema de diseño limpio típicamente toma 2-4 semanas para un desarrollador hábil. Una aplicación web compleja con docenas de componentes únicos, animaciones personalizadas e integración con CMS puede tomar 6-12 semanas. La calidad del archivo Figma importa mucho — archivos bien organizados con componentes consistentes pueden reducir el tiempo de desarrollo en 30-50%.

¿Pueden las herramientas de IA automatizar completamente la conversión de Figma a Next.js? Aún no. A partir de mediados de 2025, herramientas como Fusion de Builder.io, Kombai, y Locofy.ai pueden generar puntos de partida útiles, pero ninguna produce código listo para producción sin intervención humana significativa. Se usan mejor como aceleradores — generando el 60-70% inicial del markup — mientras un desarrollador maneja arquitectura, optimización, accesibilidad e integración con CMS.

¿Debería usar Tailwind CSS o CSS Modules para proyectos Figma-a-código? Tailwind CSS es el mejor ajuste para la mayoría de proyectos Figma-a-código. Los diseños de Figma se expresan como valores concretos (colores, espaciado en píxeles, tamaños de fuente), y las clases de utilidad de Tailwind se mapean directamente a esos valores. CSS Modules funcionan bien pero agregan una capa de abstracción que ralentiza el proceso de traducción. La excepción: si tu equipo ya tiene una base de código CSS Modules madura, mantener consistencia puede superar los beneficios de velocidad de traducción.

¿Cuál es la mejor manera de manejar design tokens de Figma en Next.js? Usa Figma Variables (o plugin Tokens Studio) para exportar tokens en un formato estructurado, luego transfórmalos en la configuración del sistema de estilos de tu proyecto. Para Tailwind, esto significa extender tailwind.config.ts. Para propiedades CSS personalizadas, genera un archivo tokens.css. La herramienta Style Dictionary de Amazon es excelente para transformar tokens entre formatos. Mantén el pipeline automatizado para que los cambios de design tokens se propaguen al código sin trabajo manual.

¿Cómo manejo el diseño receptivo cuando el archivo Figma solo tiene maquetas de escritorio? Esto es común. Primero, habla con el diseñador y establece expectativas de comportamiento receptivo. Luego implementa primero para móvil, tomando decisiones de layout basadas en tu entendimiento de la intención del diseño. Usa CSS Grid y Flexbox para crear layouts naturalmente receptivos. Donde no estés seguro, coloca un stub y obtén retroalimentación del diseñador en la construcción en vivo — es mucho más rápido iterar en una implementación receptiva real que volver a diseñar más frames estáticas.

¿Necesito un plan pagado de Figma para hacer desarrollo Figma-a-código adecuado? El plan gratuito funciona para inspección básica, pero el Dev Mode de Figma (disponible en planes pagos a $25/asiento/mes en 2025) proporciona características de entrega de desarrollo significativamente mejores: fragmentos de código CSS, inspección de propiedades de componentes, medidas precisas, y exportación de activos. Para proyectos profesionales, vale la pena el costo. Tu alternativa es usar el plugin gratuito Figma to Code o una herramienta externa como Locofy.ai.

¿Qué puntuación Lighthouse debería apuntar para una construcción Figma-a-Next.js? Apunta a 90+ en todas las categorías (Rendimiento, Accesibilidad, Mejores prácticas, SEO). Next.js te da un punto de partida fuerte, pero puedes fácilmente hundir tu puntuación de Rendimiento con imágenes no optimizadas, demasiados Client Components, o scripts de terceros pesados. Para nuestros proyectos en Social Animal, típicamente logramos 95+ en Rendimiento manteniendo límites de Client Component mínimos y usando next/image para todos los gráficos raster.

¿Cómo mantengo el diseño de Figma y la base de código Next.js sincronizados a lo largo del tiempo? Este es el desafío continuo. Usa design tokens como la fuente única de verdad — cuando colores, tipografía, o espaciado cambien en Figma, actualiza los tokens y regenera tu configuración de Tailwind. Para cambios a nivel de componente, establece un proceso: los diseñadores actualizan el componente de Figma, documentan qué cambió, y los desarrolladores actualizan el componente React correspondiente. Herramientas como Storybook pueden ayudar proporcionando una referencia visual que tanto diseñadores como desarrolladores pueden consultar contra la fuente de Figma.