Diseñar con IA

La mayoría de los equipos que he visto tratan la IA como una funcionalidad más, pegada encima del flujo de trabajo que ya tenían: un plugin de Figma que genera variantes de texto, una pestaña de ChatGPT resumiendo notas de investigación, un asistente escribiendo el primer borrador. Nada de eso está mal en sí mismo. El problema es que, usada así, la IA simplemente hereda lo que ya estaba roto en el proceso.

Un proceso improvisado no se vuelve más ordenado con IA de por medio. Se vuelve más rápido y sigue siendo improvisado. Las decisiones que nunca se documentaron no empiezan a documentarse bien; empiezan a documentarse mal con mucha seguridad. Y si el equipo no se ha puesto de acuerdo en qué está intentando conseguir, la IA optimizará para otra cosa sin avisar.

Un proceso poco claro no se vuelve más lento con IA. Se vuelve rápido, poco claro y, porque el resultado parece pulido, mucho más difícil de detectar a tiempo.

Lo que funcionó fue tratar la IA como cualquier otro problema de diseño de sistemas: fijar los inputs, los outputs, los traspasos, quién decide qué y cuándo: el flujo de trabajo primero, con la IA diseñada dentro de él después, no al revés.

La pregunta útil dejó de ser "¿qué puede hacer la IA?" y pasó a ser "¿dónde encaja esto de verdad en el proceso, y cómo sabría yo si no estuviera funcionando?" Más lenta de responder, pero es la que importa.

El framework organiza el trabajo de diseño asistido por IA en tres niveles de agentes que operan en cinco fases.

Los tres niveles

Nivel 1: el Orquestador ocupa la cúspide. Su trabajo es gestionar el contexto a lo largo de todo el proyecto: mantener el registro del proyecto, resumir los outputs de cada fase, coordinar los traspasos entre fases y escalar a los responsables de decisiones cuando algo es genuinamente ambiguo o relevante. El Orquestador no toma decisiones de diseño. Gestiona las condiciones bajo las cuales se toman las decisiones de diseño.

Nivel 2: Agentes de Fase son propietarios de una única fase: Descubrimiento, Definición, Apuesta, Construcción o Retrospectiva. Reciben inputs del Orquestador, coordinan los Agentes de Tarea dentro de su fase y producen outputs estructurados para revisión humana al final de la fase.

Nivel 3: Agentes de Tarea son especialistas con alcance muy específico. Un agente de análisis de restricciones. Un agente de síntesis de necesidades de usuario. Un agente de registro de decisiones. Un agente de monitorización de alcance. Cada uno hace una sola cosa dentro de su fase y produce un output estructurado que alimenta directamente la síntesis del Agente de Fase. Su especificidad es una característica, no una limitación: alcance estrecho significa responsabilidad clara y fallos contenibles.

Las cinco fases

Las fases siguen el ritmo central de la metodología Shape Up: el descubrimiento da forma al problema, la definición produce una propuesta, la apuesta compromete el alcance, la construcción lo ejecuta, y la retrospectiva hace evolucionar el propio framework. Cada fase tiene criterios de salida explícitos: condiciones que deben cumplirse antes de que el framework avance.

Esto importa porque previene el fallo más común en los flujos de trabajo asistidos por IA: fases que se completan técnicamente pero que no resuelven nada realmente. Los criterios de salida fuerzan la resolución. Evitan que la apariencia de progreso oculte su ausencia.

Por qué importa la estructura

La jerarquía de tres niveles no es burocracia. Es contención. Un agente que opera con un mandato demasiado amplio derivará. Un agente que recibe inputs mal definidos alucinará de forma plausible. La jerarquía crea las condiciones bajo las cuales cada agente puede ser fiable: alcance claro, inputs bien formados, outputs estructurados y una capa de revisión humana en cada transición significativa.

La jerarquía crea las condiciones bajo las cuales cada agente puede ser fiable. Alcance claro, inputs bien formados, outputs estructurados y una capa de revisión humana en cada transición significativa.

He dejado de fiarme de la frase "humano en el loop" por sí sola: cubre desde un rol de decisión real hasta un diálogo de confirmación que nadie lee antes de darle a aceptar. Muchos flujos de trabajo prometen supervisión humana y entregan un trámite.

El framework adopta una posición diferente: los checkpoints humanos deben ser puertas duras: momentos donde el flujo de trabajo literalmente no puede avanzar sin una decisión humana nominada. No una notificación. No un correo de resumen. Una decisión, con un registro de quién la tomó y por qué.

Cómo es un checkpoint genuino

Cada transición de fase significativa requiere un Bloque de Confirmación: un output estructurado de IA que captura el entendimiento actual del agente sobre el problema, los supuestos que lleva adelante y las decisiones que permanecen abiertas. El trabajo del revisor humano no es aprobar esto como cortesía. Es leerlo de forma adversarial: ¿qué está mal aquí? ¿Qué falta? ¿Qué ha cambiado?

Si una persona lee ese resumen y no tiene nada que corregir, yo lo tomaría como una señal amarilla, no verde. Puede que el agente haya capturado de verdad una fase bien estructurada. O puede que el revisor lo haya leído por encima. He aprendido a asumir lo segundo hasta que tenga motivos para pensar lo contrario.

El problema del drift

Nadie habla del drift como modo de fallo, probablemente porque no se anuncia. Desde dentro, simplemente parece que el proyecto avanza.

El drift es la divergencia gradual entre el modelo de trabajo de la IA y la intención real del equipo. Es diferente de un error puntual, que es visible y corregible. El drift es acumulativo: pequeñas desalineaciones que se acumulan a través de las fases hasta que la brecha entre "lo que estamos construyendo" y "lo que dijimos que construiríamos" se vuelve significativa.

Se manifiesta como drift de encuadre (la declaración del problema cambia sutilmente), drift de persona (el usuario objetivo se aleja de la investigación), o drift de prioridades (las compensaciones resueltas antes se vuelven a ponderar silenciosamente). Cuando es visible, varias fases de trabajo pueden estar construidas sobre una base incorrecta.

Las defensas contra el drift son estructurales: un documento de contexto del proyecto actualizado y revisado en cada transición de fase; la intención original leída literalmente en cada gate de fase, desde un documento no desde la memoria; y bloques de confirmación que sacan a la superficie el encuadre actual del problema del agente para comparación humana.

La defensa más importante es cultural: un entorno de equipo donde cuestionar el encuadre de la IA es esperado y recompensado, no tratado como fricción.

El contexto como disciplina de diseño

Trabajar con modelos de lenguaje en un flujo de trabajo multifase significa aceptar una restricción real: los agentes no tienen memoria de la manera en que los miembros humanos del equipo sí la tienen. Cada uno opera dentro de una ventana de contexto: un espacio limitado de información que puede procesar activamente. Cuando esa ventana se llena, el contexto se resume, comprime o pierde.

Así se comporta la tecnología, no es un fallo que se pueda eliminar a base de ingeniería, y diseñar alrededor de eso resultó ser una habilidad en sí misma. El framework lo gestiona con cuatro mecanismos:

• Inicialización del contexto: un documento de proyecto vivo mantenido a través de todas las fases, reinyectado al inicio de cada fase
• Resumen incremental: compresión estructurada de los outputs de fase que preserva las decisiones y las preguntas abiertas
• Inyección selectiva: paquetes de contexto específicos por tarea que dan a cada agente solo lo que necesita para su alcance
• Auditoría de contexto: revisión liderada por humanos de la precisión del contexto en cada límite de fase

La habilidad de la arquitectura de contexto, saber qué información debe llevarse hacia adelante, cómo comprimirla sin perder señal, cuándo el contexto ha derivado de la realidad, es una de las habilidades más subestimadas en el trabajo de diseño aumentado por IA. También es una de las más enseñables.

Integrar la IA en un flujo de trabajo de diseño no facilita el trabajo del facilitador. Es un trabajo distinto.

El cambio más visible: el facilitador ya no es el procesador principal de información del grupo. La IA gestiona gran parte de la transcripción, el etiquetado y la síntesis preliminar. Esto libera atención, pero también crea nuevas demandas. El facilitador ahora debe monitorizar no solo la sala sino el sistema, rastreando lo que la IA está haciendo con el input del grupo y preparando a los participantes para interactuar críticamente con esos outputs en lugar de pasivamente.

Hay un riesgo específico aquí. Cuando la IA resume un taller de dos horas en un conjunto de clusters de insights bien definidos, los participantes tienden a aceptar ese resumen como autoritativo, porque parece organizado y confiado. El facilitador debe resistir esto activamente: incitando al grupo a interrogar la síntesis, identificar qué se perdió en la compresión y sacar a la superficie los desacuerdos que el sistema puede haber suavizado.

El facilitador debe monitorizar no solo la sala sino el sistema. Y cuando los dos se contradicen, la sala gana.

Lo que no cambia

• Mantener el propósito: la IA puede rastrear temas pero no puede mantener la intención. El facilitador es el propietario de por qué se realiza la sesión.
• Leer la sala: ningún modelo puede sentir cuándo un equipo está perdiendo confianza en el proceso, cuándo una voz está siendo sistemáticamente diferida, o cuándo el grupo está a punto de comprometerse con algo que realmente no entiende.
• Juicios de valor: cuando la síntesis de la IA contradice la lectura del facilitador de la sala, el juicio del facilitador tiene precedencia. Siempre.

La norma que vale la pena proteger

La condición más importante para la facilitación aumentada por IA es una que no puede diseñarse en el sistema: la normalización del escepticismo hacia el output de la IA.

En los equipos que hacen esto bien, cuestionar el output del sistema no se lee como desconfianza ni como perder el tiempo; se lee como alguien haciendo bien su trabajo. "No creo que esto recoja lo que realmente dijimos" vale mucho más que el silencio educado que suele recibir.

Construir esta norma requiere liderazgo explícito. El facilitador debe modelar el escepticismo: haciendo preguntas críticas sobre la síntesis de la IA frente al grupo, elogiando los desafíos y dejando claro que la IA es un colaborador con un rol definido y acotado, no una fuente de verdad.

La integración de IA no simplifica el rol del diseñador. Lo cambia.

Se dedica menos tiempo a la producción en sí: primeros borradores, síntesis estructurada, aplicar un patrón repetitivo una y otra vez; casi todo eso ha pasado a los agentes. Se dedica más tiempo a marcar dirección, evaluar lo que vuelve, e integrar entre fases, sobre todo en los juicios donde la necesidad del usuario, las restricciones del negocio y la calidad del diseño no encajan de forma limpia. La responsabilidad sobre el resultado no se ha movido ni un centímetro.

La asistencia de IA no transfiere la responsabilidad. Cambia la forma del trabajo necesario para cumplirla.

Las habilidades con las que la educación en diseño aún no ha llegado

• Craft del prompt: establecer la dirección para un agente con suficiente especificidad para guiar un output útil y suficiente apertura para permitir una contribución genuina. Esto se parece más a la escritura de briefs que a la especificación. La habilidad no está en escribir un prompt más largo y detallado. Está en escribir uno preciso.
• Evaluación del output: evaluar el output de IA crítica y rápidamente: qué es correcto, qué es incorrecto, qué necesita investigación. Esto requiere tanto conocimiento del dominio como un modelo mental claro de lo que el trabajo debe lograr.
• Arquitectura de contexto: decidir qué información debe llevarse adelante a través de las fases, cómo debe comprimirse y qué puede dejarse atrás de forma segura. Un nuevo tipo de diseño de información que los diseñadores senior están bien posicionados para desarrollar.
• Detección de drift: notar cuándo el encuadre de la IA ha cambiado sutilmente de la intención original. Esto requiere mantener la intención original visible y referirse a ella regularmente, desde un documento, no desde la memoria.
• Confianza calibrada: saber cuándo el output de la IA es probablemente fiable y cuándo requiere un escrutinio más profundo. La calibración se desarrolla con la práctica y debe hacerse explícita en todo el equipo.

El framework como práctica viva

Un framework tratado como terminado deja de mejorar. La fase de retrospectiva está específicamente diseñada para evitar esto: al final de cada ciclo, el equipo revisa no solo el trabajo de diseño sino el propio framework. Qué funcionó. Qué generó carga sin valor. Qué necesita cambiar.

Las prácticas descritas aquí son el resultado de una experimentación real: lo que ha funcionado, lo que ha fallado y lo que se ha aprendido. Representan un estado actual, no uno final. Cada equipo que adopte este framework encontrará situaciones que no aborda completamente. La respuesta correcta es adaptar y documentar, no seguirlo mecánicamente.