Ahora diseño más con Claude que con Figma
(blog.janestreet.com)- El flujo de trabajo de diseño está pasando de revisar la implementación a partir de documentos de especificación y mockups en Figma a crear funcionalidades prototipo que funcionan dentro de la base de código real
- Copilot, Cursor y Gemini no cumplieron las expectativas en tareas que ya hacía bien, como modificar un juego, redactar briefs de producto o hacer wireframes, pero en un entorno nuevo por aprender como OCaml y Bonsai, el apoyo de la IA se volvió indispensable
- El proceso está centrado en la implementación real: pasar problemas y propuestas como prompts, construir la funcionalidad base, iterarla, desplegarla al entorno de desarrollo, recoger opiniones de usuarios y luego enviar el feature
- Un prototipo que añadía prompting con LLM a una entrada de JSQL llevó a refinar varias veces botones, atajos de teclado, textos, prompts y mensajes de confirmación, concentrando el esfuerzo en el resultado real en vez de componentes de Figma o formato de documentos
- Aunque ahora los diseñadores pueden convertir ideas en algo utilizable por sí mismos, los prototipos que parecen funciones terminadas también traen nuevos retos para la forma de hacer reviews y para la exploración creativa
De la desconfianza hacia los LLM a una herramienta de apoyo indispensable
- Durante mucho tiempo, cada vez que usaba LLM terminaba decepcionado con los resultados, y cada vez que los aplicaba a tareas que ya dominaba, la calidad era peor que hacerlo yo mismo
- Intenté usar Copilot y Cursor para modificar un juego que hice el año pasado, pero ninguno logró producir cambios funcionales; en mi trabajo anterior también probé Gemini para generar esquemas de briefs de producto y wireframes, pero todo terminó descartado
- Después de unirme a Jane Street el verano pasado, tenía mucho que aprender, y tecnologías que aún no dominaba como OCaml y Bonsai hicieron que el apoyo de la IA se volviera esencial
- El gran cambio fue que la IA terminó transformando incluso el flujo de trabajo de diseño, que era donde más confianza tenía
Prototipos en la base de código real en lugar de Figma y documentos
- En vez de escribir documentos de especificación, crear mockups en Figma, redactar propuestas y revisar la implementación con desarrolladores, ahora se construyen funcionalidades prototipo que hacen exactamente lo que la idea en la cabeza pretende
- En la práctica, el flujo consiste en escribir una frase que describa el problema y la propuesta, abrir en el editor el build, el servidor y Claude, y usar esa descripción como prompt
- Primero se hace funcionar la funcionalidad base para comprobar la viabilidad, y luego se itera tantas veces como sea necesario
- Después se suben los cambios al entorno de desarrollo, se pide opinión a los usuarios y, una vez que el feature tiene la forma y el comportamiento deseados, se envía
- En Jane Street, un feature es el proceso equivalente a un pull request
- Un feature prototipo dentro de la base de código real ofrece una experiencia mejor que los mockups y los documentos en casi todos los aspectos
- Un prototipo reciente que añadía prompting con LLM a una entrada de JSQL realmente funcionó, y fue probado usándolo directamente durante varios días
- JSQL es un dialecto interno de SQL usado en herramientas para múltiples usuarios
- Claude permite una iteración libre y prácticamente ilimitada, sin molestarse por el cambio de opinión número 50 ni por pequeños pedidos de ajuste
- Se mejoraron el botón Submit, los atajos de teclado, los textos, los prompts y hasta los mensajes de confirmación generados
- En mi trabajo anterior, esta mejora del flujo habría requerido días o semanas de ida y vuelta entre ingeniería y diseño, o más probablemente nunca habría ocurrido
- El esfuerzo dedicado a esta función se concentró en mejorar el resultado real, no en entregables intermedios como crear componentes en Figma o ajustar el formato de documentos
Ampliación del alcance en los últimos dos meses
- Llegar a este flujo tomó tiempo, y al principio, tras entrar a la empresa, solo usaba IA para tareas pequeñas como corregir pequeñas molestias de UX
- Para ideas grandes seguía usando Figma y documentos, y mis intentos de construirlas con Claude fracasaban
- En los últimos 2 meses, las ocasiones en que abro Figma se redujeron drásticamente, gracias a la combinación de modelos mejores, mayor dominio de las herramientas y una elección adecuada del alcance
- La IA no solo funcionó para prompts de JSQL, sino también en alrededor de 6 prototipos que creaban cambios orientados a usuarios, modelos de datos y bibliotecas
- Algunos prototipos tenían diffs de más de 2000 líneas
- También se usó para implementar un prototipo interactivo de una app nueva diseñada en Figma
- Algunas apps nuevas omitieron Figma y comenzaron iterando el diseño visual directamente con Claude
Más autonomía para los diseñadores y una redefinición de la forma de hacer review
- Cuando los ingenieros tienen una idea, pueden crear una prueba de concepto funcional, pero los diseñadores suelen depender de convencer a otra persona para que la construya por ellos
- Ideas como “hacer prompting con LLM directamente en la entrada de JSQL” no tienen una viabilidad clara al principio, así que pedirle a otra persona que haga el prototipo puede terminar desperdiciando tiempo
- Algunas propuestas pueden no responder con claridad a las necesidades de los usuarios, pero al convertir una idea en algo real con Claude, se vuelve mucho más fácil para otros usarla directamente y evaluarla
- La desventaja es que el reviewer recibe algo que parece una función terminada, y ya no queda claro si debe revisar solo el código o también aportar sobre la funcionalidad
- En términos de diseño, se parece a cuando un PM entrega wireframes muy detallados y pide simplemente que se vean bonitos: no es una revisión especialmente agradable
- La propuesta debe ser clara y completa, pero exige que los colegas de ingeniería la traten como tratarían un mockup en Figma: algo sobre lo que iterar juntos dentro del espacio de diseño
- La solución actual es incluir una breve nota en la descripción del feature
- El prototipo es un documento de propuesta vivo
- El código puede desecharse
- El rol del reviewer es dar feedback sobre diseño y experiencia de usuario
- En última instancia, el reviewer toma la idea y la implementa en un feature aparte, usando el prototipo como referencia, mientras que el código de producción queda bajo responsabilidad del reviewer
- En el trabajo real, todavía se sigue entendiendo qué resulta razonable y qué se siente bien dentro de este nuevo flujo
Los límites de la iteración y la sensación de haber vuelto al medio real
- Existe la preocupación de que diseñar con Claude aleje de una forma de pensar más fluida y creativa, y que la iteración quede atrapada dentro de los resultados que uno cree que Claude puede producir
- Eso puede estar bien cuando los cambios son iterativos, como ocurre con herramientas maduras, pero al crear algo nuevo existe el riesgo de perder ideas
- Cuando empecé mi carrera profesional en 2011, se hablaba mucho de designers should code, y quienes criticaban esa postura decían que, al empezar a programar, se volvía más difícil hacer cambios profundos en las ideas
- Como me gustaban crear sitios web y programar, seguí escribiendo código, pero cuando frameworks frontend como React se volvieron comunes y el desarrollo frontend se hizo más complejo, opté por especializarme
- Mis proyectos personales con React me ayudaron a interactuar con desarrolladores, pero en el trabajo pasaba casi todo el tiempo en Figma y documentos
- Si me hubiera unido a Jane Street antes de los LLM, probablemente habría quedado aún más atrapado en Figma, y a diferencia de JavaScript, OCaml y Bonsai eran totalmente nuevos, así que contribuir técnicamente habría parecido algo fuera de mi alcance
- Ahora siento que he vuelto a crear resultados reales, a trabajar dentro de ese medio y a tener más libertad para probar cualquier cosa
1 comentarios
Comentarios de Hacker News
En el lado de negocio ya suelen traer los requisitos en forma de una solución que ellos mismos idearon, y normalmente es algo tipo máquina de Rube Goldberg, así que hay que hacer ingeniería inversa en la conversación para llegar al requisito real
En adelante, probablemente traerán una solución ya “lista” y “funcionando”, y estarán menos abiertos a hablar de diseño y arquitectura de forma integral
Seguramente será algo como: “Pero si ya se puede hacer así. Casi está listo, ¿por qué hace falta X semanas-persona?”
La desventaja es que el lado de negocio no entiende por qué no se puede desplegar esa app tal cual a producción
Va a aumentar la presión de “podemos ir más rápido con AI”, y al final parece que dependerá de una dinámica organizacional sana
La ventaja es que la idea está mucho más validada que un boceto en una servilleta
Claude probablemente ya preguntó por casos límite y decisiones de diseño, y es muy posible que en algún punto le hayan dicho explícitamente “no te preocupes por eso, asúmelo” o “después de usarlo unas veces, esta interacción no convence, cámbiala”
Ahora mismo la presión de “qué problema hay, solo súbelo a producción” es fuerte, tonta y desmoralizante, así que se acerca más a una pérdida neta, pero cuando se estabilice podría volverse una ganancia neta para proyectos futuros
Esos ajustes menores son cosas como que el layout se rompe si el navegador no mide exactamente 1920px de ancho, que los filtros y el ordenamiento a veces no funcionan bien, o que después de cierta acción el nuevo valor no se actualiza correctamente en la app
Sin importar el problema, el lado de negocio cree que ya hizo el 95%, así que asume de antemano que “un desarrollador con experiencia lo arreglará rápido”
La gente se acostumbra al resultado que ya tiene y luego le cuesta más aceptar los cambios en una nueva mezcla profesional
Hay PM, CSM y TAM que sí tienen el criterio para traducir el problema del cliente en funcionalidades de producto usables, pero si se saltan la definición del problema y hacen que otra organización funcional construya la solución, normalmente termina siendo un desastre que desperdicia muchísimo esfuerzo de ingeniería y otros recursos
Si alguien llega ya con una solución, corres el riesgo de pasarte meses construyendo software operable para descubrir después que al cliente no le gusta, que no resuelve el problema o que creó uno nuevo
No donde trabajo ahora, sino en un lugar donde estuve antes, y lo subieron a producción tal cual con pérdida de datos y problemas de seguridad
Según entiendo, Jane Street es inversionista de Anthropic, así que hay que tener eso en cuenta
También está el hecho de que en julio de 2025 la SEBI, el regulador bursátil de India, afirmó que Jane Street manipuló el mercado usando varias entidades y le prohibió el acceso al mercado
Supongo que una gran máquina de hacer dinero necesita muchos dashboards
Aquí el diseñador parece estar tomando un enfoque equivocado, como si hubiera caído en una especie de envidia de ingeniería y quisiera que el prototipo fuera lo más profundo y realista posible
Pero esa no es la parte más importante del trabajo de diseño
Lo más importante es que se construya lo correcto
Preguntas como “¿por qué hace falta una caja de entrada JSQL? ¿qué es lo que realmente se quiere? ¿qué otras formas hay?” muchas veces se resuelven mejor con bocetos en papel, reuniones, observación y discusión
Es mejor eso que cerrarse demasiado rápido a un diseño específico y terminar discutiendo si el botón va a la izquierda o a la derecha, o cómo debe comportarse en detalle el LLM
Aunque claro, también podría ser exactamente eso lo que quieren que pensemos
A veces se nota esto
Los LLM actualmente no ven más allá de la iteración presente, así que tengo que pensar fuera del marco y decir “¿y si lo vemos desde este ángulo?” para que de pronto aparezca una forma nueva de diseño
A veces incluso hay que hacer un diagrama de flujo para que el LLM pueda ver más allá de la etapa en la que va
Cuando dice “Claude me dio iteración gratis e ilimitada, sin molestarse aunque cambiara de opinión por quincuagésima vez o pidiera un ajuste pequeño”, ¿significa que no paga Claude?
Los estudios de diseño pequeños también suelen funcionar parecido, y muchas veces no cobran por hora como los desarrolladores
Respondí honestamente que soy realmente malo para diseño y que también tengo problemas para extrapolar sistemas de diseño
Me cuesta muchísimo llegar a un punto que se vea aceptable, y en el proceso casi siempre termino empeorándolo
La diseñadora que me entrevistaba se lo tomó como algo personal y se me fue encima
Ya me había pasado antes algo parecido
A los diseñadores no les gustaban las preguntas constantes sobre cómo debía verse algo, y querían una entrega tipo “te lo paso una vez y listo”
Incluso en agencias de marketing y publicidad tuve que pelear constantemente para que me dieran muestras de cómo debían verse cosas que no estaban en la especificación de diseño
No digo que yo tuviera razón, pero para mí es un gran talón de Aquiles
Así que cuando oigo “gratis, iteración ilimitada, sin molestarse”, antes que el dinero pienso en tiempo y paciencia
Bolt, que uso para hacer prototipos, no se enoja
Tal vez no produzca el mejor diseño posible, pero es muchísimo mejor que lo que yo podría hacer, y al final se le puede dar a un diseñador de verdad para que lo mejore
Hasta entonces, no tengo que preocuparme por hacer enojar a nadie
He estado usando Claude Design para frontend
La apariencia y la sensación del resultado son suficientemente buenas, pero los diseños suelen verse parecidos y en general siguen patrones trillados de la web moderna
Me pregunto si alguien ha logrado hacer intentos creativos no convencionales con esto
Hasta ahora le he dedicado unas 3 semanas y todavía no está terminado, pero se entiende la idea
Así como en la última década existió el boilerplate de SaaS, también existe un boilerplate de LLM entrenado con internet
Aun así, si le metes suficiente mano, sigue siendo posible hacer cualquier cosa
Me parece interesante que si le das requisitos, los sigue, y si no le das dirección, toma decisiones seguras
Si vas a evaluar la estética del output y la experiencia de usuario y el contenido, pero casi no das prompts sobre la parte estética, solo vas a recibir valores seguros por defecto
Hace bien diseños con esa sensación de copia de bootstrap/tailwind, pero hay que empujarlo conscientemente en esa parte
En páginas web simples, empecé a poner el estilo visual como único foco de las iteraciones iniciales
Basta con indicarle específicamente que no se vea estándar y darle ejemplos del estilo de sitios web que quieres
Si peleas un poco con eso, se siente algo más creativo, pero requiere trabajo de prompt
Me lo recomendaron diseñadores muy respetados y con mucha experiencia, y ellos ahora hacen prototipos casi por completo en Claude y, si les gusta, luego lo pulen en Figma
Desde el inicio, si pides una UI genérica sin un prompt de estilo detallado, es obvio que va a salir un diseño genérico
La ventaja aquí es que los diseñadores aprendan a programar
Siempre me pareció raro que un diseñador moldeara software sin saber cómo se construye el software
Para que conste, yo también soy diseñador
Pero diseñar en código es un enfoque de la tecnología primero
Si el objetivo del diseño es dar forma a un resultado de acuerdo con objetivos humanos, también se puede argumentar que es mejor no empezar desde las reglas estrictas del código
No por lo bonito del resultado, sino porque para empujar el pensamiento hacia adelante sigue siendo difícil ganarle al papel y lápiz
Ahora que prácticamente ya se puede programar con la voz, estoy volviendo otra vez al vibe coding y a crear productos, y se siente increíble
Mi jefe todavía está tratando de entender esta nueva situación, pero parece que la vieja separación de roles ya empezó a morir
Creo que estar en la intersección es el mejor lugar ahora mismo
Siento que toda mi vida me preparó para este momento
Para un diseñador, probablemente se parezca a Figma, pero viendo el resultado y corrigiéndolo con lenguaje en vez de con un editor visual
Mi esposa trabaja como product manager en una FAANG, y su equipo depende muchísimo de usar AI para vibe codear piezas de software que antes habrían hecho con algo como Word o Excel
No aprenden a programar ni miran el código ni por un segundo
El enfoque de “el prototipo es un documento de propuesta vivo, el código se puede desechar y el trabajo del revisor es dar feedback sobre el diseño y la experiencia de usuario
Al final, el revisor toma la idea y la implementa como una funcionalidad aparte, usando el prototipo como referencia, pero siendo dueño directo del código de producción” resuelve un problema que yo tenía en todos los POC
Es una forma realmente buena de trabajar
Cuando estás tratando un problema específico de un producto específico, es fácil llamarlo un “documento de propuesta”
Pero aun así muchísimos diseñadores siguen usando Figma para definir y mantener sistemas de diseño a lo largo de productos y plataformas enteras, y en esos casos Figma es la fuente de verdad
En mi equipo también trabajamos así, y yo soy ingeniero frontend, pero honestamente extraño muchísimo la forma anterior
Como las especificaciones escritas fueron reemplazadas por prototipos funcionales, ahora existe una carga cognitiva extra: tengo que leer el código y decidir cuál es el cambio intencional y qué ruido hay que desechar
Me pasan un PR generado y tengo que decidir si hago los cambios necesarios sobre eso o si lo rehago desde cero, y en ambos casos hay fricción
A veces se generaron un montón de cambios no intencionales, yo dediqué tiempo a reimplementarlos, y después más tarde llega el “ah, perdón, eso no era algo que queríamos cambiar”
Entiendo que esto da más autonomía, pero también le quitó parte del disfrute que sentía en mi trabajo y lo convirtió en un dolor de cabeza
Diseño y producto hacen vibe design/vibe coding de funcionalidades o experiencias con Claude, arman prototipos rápido y los llevan frente a clientes para recibir feedback con el mínimo tiempo de ingeniería posible
Eso está buenísimo
Pero puede sorprender que, en conjunto, no haya ayudado mucho a lanzar más rápido
Creo que la razón es que en el proceso se perdió pensamiento
Una parte nada menor del razonamiento ahora está tercerizada al modelo de lenguaje
Tapa los huecos del prompt y rellena con alucinaciones los comportamientos no especificados
Antes uno se detenía con cosas como “esto no termina de encajar”, “¿cómo comunico esta idea?”, “¿qué pasa en este caso?”, pero ahora eso desapareció y esos detalles se empujan para después, cuando ya está construido
Claro que podemos mejorar el proceso y revisar cómo aprovechar mejor esta nueva técnica, pero no sé si de verdad sea mejor que antes
Está quedando obsoleta
Ahora la gente de backend también hace frontend
Esa es la confusión
¿Te pones a mirar el ensamblador generado por el compilador? No
Entonces, ¿por qué estás mirando este código?
Lo que hicimos fue subir el nivel de abstracción
Yo también uso mucho el mismo enfoque
Incluso antes de la IA lo hacía así, de forma manual
Primero me sentaba con el usuario con solo pluma y papel, y después armaba rápido un POC o demo de frontend, dejaba que el usuario lo probara y luego lo ajustaba hasta que funcionara como quería
Para mí, hacer en código un demo rápido de frontend, no con calidad de producción, muchas veces ya era más rápido que crear interacciones precisas en Figma
Como permitía una interacción completa, podía detectar muchos más casos límite del lado de la experiencia de usuario
Ahora, gracias a Claude Code, hacer prototipos desechables se volvió más rápido, pero no es una diferencia enorme
Como el 80% del tiempo total se va en hablar con el usuario y pensar cómo debería funcionar, Claude más o menos reduce a la mitad el 20% restante frente a cuando lo construyo rápido yo mismo
La primera versión sale más rápido, pero iterar es más lento cuando no lo has entendido por completo
Edwin, qué gusto ver que publicaste esto
Recuerdo que participamos juntos en un hackatón por ahí de 2012/2013
La capacidad de llegar más rápido a un prototipo funcional da muchísimo impulso, incluso si existe la tentación de publicar tal cual una idea todavía incompleta
El diseño y los requisitos de experiencia de usuario se benefician enormemente cuando puedes ir más allá del storyboard y el wireframe, y tocar y experimentar el flujo real