Pensamientos e impresiones sobre Claude Design
(samhenri.gold)- A medida que se reforzó la sistematización del diseño, Figma fue haciendo crecer una estructura compleja centrada en sus propias unidades, como componentes, estilos, variables y props, y terminó generando distancia respecto del medio real de implementación
- El formato propietario de Figma quedó naturalmente excluido de los datos de entrenamiento de los LLM, y en la era de los agentes, con el auge de las herramientas basadas en código, el source of truth del diseño vuelve a desplazarse hacia el código
- Claude Design, como un medio honesto que trabaja directamente con HTML/JS, propone un enfoque de trabajo directo sobre el medio real de implementación, sin pasar por una aproximación con pérdida del código (lossy approximation) como ocurre con Figma
- Gracias a su relación de hermandad con Claude Code, tiene una ventaja estructural: puede integrar en una sola conversación el loop de retroalimentación entre diseño e implementación
- A medida que el mercado de herramientas de diseño se divide entre herramientas basadas en código y herramientas de exploración pura, surge la posibilidad de que Figma termine recorriendo el mismo camino que Sketch: un
**Sketch moment**
La paradoja de la sistematización en Figma
- A medida que crecieron los equipos de producto, el diseño tuvo que justificar su existencia dentro de las organizaciones de ingeniería, y eso lo empujó hacia la sistematización (systematization)
- Para eso, Figma inventó primitivos propios como componentes, estilos, variables y props, pero algunos fueron tomados de la programación y otros no, dando como resultado una estructura que no encaja limpiamente con ninguna de las dos
- Las guías cambian constantemente, las migraciones se acumulan, y para automatizar algo hay que depender de unos cuantos plugins de baja calidad
- La complejidad creció hasta el punto de que aparecieron roles de diseño especializados únicamente en administrar ese sistema
El desplazamiento del Source of Truth
-
Entre Figma y el código siempre existió una tensión sobre qué debía ser el original (source of truth)
-
Al vencer a Sketch, Figma adoptó la postura de que su herramienta sería el canon (canonical)
-
Pero esa victoria tuvo un costo oculto: su formato cerrado (locked-down) y en gran parte no documentado es difícil de tratar programáticamente, por lo que quedó naturalmente excluido de los datos de entrenamiento de los LLM
-
Los LLM fueron entrenados con código, no con los primitivos de Figma, así que los modelos nunca aprendieron el sistema de Figma
-
A medida que escribir código se vuelve más fácil incluso para diseñadores y los agentes mejoran, el source of truth muestra una tendencia a volver naturalmente al código
-
Frente a esto, la compleja infraestructura que Figma construyó durante la última década puede terminar viéndose excesiva
"Si quieres hacer cerámica, ¿por qué estás pintando una acuarela de la cerámica? ¿No sería mejor simplemente moldear el barro?"
La complejidad del propio sistema de diseño de Figma
- En el trabajo real, llevar de vuelta a Figma (back-porting) cambios de diseño que se hicieron directamente en código es extremadamente tedioso
- Se presenta como ejemplo el archivo del sistema de diseño del propio producto de Figma, y aun siendo el resultado del equipo de sistemas de diseño más competente, está en un estado de complejidad extrema
- 946 variables de color organizadas en grupos anidados como "bg/desktopBackgrounded", y una sola variable puede tener valores para 8 modos distintos, como Light, Dark y FigJam-Light
- Un componente de footer modal tiene 12 variantes, con menús desplegables de valores como "DS Library Swap" y "QA Plugin", además de 8 props
- El estilo de efectos de un componente slider existe como un estilo nombrado por separado para una sola sombra paralela de 0.5 px (drop shadow), porque es la única forma de documentar su correspondencia con variables CSS
- Un componente de entrada tipo combo tiene 16 variantes, y los nombres de capa tienen formas como "Default, Default, Close Button=False"
- Cuando un color se ve mal, el proceso de depuración exige un rastreo de múltiples etapas: revisar el componente → revisar la variable → revisar otra variable alias → revisar el modo → revisar overrides a nivel de instancia → revisar componentes anidados con library swap aplicado
Figma Make vs Claude Design
- A medida que el source of truth se mueve hacia el código, Figma queda en una posición incómoda, aferrado a un sistema pasivo y previo a la era de los agentes (pre-agentic)
- Es posible que las herramientas de diseño del futuro se dividan en dos formas claramente distintas
- Vuelve a abrirse la competencia por responder la pregunta que Figma respondió en 2016: "¿Cuál es la herramienta más rápida para sacar mis ideas como diseñador?"
- Figma Make es una herramienta para quienes ya están familiarizados con el sistema de Figma
- Lee estilos de Figma, bibliotecas de componentes y props propietarios (Prop Props), y es la única herramienta en este nuevo entorno que todavía asume que el archivo de diseño es el canon
- Es una herramienta para quienes quieren quedarse dentro del sistema o no tienen más remedio que hacerlo
- Claude Design apuesta por lo contrario
- Encaja con el principio de "truth to materials" del movimiento Arts and Crafts: la idea de que una cosa debe ser honesta respecto de sí misma y de cómo está hecha
- Figma, en cambio, sería lo opuesto: una capa libre y "vibey" montada sobre un esquema extremadamente rígido; como una personalidad tipo A fingiendo estar relajada mientras por dentro grita por el anidamiento de frames y la separación de tokens
- Claude Design es tosco, pero al menos es honesto sobre lo que es: HTML y JS hasta el final
La ventaja estructural de Claude Design
- El punto clave es que el hermano de Claude Design es Claude Code, que maneja bien el código, y eso le da una ventaja estructural central
- En última instancia, la estructura permite pasar directamente de Claude Design a Claude Code o viceversa
- En el onboarding de Claude Design ya existe una función para importar repositorios (repo)
- El loop de retroalimentación entre diseño e implementación —históricamente una fuente constante de fricción— converge en una sola conversación
La posibilidad de otras herramientas no relacionadas con código: entornos de exploración pura
- En el otro eje de esta bifurcación, podrían aparecer herramientas que no tengan ninguna expectativa sobre el código
- Un entorno de exploración pura donde se puedan poner rectángulos, apilar estilos de capa, manipular libremente modos de fusión y gradientes, sin quedar atado a sistemas ni reglas de prompts
- Podría tomar la forma de una app con soporte para iPad + Pencil enfocada en bosquejar rectángulos rápidamente, o un espacio donde 37signals haga intentos interesantes
- En la dirección opuesta, podría ir hacia algo como Photoshop, apostando por la composición de alta fidelidad (high-fidelity) y liberando la imaginación de los límites de los efectos CSS
- Resulta extraño pensar que, durante el 90% de su vida útil, Figma solo ofreciera sombras paralelas o blur como efectos de capa
El "Sketch moment" de Figma
- El Sketch moment de Figma —el momento en que Figma sea desplazado como Sketch fue desplazado por Figma— se está acercando rápidamente
1 comentarios
Comentarios en Hacker News
Hoy revisé un sistema de diseño que había hecho antes, metiéndole logo, branding y fuentes, y después de corregirlo una y otra vez hasta el cansancio, por fin obtuve un resultado más o menos satisfactorio
Pero al ver el uso, ya me había gastado el 95% del límite semanal de Claude Design
A ese nivel, me pareció más un juguete de demostración que una herramienta de verdad
No coincidía para nada con el estilo que queríamos, pero algunas decisiones de agrupación de contenido e IA sí valían la pena para incorporarlas a mi trabajo
En general me dejó una buena impresión, pero después me dio risa ver en Twitter casos de éxito de otras personas con mockups casi idénticos al que me entregó
Creo que este problema de uniformidad va a seguir persiguiendo a la IA, igual que con el texto, el código y las imágenes generadas
Mi cuñada tiene una pequeña empresa de ropa, y aunque en los últimos 6 años ha mejorado muchísimo, al principio realmente sufría para convertir sus ideas en resultados concretos
Para alguien así, creo que cualquier herramienta que baje la barrera de entrada inicial vale totalmente la pena probarla
Aun así, esto sigue en fase de research preview, así que creo que va a cambiar más adelante
Con el primer sistema de diseño hice una nueva sección de footer para mi startup de iPaaS, y la cuarta opción de cuatro salió bastante bien
Luego la conecté con Claude Code, la pulí un poco, generé el código y la dejé desplegada de inmediato. Si te interesa, puedes ver la sección inferior de tediware.com, la parte de "Origin story" a la izquierda y el panel de registro a la derecha
No era una implementación compleja, pero las ideas que salieron y el flujo de integración fueron tan sencillos que me dejó ver muchísimo potencial
Claude Design usa Opus 4.7, así que es más caro que los modelos anteriores
Apenas lleva dos días desde su lanzamiento, así que todavía no es un producto terminado, y Anthropic suele mejorar estas cosas a una velocidad brutal
Además, si llevas mucho tiempo usando Claude, ya conoce mis gustos y estilo, así que si me cambio a otra herramienta de diseño con IA tendría que empezar de cero otra vez
Al menos sí deja exportar en ZIP, así que probé meter ese archivo en Stitch de Google, pero la compatibilidad no fue muy buena
No coincido mucho con la idea de que Claude Design vaya a eliminar toda la complejidad del diseño
Que una app hecha con vibe coding en Claude parezca simple es porque en realidad el alcance del producto es simple
Se siente como comparar una bicicleta con un avión usando el mismo criterio y confundir eso con simplicidad
Si haces los mismos componentes de un sistema de diseño en código y en Figma, el código puede verse más conciso gracias a las condiciones y al flujo de control
Pero el código es menos flexible que dibujar directamente sobre la pantalla y es más difícil conseguir libertad creativa
Al final, muchas veces la complejidad la crea la propia gente al montar 4 productos con 8 modos y temas claro/oscuro
Claude quizá pueda facilitar un poco el mantenimiento, pero no creo que elimine gran cosa de la complejidad en sí
Por eso creo que esta tendencia sí le va a pegar bastante fuerte a Figma
Creo que el software que logre eso es el que va a ganar
Quería preguntar si entendí bien
Yo programo desde chico, pero no me siento fuerte con CSS, y me dio curiosidad si en la práctica hay muchas organizaciones donde los desarrolladores, incluso los de frontend, colaboran con diseñadores que gestionan el diseño completo del producto en herramientas como Figma, y no solo bocetos de logos o landing pages
Y también me preguntaba si la idea es que esos diseñadores, sin ser desarrolladores, mantengan algo parecido a una base de datos de estilos para manejar la apariencia sin tocar el código, o si lo más habitual es que los desarrolladores frontend también usen Figma pero odien que esté separado del código
El cliente también lo revisa directamente, o al menos aprueba slides de branding que reflejan ese resultado de Figma
Después el frontend toma Figma y lo vuelve a implementar en CSS, pero la función de copiar CSS de Figma es básicamente inline CSS inútil, así que casi siempre se rehace como la mejor aproximación posible
Tampoco refleja bien el sistema de unidades, ni las relaciones padre/hijo, ni las variables CSS, ni las jerarquías de clases
Y si varios frontend implementan componentes por separado, aparece el drift
Por eso también se crea otro punto de referencia frontend con algo como Storybook, y desde ahí se mete en React o NextJS, o se vuelve a implementar como componentes de CMS
En ese punto ya surge la pregunta de cuál es la verdadera source of truth, pero en la práctica se parece más a una cadena de referencias enlazadas como juego del teléfono descompuesto
Y si además aparecen landing pages promocionales hechas fuera del proyecto principal, terminas implementando el mismo diseño otra vez en otro sistema
Al final, en la brecha del handoff entre diseño y código, la intención del diseñador se distorsiona, o el desarrollador termina absorbiendo tarde problemas del mundo real como la longitud de los textos, cambios en la cantidad de elementos, scroll real o adaptación a distintos tamaños de pantalla
Este video corto tipo meme da risa y no da risa justamente porque apunta demasiado bien a esa realidad
En general, los diseñadores no programan y los desarrolladores no diseñan, y la gente que hace bien ambas cosas es realmente rara
Sinceramente es una forma bastante horrible de trabajar, pero igual se siente mejor que las alternativas anteriores
Aun así, me parece inferior a herramientas que automatizan la mayor parte del trabajo tedioso de traducir diseño visual a código y lo conectan directamente con el código
No he usado Claude Design todavía, pero para alguien como yo, que se siente mucho más cómodo con código que con las miles de opciones GUI de Figma, eso suena mejor
Como tengo una trayectoria parecida a la de quien preguntó, esa forma de verlo me genera rechazo casi instintivo
Porque para lograr que todos los ingenieros, incluso con el paso del tiempo, hagan una implementación consistente sin diferencias de estilo, necesitas cierto nivel de referencia centralizada
Últimamente he estado haciendo ingeniería inversa del protocolo de Figma con figma-kiwi-protocol, así que conecté muchísimo con la idea de que “Figma se excluyó a sí misma de los datos de entrenamiento necesarios para la era de los agentes”
El formato binario de Figma está planteado como si quisiera reinventarlo todo, y como abarca diseños web, Android, iOS y de todo tipo, termina siendo muy general pero no tiene una correspondencia 1:1 completa con la web
Y para que le sirva a un agente, la intención tiene que estar clara, pero cualquiera que haya implementado un Figma hecho por un diseñador UX sabe que incluso para una persona muchas veces es difícil entender la intención de diseño exacta
Siguen saliendo preguntas como qué pasa con el botón cuando en alemán el texto se alarga, qué hacer si al pasarlo a CSS se rompe en dos líneas, cómo se ve en teléfonos que no sean iPhone, con qué reemplazar un borde con gradiente que CSS no puede hacer, o qué pasa en una pantalla 4K
Algunas cosas se pueden responder con props o autolayout, pero el responsable de UX en la vida real no siempre es ese ser mítico que domina Figma a la perfección
Por eso espero que herramientas con base interna en HTML se pongan al día rápido, y si se puede, también me gustaría ver hasta el prompt que el product manager le dio a la persona de UX
El texto me gustó, y los últimos párrafos de verdad me hicieron reír
En especial me gustó la parte sobre no pretender ser algo distinto y ser honesto con la propia identidad
Y eso me hizo pensar que PenPot podría estar en una posición bastante favorable en esta era de agentes
A diferencia del enfoque tipo canvas de la familia fig, se fue más por el lado de un diseño basado en markup real, así que si ese rumbo te interesa, parece tener aún más potencial
Desde que InVision cerró y giró hacia el lado de la pizarra digital, para mí este mercado de herramientas de diseño ya se sentía prácticamente acabado
Me parece un mercado así de difícil
Más en el fondo, mantener bien un sistema de diseño a largo plazo es demasiado complicado, sobre todo porque está profundamente entrelazado con el código y las bibliotecas de componentes, y ese nivel casi nunca lo tocan los diseñadores
Ni Claude Design, ni Figma, ni ninguna otra herramienta me parecen capaces de resolver de raíz el infierno de Storybook alrededor de componentes reutilizables y layouts bonitos
Se siente como un problema cuya solución tendría que cambiar más abajo, a nivel de componente
Ahorita estamos atrapados en la forma de pensar de crear componentes para ir insertándolos en cada nuevo diseño
Si encuentras un componente que te gusta, guardas su definición en markdown, y en el siguiente diseño le pides a la herramienta que lea ese markdown y use ese componente cada vez que haga falta
Creo que eso produciría un flujo mucho más flexible e interesante
Tiene que poder programarse y también dibujarse directamente; si cambias el diseño, el código frontend debería cambiar de inmediato, y los cambios en el código también deberían reflejarse al mismo nivel en el diseño
Creo que la forma final sería un modelo donde el diseñador y el ingeniero frontend son coautores sin handoff
Aunque también hay quien dice que, como en adelante modificar, extraer y reorganizar será casi gratis, ese tipo de estructuración va a importar menos
Yo todavía no estoy totalmente convencido, pero entiendo por qué se dice
Desde la perspectiva de alguien que lleva años construyendo herramientas de diseño, sentí que este texto malinterpreta bastante de fondo tanto el ámbito del diseño como a Figma como empresa
Figma siempre estuvo enfocada no solo en hacer un producto exitoso, sino también en construir una empresa exitosa
Al principio había una dirección más ambiciosa y también capacidad de ejecución gracias a gente como Evan Wallace, pero al final se convirtió en el negocio que es hoy porque se concentró en productos concretos que daban dinero, más que en demos de WebGL
Creo que la ausencia de cosas como funciones 3D también es consecuencia de esa decisión
Figma, antes que una herramienta de diseño, siempre fue una empresa que hace productos que las compañías realmente usan, y para cuando llegó al IPO ese objetivo ya estaba bastante cumplido
No sé cómo se moverá el mercado a futuro, pero es posible que quien tenga más capital de guerra esté mucho mejor posicionado que quien solo tenga demos técnicamente impresionantes
Y además, los problemas que menciona el artículo ya los conocen muy bien la gente de Figma y, en realidad, cualquiera que haya intentado hacer herramientas de diseño
Es obvio que UI/UX está en la intersección entre diseño, desarrollo y PM, y también que debería acercarse lo más posible a una source of truth como el código
El problema es que, en cuanto intentas implementarlo de verdad, se convierte en un desafío enorme que se expande más allá de las herramientas de diseño hacia coding, gestión de datos y herramientas de arquitectura
Sobre IA no tengo certezas, pero siento que los modelos SOTA recientes son tan generalistas que su capacidad de razonamiento base quizá importe más que datos especializados
Después de todo, el diseño de UI tiene mucha información visible externamente que también se puede recolectar de la web
No tengo ningún interés especial en esta pelea ni sé si el análisis del post original sea correcto
Pero aun así, cada vez que escucho una historia de alguien que se quedó atrás por un formato de archivo propietario, me da una pequeña dosis de schadenfreude
Algunos puntos me parecieron buenos, pero en general no estoy completamente de acuerdo
Creo que Sketch perdió contra Figma por el tooling de diseño y la experiencia multiplayer
Igual que los productos físicos se diseñan antes de fabricarse, no creo que la etapa de diseño desaparezca en los productos digitales
Más bien, creo que Figma tiene que decidir pronto cuál va a ser exactamente su identidad, en vez de intentar abarcar ambos lados
El modelo de pedir que instalaran una app en Mac y abrieran un archivo específico fue envejeciendo mal con el tiempo, tanto por el propio archivo como por la accesibilidad
Relacionado con esto, hubo un hilo reciente en HN sobre Claude Design, y para abril de 2026 ya llevaba 732 comentarios, así que la reacción fue bastante grande