Diseñar
con IA

La mayoría de equipos trata la IA como una funcionalidad — algo que se añade a un flujo de trabajo existente. El plugin de Figma que genera variantes de texto. La pestaña de ChatGPT que resume notas de investigación. El asistente que escribe el primer borrador. No hay nada malo en ninguno de estos usos. Pero comparten una limitación común: heredan los problemas estructurales que ya existen en el flujo de trabajo.

Si el proceso es ad hoc, la IA lo hace más rápido y más ad hoc. Si las decisiones están mal documentadas, la documentación generada por IA será confiadamente incorrecta. Si al equipo le falta comprensión compartida de lo que intenta lograr, la IA optimizará para algo — pero no necesariamente para eso.

Añadir inteligencia a un proceso poco claro produce algo peor que un proceso lento y poco claro. Produce uno rápido y poco claro que parece creíble.

Añadir inteligencia a un proceso poco claro produce algo peor que un proceso lento y poco claro. Produce uno rápido y poco claro que parece creíble.

El reencuadre: trata la IA como tratarías cualquier otro problema de diseño de sistemas. Define los inputs. Define los outputs. Define los traspasos. Define quién decide qué y cuándo. Diseña el flujo de trabajo primero, luego diseña la IA dentro de él.

Esto desplaza la pregunta de "¿qué puede hacer la IA?" a "¿dónde encaja la IA en este proceso y cómo sabemos si está funcionando?" La segunda pregunta es más difícil. También es la que vale la pena hacerse.

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.

"Humano en el loop" se ha convertido en una frase que no significa casi nada. Describe desde un diálogo de confirmación hasta una estructura real de autoridad de decisión. La mayoría de los flujos de trabajo asistidos por IA afirman tener supervisión humana y entregan un sello de aprobación.

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 el humano lee esto y no encuentra nada que corregir, debería estar en alerta. O el agente está capturando con precisión el output de una fase bien estructurada, o el revisor no está leyendo con suficiente atención. Ambas son posibles. Desarrolla el hábito de asumir la segunda.

El problema del drift

El drift es el modo de fallo del que nadie habla, porque no parece un fallo. Parece progreso.

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.

Esto no es un error. Es una característica de la tecnología, y diseñar en torno a ella es una habilidad genuina. El framework lo aborda mediante 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.

Cuando la IA está integrada en un flujo de trabajo de diseño, el trabajo del facilitador no se hace más fácil. Se hace diferente.

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 trabajan bien con IA, cuestionar el output del sistema no es una señal de desconfianza o ineficiencia. Es una señal de buen juicio profesional. "No creo que esto capture lo que realmente dijimos" debería ser una contribución celebrada, no una incómoda.

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.

Lo que disminuye: el tiempo dedicado a cierto trabajo de producción — generación de primeros borradores, síntesis estructurada, aplicación repetitiva de patrones. Esto se desplaza sustancialmente hacia los agentes. Lo que aumenta: el tiempo y la atención requeridos para establecer la dirección, la evaluación crítica, la integración entre fases y los juicios de valor que se sitúan en la intersección de la necesidad del usuario, las restricciones del negocio y la calidad del diseño. Lo que permanece igual: la responsabilidad.

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.