Deja de diseñar en Figma

Tu archivo de Figma es una fotografía estática de un producto que no existe. Para cuando el ingeniero lo lanza, ya está mal. Las fuentes se renderizan distinto, salen los breakpoints que ignoraste, aparece el estado vacío que olvidaste y el hover que dejaste como comentario lo interpreta alguien que no eres tú. La solución no son mejores plugins de Figma. La solución es dejar de usar Figma como herramienta de diseño y empezar a usar el codebase.

Esto no es un ataque a Figma. Figma sigue ganando en trabajo de sistemas, exploración de marca y diagramas en FigJam. La tesis es más estrecha y más dura. En 2026, el diseño de producto ocurre en código. v0, Cursor, Lovable y el registro de Vercel UI han reemplazado al artboard como el lugar donde las superficies realmente se diseñan. Los diseñadores que siguen entregando frames de Figma pixel-perfect para que los ingenieros los "implementen" están haciendo dos trabajos a mitad de velocidad.

Qué cambió de verdad

Figma se construyó para una era en la que la producción era el cuello de botella. En 2018, generar un componente de React funcional le costaba tres días a un ingeniero, y un diseñador podía sacar veinte frames hi-fi en el mismo lapso. Entregar artboards planos como producto final era la jugada racional. El artboard era la parte más rápida del pipeline.

Esa cuenta se invirtió en 2026. v0 convierte una frase en un componente funcional en treinta segundos. Cursor edita un repo real con un diff real. Lovable levanta una app desplegable a partir de un solo prompt. El artboard ahora es la parte más lenta del pipeline, no la más rápida, y la brecha se ensancha cada trimestre. El análisis más profundo del cambio a nivel de artefacto está en la muerte del mockup. Este artículo trata de la herramienta que produce el artefacto.

El frame plano no empeoró. El banco de trabajo mejoró.

Dónde Figma todavía se gana el sueldo

Seamos honestos. Figma es excelente en cuatro trabajos, y fingir lo contrario hace que descarten el resto del argumento.

Figma sigue ganando en la exploración de identidad de marca, donde viven logos, estudios tipográficos y sistemas de color antes de que exista ningún codebase. Gana en los inventarios de design system, ese archivo único que lista cada token, variante y estado con un modelo multijugador que nada más replica. Gana en diagramas en FigJam y alineación de equipo, la pizarra y el mapeo de journeys donde la superficie es la conversación. Y sigue ganando para el diseñador que de verdad no sabe leer código, un perfil más raro en 2026 de lo que la industria admite, pero real.

Todo lo demás, toda superficie de producto que llega a un usuario real, pertenece al código.

Las cinco diferencias

Diseñar en Figma y diseñar en código no es el mismo trabajo a distinta velocidad. Son trabajos distintos.

Fidelidad. Un frame de Figma aproxima la tipografía, ignora el hover, simula el scroll y renderiza fuentes que el navegador no cargará igual. Una superficie en código usa la fuente real, el componente de botón real, el breakpoint real, el focus ring real. La brecha entre aproximación y realidad antes era aceptable. En un producto donde los estados de carga, vacío y contenido largo son la mitad del diseño, ya no lo es.

Velocidad. El ciclo de Figma es editar el frame, comentar al ingeniero, esperar, revisar el build, comentar otra vez, esperar otra vez. El ciclo en código es editar, recargar, ver. El primero corre en días, el segundo en segundos. La velocidad de iteración decide cuántas ideas llega a probar el equipo antes del lanzamiento.

Modelo de colaboración. Los comentarios de Figma y los de un PR son superficies distintas. Los comentarios de Figma van de diseñador a stakeholder y de diseñador a ingeniero como especificación. Los comentarios de PR son diseñador e ingeniero como pares sobre un único artefacto. El segundo modelo es el que usan los equipos de design engineering, y es estructuralmente más rápido.

El handoff desaparece. El handoff es el momento más caro del pipeline tradicional. Diseñar en código lo elimina. No hay paso de traducción porque el diseño es la implementación.

Los casos límite se revelan al instante. Vacío, carga, contenido largo, móvil, error, red lenta. En Figma existen si el diseñador se acordó de dibujarlos. En código existen te acuerdes o no, porque el componente tiene que manejarlos para renderizar. El código obliga a ser honesto.

v0, Cursor, Lovable y Vercel UI son la nueva superficie de diseño

El nuevo entorno de diseño no es una sola herramienta, es un stack que alcanza masa crítica de golpe. Cada una cubre una capa de lo que Figma hacía solo.

v0 de Vercel convierte un prompt en un componente funcional de React y Tailwind en unos treinta segundos. Haz fork del resultado, itera por prompt o a mano, mételo en el codebase. El modelo de fork e iteración reemplaza al duplicar y retocar de Figma, solo que el duplicado es código real.

Cursor es la superficie de diseño para diseñadores de producto que saben leer código. Abres el repo real, ves el render real, editas un componente con prompt o a mano, y ves el cambio en el navegador en el mismo minuto.

Lovable es la superficie para fundadores y diseñadores en solitario. Un prompt y tienes una app web funcional, luego iteras sobre la cosa en marcha. El camino más rápido de la intención a una URL en vivo, sin archivo de Figma.

Vercel UI y el registro de shadcn son el estante de componentes. Toma un componente real, personalízalo dentro del codebase, lánzalo. shadcn entrega componentes como código que es tuyo, lo que significa que el design system se edita en la misma superficie que el diseño.

Las herramientas difieren en forma, pero comparten la misma idea. La superficie en ejecución es el artefacto. El artboard es un borrador, si es que existe. Para el patrón más profundo de práctica, mira vibe coding para diseñadores y Claude Code para diseñadores.

Cómo trabajan realmente Linear, Stripe y Anthropic

Los equipos que lanzan la mejor UI de producto en 2026 comparten la forma de su flujo de trabajo, y ninguno entrega Figma como resultado final.

Linear trata el codebase como fuente de verdad. Su equipo de design engineering aterriza los diseños como pull requests sobre la app en ejecución, no como frames de Figma. El design system de Stripe se construye y se publica desde código. Figma existe como documentación aguas abajo del código, no como fuente aguas arriba. Editar el sistema es editar el código. Anthropic diseña las superficies de producto de Claude en línea, en componentes de React y artifacts de Claude, con diseñadores leyendo y editando la app real en cada release.

El patrón se repite en todo equipo de producto que entrega a velocidad premium. Tokens aguas arriba, código como lienzo, IA como capa de producción, diseñadores en el diff. El pipeline de frames planos no es como trabaja ninguno de ellos, y las cuentas ya alcanzaron al resto de la industria.

Cinco preguntas antes de diseñar en código

No todo diseñador debería soltar Figma mañana. El test honesto son cinco preguntas. Si tres o más respuestas son sí, diseñar en código es la superficie correcta para tu próximo proyecto.

1. ¿Entregas el trabajo o lo pasas a otro? Si lo entregas, gana el código. Si lo pasas, el código sigue ganando, pero el cambio cultural es mayor.
2. ¿Sabes leer el codebase? No escribir React de producción desde cero, solo leer componentes, entender props, reconocer un design token y editar valores sin romper el build.
3. ¿El diseño es una especificación estática o una superficie interactiva? Una especificación pertenece a Figma. Una superficie con hover, focus, scroll, motion y estados límite pertenece al código.
4. ¿El equipo tiene un design system que extender? Una biblioteca de componentes real, incluso una base de shadcn, hace el diseño code-first dos órdenes de magnitud más rápido que Figma.
5. ¿La velocidad de iteración es tu cuello de botella? Si pierdes sprints en el ciclo de handoff, el code-first mata el cuello de botella. Si los pierdes en estrategia de marca, el code-first no hace nada. Resuelve el problema correcto.

Un equipo que saca cuatro de cinco vive en el código. Un equipo que saca dos de cinco debería repartir el trabajo entre Figma y código, con el sesgo ligeramente hacia el código en cada proyecto nuevo.

Antipatrones que hay que abandonar

Cuatro patrones matan más UI de producto lanzado que cualquier elección de herramienta. Si un equipo hace alguno de estos, el cambio de herramienta importa menos que el cambio de flujo de trabajo.

La fantasía del dev mode como handoff. El diseñador entrega un archivo de Figma lleno de líneas rojas. El ingeniero "usa Dev Mode" para traducir. Ambos fingen que la traducción es fiel. Nunca lo es. Dev Mode es útil, pero es la misma fantasía de handoff con envoltorio nuevo. La solución real es que ingeniero y diseñador editen el mismo artefacto, que es lo que habilitan las superficies en código. Para la capa de conexión, mira la guía de Figma MCP.

El mock pixel-perfect que ignora fuentes y breakpoints reales. Un frame a 1440px con Lorem Ipsum y una fuente que la app en producción no carga. El mock se ve pixel-perfect, el producto lanzado no se parece en nada, y todos aprobaron la mentira.

El design system que vive en Figma y diverge en silencio del código. La biblioteca de Figma dice que el botón tiene 12px de padding. El código dice 14px. Nadie actualizó ninguno. A los seis meses, el archivo de Figma es ficción. Una sola fuente de verdad, en código, con Figma como render aguas abajo.

El rediseño de seis meses que se entrega como PDF. Un rediseño estrella entregado como un export de Figma de cien páginas, presentado a la C-suite, pasado a ingeniería para la "fase dos". La fase dos no ocurre porque, para cuando ingeniería dimensiona la reconstrucción, la empresa ha cambiado de estrategia dos veces. El rediseño que no se lanza no existió.

La auditoría de diseño code-first

Antes de que arranque el próximo proyecto, haz la auditoría. Siete preguntas, diez minutos, respuestas afiladas.

1. ¿Cuál es el entregable, un frame o una superficie lanzada? Si es lanzada, el entregable es código. Deja de fingir que el frame es el producto.
2. ¿Quién es dueño de la app en ejecución, y el diseñador está en el diff? Si el diseñador no está en el diff, arregla eso antes de cambiar de herramienta.
3. ¿Dónde viven los tokens? Si la respuesta es Figma, muévelos. El archivo de tokens debería ser la fuente de verdad que Figma lee, no al revés. El desglose del flujo de trabajo de diseño con IA cubre el camino de mejora.
4. ¿Cuál es el ciclo de iteración, en horas? Si pasan más de cuatro horas de la edición al cambio lanzado, el problema es el flujo de trabajo, no el diseño.
5. ¿Qué superficies se siguen diseñando en artboards planos y cuáles pasaron a código? Mapea la división. La división debería sesgarse hacia el código en cada iniciativa nueva.
6. ¿En qué plugins se apoya el equipo para fingir fidelidad de handoff? Si la respuesta es "muchos", mira los plugins de Figma que vale la pena conservar y corta el resto.
7. ¿Qué lanza el equipo el próximo trimestre que demuestre que el flujo funciona? No una diapositiva, una superficie desplegada. Si la respuesta es vaga, el flujo de trabajo todavía no ha cambiado de verdad.

Un flujo de trabajo que supera la auditoría lanza producto. Uno que la suspende lanza decks. La diferencia se acumula cada trimestre, y la velocidad es la marca cuando todas las demás variables son más o menos iguales.

FAQ

¿Figma está muerto?

No. Figma no está muerto, y la tesis no es "Figma está muerto". Figma es excelente para identidad de marca, inventarios de design system, diagramas en FigJam y presentaciones a stakeholders. La tesis es más estrecha. Figma ya no es donde ocurre el diseño de producto, porque el codebase es más rápido, de mayor fidelidad y entrega el mismo artefacto que toca el usuario.

¿Y los diseñadores que no saben leer código?

Ese diseñador debería aprender a leer código, no a escribirlo. Leer componentes, reconocer tokens, editar valores y revisar un diff es una habilidad de una semana, no un cambio de carrera. En 2026 la IA se encarga del trabajo pesado del código de producción. El diseñador aporta composición, criterio y gusto a la superficie en ejecución, lo cual es más valioso, no menos, cuando la capa de producción es barata.

¿Un equipo pequeño debería saltarse Figma por completo?

No del todo. Un equipo pequeño debería seguir usando Figma para exploración de marca, inventarios de sistemas y alineación del equipo. El cambio está en las superficies de producto, donde v0, Cursor, Lovable o el registro de shadcn superarán a un artboard en todas las métricas. La división honesta es marca y sistemas en Figma, superficies de producto en código, y en las iniciativas nuevas el sesgo se inclina hacia el código.

Ponte del lado correcto del flujo de trabajo

La era de Figma como herramienta de diseño tuvo razón durante quince años y se acabó. El codebase es el entorno de diseño en 2026, y los equipos que lanzan UI de producto en código cobran más, aprenden más rápido y ganan los briefs que antes eran de los estudios de decks en Figma.

Si quieres una UI de producto lanzada en código, con diseñadores en el diff en lugar de un deck de Figma lanzado por encima del muro, contrata a Brainy. Brainy entrega marca, ingeniería de producto y el flujo de trabajo con IA como un solo proyecto, no tres. Los estudios que todavía cobran el archivo de Figma como entregable final no estarán en el brief el próximo trimestre. Está en el brief.