Contexto
Soy Product Designer y, como cualquiera en mi lugar, mi proceso de trabajo siempre fue el mismo: [más allá de las etapas de discovery con usuarios] abrir Figma, especificar cada pantalla y cada interacción, sesiones largas de handoff a desarrollo y por último QA para validar lo que desarrollo construyó.
Hace unos meses empecé a probar algo distinto: dejar de simular la interfaz y directamente construirla, con el design system real de la empresa, el mismo que se utiliza para todo, ayudado por herramientas de código asistido por IA.
Aquí les cuento un poco más sobre cómo trabajaba antes, qué cambió, cómo trabajo ahora y qué habilita este nuevo proceso.
Así se veía, paso a paso, el proceso completo.
Cómo trabajaba antes
Durante años mi día se organizaba igual. Abría Figma, armaba la pantalla, pensaba la interacción, la anotaba al margen porque Figma no la podía mostrar de verdad. Después la mandaba a desarrollo y esperaba. A veces el resultado se parecía a lo que había imaginado. A veces no, y ahí empezaba la ronda de ajustes: yo explicando de nuevo algo que ya había explicado, desarrollo interpretando algo que nunca terminó de estar del todo claro.
No era un mal proceso. Era el proceso normal. El que todos usan. Pero cada traspaso perdía algo en el camino.
const handleOpen = () => {// TODO: ¿Cómo era la animación exacta?setIsOpen(true);};Qué cambió
En algún momento empecé a mirar de reojo lo que estaba pasando con las herramientas de código asistido por IA. No como algo lejano, de programadores, sino como algo que de repente estaba a mi alcance. Nunca aprendí a programar en serio. Pero con estas herramientas, entender cómo se arma una interfaz por dentro dejó de ser un mundo aparte.
Le propuse a un compañero probarlo en serio, no como curiosidad de fin de semana sino como una forma real de trabajar. La pregunta era simple: ¿y si el prototipo dejaba de ser una simulación y pasaba a ser algo que de verdad funciona?
Cómo trabajo ahora
Hoy cuando diseño una funcionalidad nueva, la escribo. Uso el design system real de Mango, no una versión simplificada armada para ir rápido. Y contra lo que podría pensarse, no es más lento: es más rápido y más realista, porque no hay nada que simular. Lo que el usuario ve cuando testea es exactamente lo que existe en el sistema de la empresa. No una promesa de cómo se va a ver. Cómo se ve.
Para esto trabajo sobre un repo paralelo al del producto real, donde tengo libertad para probar y romper cosas sin ningún riesgo para lo que está en producción. Está desplegado en un proyecto de Vercel corporativo, con las mismas normas de seguridad que cualquier otro proyecto de la empresa. Y aunque tengo libertad para experimentar, no programo libremente: uso el design system real y sigo parámetros de código ya establecidos, para no salirme de la norma y que lo que construyo sea reutilizable.
Los usuarios entran desde su propio ordenador con una URL, nada más, y la experiencia que tienen al testear es fantástica: todo tiene interacción real y datos reales, nada es cartón piedra. Antes, sentar a alguien frente a un prototipo de Figma siempre tenía esa fricción inicial, esa sensación de estar viendo una maqueta. Ahora entran a algo que funciona de verdad, y eso cambia la conversación. Las pantallas ya nacen responsive, sin ese trabajo extra de simular cómo se comportarían. Y lo que se testea es, pixel a pixel, exactamente lo que se va a construir.
No lo pienso como un experimento que estoy probando por curiosidad. Es cómo trabajo ahora. Documento en código, testeo con usuarios reales, ajusto lo que no funciona, y lo que le entrego a desarrollo ya viene validado.
// Acceso directo por URL real
const session = await createTestUserSession({
prototypeUrl: "https://mango-internal-proto.app/flow/journey",
device: "User Laptop"
});Sin instalar nada.
El usuario abre una URL en su propio navegador y ya está dentro.
Eliminamos la fricción inicial de las presentaciones en Figma. El testeo ocurre en el entorno natural del usuario, sin Plugins de maquetas ni guías explicativas adicionales.
Qué habilita
Cuando el prototipo ya funciona de verdad, dejo de tener que explicar cómo se comporta algo. Se comporta así porque está corriendo. Eso saca ambigüedad del medio, y ya veo señales de que también acorta lo que después le toma a desarrollo construirlo — aunque todavía es pronto para tener ese número cerrado.
Pero lo que más me importa de esto no es la velocidad. Es que entrego algo distinto. Ya no una idea para que otro la resuelva, sino algo que ya resolví. Es la misma dirección en la que quiero seguir moviéndome: hacia un lugar con más decisión real sobre el producto, no solo sobre su forma.
Un solo flujo unificado de Producto
Toma de decisiones de UX, interacción y flujos con usuarios reales.
Construcción directa usando los mismos componentes reales de la empresa.
Conclusión
No cambié de oficio. Sigo pensando en usuarios, en flujos, en fricción. Lo que cambió es la herramienta con la que pruebo si esas decisiones están bien. Diseñar en código no reemplaza el pensamiento de producto. Lo hace más difícil de esconder cuando algo no funciona.