Decálogo para abordar tu primer proyecto de Vibe Coding

Hoy le he contado a alguien en una conversación cuál es la experiencia que tenemos en el Estudio para trabajar con herramientas de inteligencia artificial en el ámbito del diseño de producto y la investigación con usuarios. Normalmente cuando salgo de las reuniones de trabajo me tomo unas notas de voz para después ordenar mis ideas. Y este es el resultado de la evolución de una de esas ideas. Algo así como un decálogo para abordar un proyecto de Vibe Coding para diseño de producto.

Lo comparto porque seguro que alguien le puede servir o de inspiración o de guía.

Define el problema antes de abrir la herramienta

Parece obvio pero no lo es. La tentación de lanzarte a escribir prompts es muy grande. Pero si no tienes claro qué problema resuelves, para quién y en qué contexto, vas a construir una solución en busca de problema. Eso no es producto, eso es entretenimiento. Que no está mal, pero es otra cosa.

Empieza en pequeño

Tu primera aplicación no tiene que ser un SaaS con autenticación, base de datos, pagos y notificaciones. Tiene que ser algo simple, que funcione, que puedas usar tú mismo mañana. Una sola funcionalidad, bien resuelta. Todo lo demás vendrá después, si es que tiene que venir.

Escribe un brief de producto, no una lista de funcionalidades

Antes de hablar con la IA, escribe en un documento quién va a usar esto, en qué situación, qué necesita resolver y cuáles son los criterios de éxito. Ese documento es tu ancla. Es la fuente de la verdad. Cada vez que la herramienta te proponga algo brillante pero innecesario, que sucederá, vuelves a él.

Elige una sola herramienta y aprende a dominarla. Lovable, Mocha, Cursor… da igual

Lo peor que puedes hacer es saltar de una a otra buscando la perfecta. Cada herramienta tiene su lógica, su forma de conversar, sus limitaciones. Necesitas tiempo para entenderla. Elige una y quédate con ella hasta que la conozcas de verdad. Lleva tiempo. Yo la que más a menudo utilizo es Mocha.

Trata la conversación con la IA como un proceso de diseño

Esto no va de dar una orden y esperar un resultado mágico. Esto es iterar. Pides, revisas, ajustas, vuelves a pedir. Y vuelves a empezar. Exactamente igual que cuando haces un prototipo con un equipo de desarrollo. La diferencia aquí es la velocidad, no tanto la naturaleza del proceso.

No aceptes el primer resultado visual

Las herramientas de las que estamos hablando generan interfaces que se parecen todas entre sí. Si te quedas con lo que sale por defecto, tu aplicación será una más del montón. Invierte tiempo en la dirección visual: referencias, paletas, tipografías, densidad de información. El criterio estético es tuyo, no de la máquina. Por mucho que parezca que lo va a hacer bien, el resultado será infinitamente mejor si guías a la herramienta.

Prepárate para lo que no se ve

Autenticación, gestión de errores, estados vacíos, persistencia de datos, permisos, rendimiento, edge cases. La parte invisible del producto es la que marca la diferencia entre algo que funciona en una demo y algo que puedes usar de verdad todos los días. Esto es lo que más vas a aprender, y lo que más te va a cambiar la perspectiva. Y si no te lo crees, pruébalo y verás. Eso sí, quizá que tengas que googlear para aprender a manejar algunos conceptos, pero de eso se trata. Esto es un proceso de aprendizaje.

Documenta lo que haces y lo que aprendes

No para publicarlo (aunque puedes hacerlo si quieres), sino para ti. Qué prompts funcionan, qué errores aparecen de manera recurrente, qué decisiones tomas y por qué. Esa documentación es tu verdadero aprendizaje, no tanto la aplicación en sí.

Usa tu propia aplicación

Parece una tontería, pero muchos proyectos personales se abandonan el día que se terminan. Úsala. Todos los días si puedes, mejor. Ahí es donde descubres los problemas reales, donde el diseño confronta con el uso y donde aprendes que construir producto no es sólo lanzar, es mantener.

Recuerda que la herramienta ejecuta, pero el criterio es tuyo. Esto es lo más importante

La IA no tienen ni la más remota idea acerca de si tu producto tiene sentido, si resuelve una necesidad real, si la arquitectura de información es coherente o si la experiencia es buena. Eso lo sabes tú. Y solamente tú. El conocimiento profesional (de diseño, de investigación con usuarios, de producto) es lo que convierte el vibe coding en algo útil de verdad, y no en un juguete con el que pasar el rato.


Esto es lo que he aprendido, después de muchos, muchos meses de trabajo intenso, de pruebas, de aprendizajes, de equivocarme, de sorprenderme, de disfrutar y ahora mismo de compartir.

Publicado por

torresburriel

Llevo más de 20 años trabajando en diseño digital e investigación con usuarios. Soy CEO de Torresburriel Estudio, miembro español de UXalliance, presidente de UXPA Spain y autor de tres libros sobre diseño digital.

2 comentarios en «Decálogo para abordar tu primer proyecto de Vibe Coding»

  1. Me he visto reflejado. Llevo un par de meses así y después de algunos proyectos pequeños te das cuenta de que los bichos estos (de momento) son MUY capaces de hacer cosas MUY inútiles si no los diriges MUY bien. XD

    Lo he pasado al equipo. Reflexiones directas y acertadas!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *