La IA y el desafío de construir método en un entorno que no deja de iterar

Una reflexión sobre IA, UX y el aprendizaje de encontrar foco cuando las herramientas, los procesos y las certezas cambian todo el tiempo.

La primera vez que abrí una herramienta de IA para trabajar, me quedé mirando la caja de texto sin saber qué escribir.

Tenía una pantalla en blanco, infinitas posibilidades y una sensación extraña de bloqueo. Sabía que había algo poderoso del otro lado. Que probablemente podía ayudarme. Pero no entendía cómo conversar con esa herramienta ni cómo transformarla en algo útil para mi trabajo.

Creo que quienes trabajamos en tecnología hemos pasado por ese momento.

Después apareció la presión de entenderla rápido, miras alrededor y parece que otras personas ya la usan con soltura, como si siempre hubieran tenido un manual que a ti nunca te entregaron. Ves demos, automatizaciones y flujos que parecen increíbles, y empiezas a sentir que quizás vas tarde en una carrera que todos quieren ganar.

Es parecido a tomar una consola de videojuegos nueva. Intuyes que tiene una lógica, que no puede ser tan difícil, pero hasta que no empiezas a jugar, fallar, probar combinaciones y reconocer patrones, no le encuentras el ritmo. Mientras tanto, ahí estás, apretando botones sin saber muy bien qué estás haciendo, esperando que algo funcione, equivocándote, intentando de nuevo y entendiendo poco a poco qué hace cada comando.

Eso fue exactamente lo que vivimos en mi equipo.

En ese momento estaba atravesando un acting de Technical Lead, un rol que me puso en un lugar de acompañamiento y mentoría para UX. Eso me permitió mirar el proceso desde varios frentes al mismo tiempo. Las necesidades del equipo, las conversaciones con producto y desarrollo, y el desafío de ayudar a ordenar la incertidumbre mientras todos aprendíamos juntos.

Entre pruebas, errores y muchos intentos por lograr ese “perfect” que nunca llegaba tan rápido como imaginábamos, fuimos recorriendo un camino mucho menos lineal de lo esperado. Y el aprendizaje más importante llegó antes de lo que pensábamos.

La IA no nos hacía más ágiles por arte de magia. Nos hacía más rápidos cuando ya sabíamos hacia dónde queríamos ir.

Aprender en un terreno que no para de moverse

Al principio, todos estábamos en modo explorador. Cada persona avanzaba a su ritmo, probando herramientas y tratando de moverse en medio de algo que cambiaba constantemente.

El problema era que, mientras intentábamos aprender, seguían apareciendo nuevas versiones, nuevos modelos y nuevas formas de resolver lo mismo. Cuando creías que por fin habías entendido algo, salía una actualización que te hacía reconsiderar parte de lo aprendido. Podías pasar horas armando un sistema que funcionaba, mostrarlo con entusiasmo y, un par de días después, descubrir que ya había quedado obsoleto.

Entonces aparecía esa sensación extraña. Por un lado, estabas aprendiendo muchísimo. Por otro, sentías que no avanzabas lo suficiente.

Y ahí también se movía algo más personal. Cuando llevas años construyendo criterio, método y experiencia en tu disciplina, enfrentarte a una herramienta que parece cambiar las reglas del juego puede hacerte cuestionar tu propio seniority. Te preguntas si deberías entenderlo más rápido, si tus habilidades siguen siendo suficientes, si lo que sabes todavía alcanza.

Esa inseguridad es una de las partes menos visibles del primer contacto con la IA. No se trata solo de aprender a usar una herramienta. Se trata también de aprender a tolerar la incomodidad de no dominarla todavía.

Aprender algo nuevo también implica aceptar, por un rato, que no tienes todas las respuestas.

Para quienes venimos del diseño, hubo algo extra que no esperábamos. De pronto empezamos a acercarnos a conceptos que antes parecían territorio exclusivo de desarrollo, como automatizaciones, orquestación, lógica de backend y agentes. No como expertos, claro. Pero sí con una mirada más amplia.

El lenguaje del equipo empezó a cambiar. Empezamos a entender mejor cómo piensan quienes construyen lo que diseñamos, qué restricciones aparecen del otro lado y qué posibilidades se abren cuando diseño también entiende un poco más de la lógica técnica detrás de las soluciones.

Y eso no tiene precio.

La trampa del entusiasmo colectivo

Después vino otra etapa. El momento de mostrar lo aprendido.

Empezaron las reuniones de área, las demos, las herramientas compartidas, los casos de uso. Había mucho entusiasmo y también una sensación nueva. Todos parecíamos estar corriendo una carrera para demostrar quién dominaba más rápido estas nuevas herramientas. Casi como si el que más rápido entendía, más valor podía aportar.

El FOMO tenía su lógica. Si todos están mostrando algo y yo no tengo nada que mostrar, ¿me estoy quedando atrás? Esa presión generó aprendizaje y conversaciones que probablemente no habríamos tenido de otra forma. Pero también generó dispersión.

De pronto, lo importante parecía ser avanzar. Hacia dónde, con qué objetivo o para resolver qué problema específico podía quedar para después.

Y ahí apareció el primer problema real. Mucho de lo que veíamos en otros equipos no aplicaba a nuestra realidad. Trabajamos en productos complejos, B2B, SaaS, con impacto directo en revenue. Lo que para otros equipos podía ser una mejora evidente, para nosotros podía convertirse en una distracción o en una forma de simplificar demasiado un problema que necesitaba más contexto.

Tardamos un rato en aceptarlo.

Una herramienta puede servir para muchos, pero no todas sirven para uno.

En nuestro caso, no se trataba simplemente de insertar una herramienta nueva dentro de un proceso existente. Era más parecido a intervenir un engranaje complejo que llevaba años tomando forma. No bastaba con poner una pieza nueva y esperar que todo mejorara. Había que entender cómo esa pieza se relacionaba con todo lo demás.

Eso nos obligó a hacer algo necesario. Dejar de mirar tanto hacia afuera y empezar a mirar hacia adentro.

Velocidad sin dirección no es agilidad

Cuando empezamos a entender mejor nuestros propios procesos, también vimos con más claridad dónde la IA realmente podía aportar. No en abstracto, no porque una herramienta se viera impresionante en una demo, sino porque resolvía una fricción concreta de nuestro día a día.

Un ejemplo muy claro fueron las traducciones.

Trabajamos con productos que operan en múltiples mercados, lo que significa que cada pieza de contenido, cada copy de interfaz y cada ajuste en la experiencia necesita existir en más de un idioma. Eso tiene muchas capas: contexto, tono, consistencia, precisión técnica y adaptación cultural. Antes, ese proceso podía tomar días. Con IA, se redujo a horas.

Pero lo importante no fue la velocidad en sí. Fue para qué usamos ese tiempo ganado. Revisar si el tono era el correcto, si el mensaje encajaba con el contexto cultural, si la pieza mantenía coherencia con el resto del producto. La IA se encargó de una parte repetitiva y pesada del proceso para devolvernos tiempo de mejor calidad. El criterio humano seguía siendo necesario, pero ahora tenía más espacio para operar donde realmente importaba.

Después vimos el otro lado.

En un momento quisimos hacer un tipo de sesión de ideación con una nueva version tipo POC rápida. Reunir al equipo, lanzar prompts y prototipar en tiempo real con HTML generado por IA. Rápido, dinámico, ágil. La propuesta tenía sentido en el papel.

Pero lo que parecía prototipado era, en realidad, otra cosa.

Estábamos usando la IA para evitar una conversación que todavía no habíamos tenido.

Nadie había definido con claridad qué problema se quería resolver. No había un brief suficientemente claro, no había acuerdo sobre qué esperaba cada parte ni sobre cuál era la solución que realmente debíamos construir para responder a la necesidad de nuestros usuarios. El resultado fue predecible: un ciclo interminable de “muévelo para allá”, “no me convence ese color”, “espera, ¿para qué usuario es esto?”. Más tiempo, más confusión, menos resultado.

La IA generaba cosas, sí. Pero nadie sabía si iban en la dirección correcta, porque la dirección correcta nunca se había discutido.

Ahí está la diferencia entre los dos casos. En las traducciones, la fricción era concreta y conocida. Sabíamos qué necesitábamos y dónde seguía siendo necesario el juicio humano. En la ideación sin norte, intentamos usar la IA antes de tener acuerdo.

Sin acuerdo, la velocidad no se convierte en agilidad. Se convierte en movimiento hacia ningún lado.

Construir método en un terreno que se mueve

Desde el rol de acompañamiento y mentoría, esta parte del proceso fue la que más me hizo reflexionar. No solo por las herramientas que probamos o los resultados que obtuvimos, sino porque me obligó a mirar más allá de la adopción de IA como herramienta y pensar en cómo construimos criterio y foco como equipo.

Y ahí entendí algo que cambió la forma en que pienso sobre todo esto.

La IA no reemplaza el alineamiento del equipo. Lo amplifica. Para bien o para mal.

Si el equipo tiene claridad, criterio compartido y un problema bien definido, la IA puede acelerar el trabajo de maneras que antes parecían impensables. Pero si el equipo no tiene eso, la IA solo hace más rápido aquello que ya estaba desordenado. Genera más versiones, más iteraciones y más decisiones aparentes sobre una base que aún no está resuelta.

Todos hablan de agilidad. Pero la IA no agiliza el acuerdo.

No puede definir por ti cuál es el problema real, qué necesita el usuario, qué está dispuesto a construir el equipo de desarrollo o qué tiene sentido para el negocio. Eso sigue requiriendo conversación humana, criterio compartido y tiempo de alineamiento. Ninguna herramienta puede reemplazar esa parte.

Por eso, el camino que hoy estamos probando parte de algo que suena simple, pero cuesta más de lo que parece. Volver a los fundamentos del UX antes de abrir cualquier herramienta de IA. Antes de pedirle algo, necesitamos tener claridad sobre qué problema queremos resolver, para quién, con qué restricciones y qué tipo de resultado esperamos obtener.

Sin eso, la IA no tiene suficiente contexto para aportar valor. O peor, empieza a trabajar sobre supuestos que nadie validó.

Y para productos complejos, aprendimos algo concreto. Funciona mejor pedirle a la IA que construya por bloques, no todo de una vez. Así los cambios son más manejables, las iteraciones tienen más foco y evitas terminar sosteniendo un castillo de naipes que nadie sabe cómo modificar sin que todo se caiga. Parece un detalle, pero es una diferencia enorme en el día a día.

Todo esto todavía está en prueba. No es una metodología cerrada. Es el camino que hoy nos está funcionando después de haber pasado por la incertidumbre inicial, el FOMO y los intentos que nos mostraron lo que no queríamos repetir. Y digo “hoy” porque, si algo aprendimos, es que nada se mantiene quieto por demasiado tiempo.

La IA puede acelerar muchas cosas. Pero el trabajo previo sigue siendo humano: el alineamiento, el brief y esa conversación incómoda donde alguien pregunta “¿pero para qué es esto exactamente?”.

Eso no te lo resuelve ninguna herramienta.