A muchos diseñadores de UX y de producto nos pasa lo mismo. Diseñamos bien, pensamos bien la experiencia, pero todo se frena cuando hay que llevarlo a algo real. El prototipo funciona, pero el producto no existe. Y ahí casi siempre dependemos de ingeniería.
Eso ha sido lo normal durante años, yo lo he vivido muchas veces.
Qué está cambiando
Lo que está cambiando es la forma de construir. Cada vez veo a más diseñadores creando cosas reales sin esperar a nadie. Aquí aparece el vibe coding.
El vibe coding consiste en decirle a una IA lo que quieres hacer con palabras normales. Explicas la idea, el flujo y el comportamiento. La IA se encarga del resto.
Esto no va de jugar a ser developer… va de no quedarte bloqueado.
Cuando este enfoque se combina con un backend como Supabase, el salto es evidente. Hablo de Supabase porque es la que estoy usando ahora, pero esto aplica igual a Firebase u otras soluciones similares. La herramienta importa menos que el enfoque.
Supabase te da lo justo para probar ideas rápido: base de datos, usuarios y almacenamiento, sin montar nada desde cero.
MCP en la práctica (ejemplos reales de UX)
Aquí no voy a explicar qué es MCP, prefiero contar cómo lo uso mientras diseño.
A grandes rasgos, un MCP es lo que permite que una IA se conecte a tu proyecto y trabaje con datos reales, no con información inventada.
Ejemplo 1: formularios que no mienten
Estoy diseñando un formulario de registro.
En lugar de simular estados con textos inventados, le pido a la IA que cree la tabla real y empiece a guardar datos.
A partir de ahí, diseño viendo errores reales, campos mal rellenados y usuarios que abandonan a mitad. Ajusto mensajes, jerarquía visual y microcopy con información real, no con supuestos.
El formulario deja de ser una pantalla bonita y pasa a ser una parte viva del producto.
Ejemplo 2: contenido dinámico para validar layouts
Estoy trabajando un listado, una tabla o un dashboard.
Le pido a la IA que lea datos existentes de la base de datos y los pinte en la interfaz.
De repente veo problemas que en Figma no aparecen: textos demasiado largos, estados vacíos, filas que no caben o casos límite.
No rediseño “por intuición”. Ajusto el diseño porque el contenido real me obliga a hacerlo.
Ejemplo 3: decidir qué se queda y qué se va
Estoy dudando si añadir una funcionalidad nueva o dejarla fuera.
Es una de esas ideas que sobre el papel suenan bien, pero no tengo claro si aportan algo real.
En lugar de diseñarla “por si acaso”, le pido a la IA que mire cómo se está usando ahora mismo el producto. Qué acciones se repiten, cuáles se ignoran y en qué punto se quedan los usuarios.
Con eso decido si esa funcionalidad merece la pena, si hay que replantearla o si directamente es ruido.
No es analítica avanzada ni dashboards complejos. Es la información justa para no diseñar a ciegas.
Diseñar y construir a la vez
Cuando trabajas así, el diseño deja de ser una simulación.
Diseñas con datos reales y flujos que funcionan. Ajustas sobre lo que pasa de verdad, no sobre lo que crees que pasará.
La velocidad cambia… un MVP puede estar listo en horas, no para escalar, sino para decidir.
También cambia la relación con los developets. Cuando alguien entra después, entra a algo que ya existe y se puede tocar.
Nada de esto va de perder control. Puedes definir reglas básicas, como que cada usuario solo vea lo suyo. A eso se le suele llamar seguridad a nivel de filas (Row Level Security), pero en el fondo es sentido común.
Recuerda, el diseñador decide y la IA ejecuta.
Aquí hay un cambio claro: el diseñador no solo define pantallas, participa en cómo se construye y cómo se prueba un producto.
Quien entienda este enfoque va a tener más margen… quien no, seguirá entregando enlaces de Figma.
Una cosa más…
Usar IA para escribir en una base de datos está bien.
Hacerlo sin una mínima capa de seguridad es mala idea, sobre este tema hablaré en el próximo post.
Aprende sobre UX/UI + IA, Figma y Product Design
📣 Apúntate a mi newsletter semanal
