Hace unas semanas grabé una conversación con Rodri Valdez para el Girocast, el podcast de Girolabs. Hablamos una hora de cómo llegué al diseño de producto desde la ingeniería informática y de cómo uso la inteligencia artificial en mi trabajo hoy. El episodio completo está en YouTube.

Si tuviera que resumir la parte de IA en dos líneas: me cambió cómo junto el contexto de cada proyecto y me hizo empezar por un prototipo en código en lugar de pantallas en Figma. El resto del proceso (presentar al cliente, pasar las aprobaciones, documentar para desarrollo y hacer seguimiento) sigue bastante parecido a como era antes. Acá lo ordeno por escrito.

¿Qué es el context engineering y por qué me importa más que la herramienta?

Es darle al modelo información estructurada de tu proyecto para que trabaje sobre algo real. Los modelos van a seguir mejorando solos. Lo que ninguno va a traer de fábrica es lo que se habló en tu última reunión con el cliente.

Por eso grabo todas mis reuniones, siempre pidiendo permiso antes. Cada transcripción pasa por una estructura de carpetas por proyecto, con los datos de negocio y lo que ya se aprendió en proyectos anteriores. Cuando arranco algo nuevo, lo primero que hago es pedirle al agente que junte todo lo que ya existe sobre el tema. Con eso a mano me siento bastante más inteligente de lo que soy.

En Paraguay esto pesa el doble. Muchas empresas locales casi no tienen presencia online, y si le pedís a un modelo que investigue el mercado va a encontrar poco. El discovery acá se hace hablando con gente: los directores y cada departamento, empezando por el comercial. La diferencia está en guardar esas conversaciones para que después sirvan.

No hablo de herramientas específicas a propósito. Cambian cada tres meses, y una lista de mi stack quedaría vieja antes de que termines de leerla.

¿Por qué empiezo con un prototipo en código y no en Figma?

Porque las pantallas en Figma son fotos del producto, y el producto es una película. Nunca estás mirando una pantalla quieta: estás apretando un botón o equivocándote en un campo. Un prototipo interactivo muestra eso de entrada.

Antes, llegar a tener algo sobre lo cual conversar costaba semanas, porque hacer pantallas cuesta. Hoy, si el lunes tengo la reunión de arranque, el martes llego con algo que se puede tocar. La primera conversación ya gira alrededor de preguntas concretas: qué no estoy teniendo en cuenta, o si este cambio se puede hacer.

Un consejo chico que me sirvió mucho: todos mis prototipos comparten el mismo marco. Arriba hay una barra. A la izquierda tiene botones para cambiar de estado (opción uno, opción dos, el flujo feliz, el flujo con error). A la derecha tiene la documentación de diseño, que es lo que el prototipo no dice solo: qué interacciones cubre y qué preguntas siguen abiertas. Una vez compartí uno con un project manager y me enteré después de que lo estaba usando en sus propias entrevistas con el equipo de cuentas.

¿Para qué sigo usando Figma?

Para comentar y para el detalle fino. Es muy fácil que alguien deje un comentario del tipo “este botón no me convence” sobre un frame. Y hay cambios que por texto no tienen sentido: algo desalineado tres píxeles, un border radius de seis que tiene que ser cuatro. Ahí paso a Figma, ajusto, y después sincronizo con el prototipo. Ser experto en Figma nunca me dio mucho orgullo, pero sigue siendo la mejor herramienta para esa parte.

Si la IA me hace más rápido, ¿entrego antes?

Casi nunca. El tiempo que me ahorro en hacer pantallas lo uso para dejar que la idea repose. Hacer las cosas más rápido solo por hacerlas más rápido no me da nada.

Mientras hacés pantallas a mano también estás pensando, y si te saltás esa parte perdés tiempo de masticar el problema. Me pasó en empresas anteriores: me apuraban para entregar, lanzábamos, y dos semanas después me aparecía en la cabeza el caso que no habíamos pensado. Tocaba escribirle a alguien y arreglarlo en producción. Así que estiro todo lo que el deadline permite, juego con el prototipo, pruebo varias soluciones al mismo problema y dejo que las conexiones aparezcan solas.

¿Qué parte del diseño no va a reemplazar la IA?

El criterio y la articulación. Percibimos muchas más señales de las que creemos, y buena parte de ese procesamiento es emocional. Eso influye en cómo diseñamos y en cómo alguien usa una app, hasta en cómo escribimos un prompt. No puedo señalar exactamente qué parte no se va a poder reemplazar, pero tengo la convicción de que si sacás a la persona y quedan agentes hablando con agentes, el resultado va a ser peor.

La articulación la veo todavía más lejos. Decirle a un cliente que su departamento no tiene cómo sostener el proceso que está pidiendo, y convencerlo, es trabajo con personas. Un diseñador no hace nada solo; su trabajo es poner de acuerdo a gente que piensa distinto.

¿Qué recomiendo para seguir aprendiendo?

Seguir a la gente de los laboratorios que está construyendo cosas, sin tragarse todo el hype. Y el contenido de Y Combinator: los ensayos de Paul Graham y los videos de Startup School. Está pensado para fundadores, pero aprendí mucho de ahí, de ventas por ejemplo, y es de lo poco que no envejece con cada modelo nuevo.

En el episodio está todo esto con más ejemplos, además de la historia de cómo pasé de informática a diseño gráfico y de ahí a producto.