Diseñar la capa de IA, no solo usarla.
La mayoría de los equipos añaden herramientas de IA a un proceso existente. Este proyecto, una iniciativa exploratoria interna dentro del equipo de diseño de experiencia digital de IKEA, planteó una pregunta diferente: ¿cómo se ve arquitectar la IA en un flujo de trabajo de diseño desde cero, con checkpoints explícitos, roles de agentes definidos y una capa de decisión humana que controle realmente el resultado?
La pregunta equivocada estaba en todas partes
La pregunta dominante en los equipos de diseño que exploraban la IA era "¿qué herramienta deberíamos usar?". La respuesta casi siempre era una recomendación de producto: un asistente específico, un plugin específico, una integración específica. Los equipos lo adoptaban, lo usaban unas semanas y descubrían que los resultados eran inconsistentes, el proceso era más oscuro que antes y nadie podía explicar por qué un output era bueno o malo.
La herramienta casi nunca era el problema real. La IA había caído en un proceso que nunca se había construido para sostenerla: sin fases definidas, sin roles de agente, sin checkpoints, sin ningún plan sobre qué contexto debía pasar de una etapa a otra. Así, el trabajo asistido por IA no falla de forma ruidosa. Se aleja de la intención original mientras sigue pareciendo correcto, y eso es peor, porque nadie lo detecta a tiempo.
Trata la IA como una pieza más del sistema
Lo que realmente hizo posible este proyecto fue negarme a tratar la IA como algo especial. Le di el mismo trato que a cualquier otro problema de sistemas de diseño: entradas, salidas, traspasos, y quién decide qué en cada paso.
Dejé de preguntarme qué podía hacer la IA y empecé a preguntarme dónde encajaba de verdad en el proceso y cómo sabría si estaba funcionando bien. Pregunta más difícil, respuesta más útil, y es justo el tipo de pregunta donde un pensador de sistemas tiene ventaja, porque exige entender el conjunto antes de tocar cualquier pieza suelta.
Tres niveles. Cinco fases. Puertas humanas en cada etapa.
El framework organiza el trabajo de diseño asistido por IA en una jerarquía de agentes de tres niveles que opera a través de cinco fases definidas. Cada nivel tiene un alcance explícito, entradas y salidas definidas, y rutas de escalado claras hacia los responsables de decisiones humanos.
Dos líneas de trabajo, la misma estructura
El framework no se construyó en abstracto. Emergió de dos líneas de trabajo paralelas dentro de un equipo de diseño empresarial, ambas expusieron el mismo problema subyacente: la IA sin proceso produce trabajo que nadie puede asumir como propio.
Facilitación con Shape Up
Las sesiones de shaping de Shape Up son cognitivamente intensivas: múltiples stakeholders, alcance ambiguo, restricciones en competencia. Diseñé flujos de facilitación que usan la IA para apoyar el proceso de shaping: estructurar el problema antes de que comience la sesión, identificar casos límite antes de escribir los pitches, y sintetizar los outputs de múltiples participantes en documentación lista para presentar. La IA gestiona la estructura; el facilitador gestiona el juicio.
Orquestación multi-agente para funcionalidades complejas
Para funcionalidades que involucran simultáneamente a producto, ingeniería, contenido y negocio, un enfoque de agente único produce outputs genéricos que no satisfacen a nadie. El enfoque multi-agente distribuye la tarea de shaping: un agente descompone el problema, otro mapea las restricciones, otro evalúa las direcciones de solución. Los outputs están estructurados para fluir hacia los formatos de documentación existentes, de modo que la capa de IA y la capa de proceso son el mismo sistema.
Este modo de trabajar exige más al diseñador, no menos
Casi todo el mundo asume que un flujo de trabajo asistido por IA facilita el día a día del diseñador. En la práctica, el trabajo simplemente se mueve: menos tiempo produciendo, más tiempo dirigiendo, revisando y encajando piezas. Nada de eso se enseña en una carrera de diseño, así que el framework lo incorpora de forma explícita. Cinco hábitos cargan con la mayor parte del peso: leer un prompt como quien escribe un brief y no una especificación, juzgar rápido el output de la IA sin perder rigor, decidir qué contexto sobrevive de una fase a otra, notar cuándo un agente se ha desviado de la intención original sin que nadie lo avisara, y saber qué outputs necesitan solo un vistazo frente a los que necesitan una revisión completa.
Los design leads y los pensadores de sistemas suelen coger esto rápido, sobre todo porque ya leen el proceso de la misma manera; solo tienen que apuntar ese hábito hacia un tipo de colaborador nuevo.
Un framework que separa el proceso de las herramientas
El resultado más duradero de este trabajo es una arquitectura de proceso independiente de cualquier herramienta o plataforma de IA específica. Como el framework define fases, roles de agentes, checkpoints y protocolos de gestión de contexto a nivel de proceso, no de implementación, sobrevive a migraciones de herramientas, cambios de plataforma y rotación de equipos.
Esa separación también lo hace enseñable. El framework se está compartiendo ahora a través de un programa activo de formación en IA para profesionales del diseño senior, con foco en el diseño de flujos de trabajo y no en el uso de herramientas. El público objetivo son diseñadores y design leads que ya piensan en sistemas y están preparados para aplicar ese pensamiento a cómo encaja la IA en el proceso, no solo a qué puede hacer la IA.
El framework en sí está escrito por separado, con más detalle del que cabe aquí, para que cualquier otro equipo pueda cogerlo y adaptarlo en vez de partir de cero. Está construido a partir de los fallos reales que encontré en este proyecto, no de una versión teórica de ellos.
Leer el framework completo (18 min) →
Tu problema más difícil
es un buen punto de partida.
Abierto a roles de product design senior y proyectos de consultoría selectivos, en inglés o español.