Prototipando en producción

El proceso de siempre

El flujo tradicional de diseño de producto es conocido, y en general siempre nos hemos preocupado de mantenernos al día con buenas prácticas y tecnología de punta:

1. El equipo de Producto arma un spec: una definición clara en un documento de Notion sobre qué se quiere construir y por qué.
2. El equipo de Product Design lo toma y construye prototipos en Figma. Se itera con producto y stakeholders, se diseñan los casos borde, se pulen las interacciones.
3. Cuando todo está listo, se entrega a desarrollo para implementar.

Funciona, pero tiene una fricción natural. Cada vez que un diseño pasa de Figma a implementación hay pérdidas. Pueden ser cosas menores: un spacing que cambia, una interacción que se siente distinta; o cambios mayores como cambios de scope que quedan en el spec pero quizás no se actualizan o no hay tiempo para adaptar el Figma y se ve sobre la marcha. El prototipo rara vez es el producto real.

Cuestionando lo cómodo

Partimos el proceso de exploración en el mundo del vibe-prototyping usando lovable. Era un upgrade en velocidad pero seguía sin lograr transmitir la experiencia Fintoc como para imaginarse cómo se vería la solución real.

Por eso, decidimos ir ahora un paso más allá y probar si se podía lograr algo suficientemente low-code en Cursor, para poderse usar de forma rutinaria.

El equipo de Product Design ahora está empezando sus procesos de diseño iterando directamente sobre el dashboard de producción. Con Cursor corriendo localmente, promptean cambios en tiempo real usando los componentes reales del Design System que viven en el código. Diseñar directamente en código permite un nivel de fidelidad e interactividad imposible de replicar en mocks sin contexto: lo que diseñan se ve y se comporta exactamente como el producto final.

En la práctica, esto es:

• Prototipar sobre el dashboard en producción
• Usar componentes reales, no aproximaciones
• Diseñar y explicar ideas con experiencias interactivas

El setup

Para el equipo de Product Design corremos el dashboard de Fintoc localmente desde Cursor, conectado a la base de datos remota de staging a través de Doppler. Para acceder a la API de staging, que no está expuesta públicamente, usamos Twingate. Cada diseñador tiene permisos para el repositorio del dashboard en GitHub y acceso a staging en Doppler.

Esto permite probar localmente como usuarios reales del dashboard de staging, que tienen todos los productos activos como si fuera un entorno live, tanto para Chile como para México.

Usamos el Agent view de Cursor: un chat a la izquierda y una vista de navegador a la derecha. Esto le acomoda al equipo porque se siente literalmente como Lovable, versión Fintoc. Este formato de visualización esconde el código y deja al equipo enfocarse en la experiencia.

Dejamos una guía en Notion con dos comandos para levantar el entorno, considerando la arquitectura de Fintoc.

Tenemos Cursor conectado a Linear (software que usamos para Project Management) y GitHub. Para guardar una idea o feature, le pedimos a Cursor que cree una rama y guarde los cambios ahí. Así, si alguien quiere probar lo que diseñé, o quiero que otro designer siga haciendo cambios sobre eso, le paso el link a mi rama y pullea el código en su Cursor para verlo localmente.

Un punto importante: usamos el mismo código que el equipo de desarrollo. Eso lo podemos hacer porque ya tenemos guardrails en nuestros repositorios: tests, linters, estándares para crear PRs y un proceso de revisión que bloquea merges accidentales a producción. Todo esto aplica por igual a los cambios que pudiera alguien del equipo de Diseño mandar (por error o a propósito) al main branch. Por esto, no hay riesgo de subir código por accidente.

El rol de Figma en este nuevo flujo

Nos hemos cuestionado si esto reemplaza a Figma (o incluso a los diseñadores) y creemos que no.

Cursor no reemplaza Figma ni el proceso de diseño. Figma sigue siendo el espacio para pensar y explorar. Cursor suma una capa que acorta la distancia entre diseño e implementación.

Tampoco es "vibe coding": no se empuja código a producción. Es un entorno controlado para validar ideas con el contexto real del producto.

Cursor brilla cuando diseñamos sobre lo que ya existe: los datos, los componentes y los flujos que ya viven en el código. En cambio, cuando el trabajo parte desde cero (un producto nuevo, un flujo que requiere modelos de datos que aún no existen o cambios de estructura en el backend), Figma sigue siendo la herramienta.

Para innovar en experiencias que todavía no tienen soporte en el código, necesitamos un espacio libre para explorar, sin las restricciones de lo ya construido. Ahí es donde Figma destaca: pensar flujos nuevos, prototipar con datos ficticios e iterar sobre conceptos que todavía están tomando forma.

Lo que cambia es el momento en que entra cada herramienta: Figma para explorar lo que aún no existe. Cursor para diseñar, iterar y construir sobre lo que ya está en el producto. El valor está en saber cuándo usar cada una.

Lo que viene

Para mantener Figma vigente como espacio de documentación, queremos probar la nueva funcionalidad de Claude Code en Figma.

Estamos convencidos de que el code-based design nos va a ayudar a construir mejores interfaces, reducir tiempos de QA y re-trabajo, y mejorar la colaboración entre producto y desarrollo.

Esto recién empieza, y estamos explorando hasta dónde podemos llevar esta forma de trabajar.