Diseñar para algo que el usuario no sabe que quiere
Cuando empecé a trabajar con agentes de IA cometí el error que comete casi todo el mundo: intenté aplicar el proceso de siempre. Observar al usuario, identificar la fricción, reducirla. El problema es que ese proceso asume algo que con agentes no se cumple — que el usuario tiene un problema que puede articular, aunque sea mal.
Con agentes el usuario no tiene una tarea frustrada. Tiene una capacidad nueva que no sabe cómo convertir en intención.
“El cuello de botella nunca fue la construcción. Siempre fue el pensamiento.” — Alfonso Morcuende
Estoy de acuerdo. Pero hay un caso que ese principio no contempla del todo: qué pasa cuando el pensamiento tampoco puede arrancar porque el problema todavía no existe como tal. No es que el equipo no quiera pensar — es que el producto es tan nuevo que la pregunta correcta tampoco está disponible todavía.
Esa es la trampa específica de los agentes. Y confundirla con falta de rigor es un error.
En una sesión con un cliente, en medio de una demo, alguien preguntó si el sistema podría aprender a trabajar como lo hace una persona concreta de su equipo. No era una petición de feature. Era la primera vez que esa persona se permitía imaginar lo que el producto podría llegar a ser. Y en esa pregunta había más información sobre sus necesidades reales que en todo el briefing previo.
Eso no sale en un research tradicional. Sale cuando pones algo real delante de alguien y le dejas reaccionar sin guión.
Pero aquí viene el matiz que más me ha costado entender: trabajar en incertidumbre no es una excusa para saltarse el problema. Es exactamente lo contrario. Cuando el usuario no sabe lo que quiere, la tentación del equipo es lanzarse a construir — explorar, iterar, ver qué pasa. Y eso, sin un problema aunque sea provisional que lo ancle, no es agilidad. Es ruido con buenas intenciones.
Lo que he aprendido trabajando en los dos lados — definiendo qué debería hacer el agente y diseñando cómo el usuario interactúa con él — es que la incertidumbre tiene dos capas que no son lo mismo. La incertidumbre sobre la solución es legítima y esperable con productos nuevos. La incertidumbre sobre si hay un problema real es otra cosa. La primera se gestiona con prototipos y observación. La segunda no se gestiona — se resuelve antes de avanzar, o te cobra el precio después.
El prototipo en este contexto no es una validación. Es una herramienta para generar la pregunta correcta. Pones algo delante del usuario no para confirmar lo que ya crees, sino para ver qué descubre. La información está en la pausa, en el “¿y esto también podría...?”, en la reacción que nadie te habría dado en una entrevista. Pero esa reacción solo tiene valor si sabes a qué problema estás intentando responder. Si no, es una reacción interesante que no te lleva a ningún sitio.
Eso no es UX en el sentido habitual. Es trabajo editorial y estratégico al mismo tiempo — decidir qué historia cuenta el producto sobre sí mismo antes de que el usuario tenga criterio para evaluarla, y hacerlo con un norte aunque sea borroso.
El diseñador senior en este contexto no es el que tolera mejor la ambigüedad. Es el que sabe distinguir qué tipo de incertidumbre tiene delante — y actúa en consecuencia.
Escribo sobre diseño de producto, estrategia e IA desde dentro. Si quieres seguir leyendo, suscríbete.