Cómo usar la IA generativa para revelar los supuestos ocultos en un PRD — antes de invertir dos sprints diseñando algo que el stakeholder no había pedido.
El filósofo Michael Polanyi lo formuló con una frase incómoda: “sabemos más de lo que podemos decir”. En cada PRD que llega a un equipo de diseño hay dos documentos superpuestos: el que está escrito — con sus features, sus criterios de aceptación y sus mockups de referencia — y otro que nadie redactó, hecho de supuestos estéticos, expectativas de ritmo, referencias culturales y modelos mentales que el stakeholder no formalizó porque los da por obvios.
Ese segundo documento es conocimiento tácito. Y por su naturaleza, es esquivo: cuando el PM escribe “que se sienta moderno”, “algo tipo Linear pero para nuestro caso” o “limpio, sin fricciones”, cada palabra carga un modelo interno que ni él mismo puede describir con precisión. Solo se hace visible cuando reacciona a algo concreto — un mockup, una referencia, una versión equivocada — con un “no, así no me lo imaginaba”.
Ese momento, esa corrección viva, es lo que separa un diseño que cierra a la primera de uno que rebota tres veces. La IA generativa promete llegar a él más rápido — no diseñando el producto final, sino generando el estímulo que lo hace aflorar en el kickoff. Pero la promesa tiene dos caras — una ayuda y una trampa — y confundirlas es lo que convierte una alineación en una alucinación bien maquetada.
Sabemos más de lo que podemos decir.— Michael Polanyi · The Tacit Dimension · 1966
Traduce las palabras del brief en imágenes concretas en minutos. Funciona como boundary object entre diseño y producto: fuerza al stakeholder a confrontar lo que realmente quiso decir con “moderno”, y a decirlo antes de que empieces a diseñar.
Escupe pantallas tan acabadas que producen una ilusión de acuerdo. El PM aprueba lo que ve porque parece profesional; nadie discute los supuestos que lleva adentro. Dos sprints después aparece el “no era esto lo que pedí”.
Llegar al kickoff con 3 lecturas visuales opuestas del brief, no con una interpretación pulida.
Co-construir el prompt en vivo con el PM, usando las palabras textuales del brief para materializarlas.
Mostrar los supuestos, las variantes descartadas y las decisiones abiertas — no solo la propuesta final.
Nunca llegues a la reunión con una interpretación pulida del brief — es la forma más rápida de comprometerte a supuestos que no discutiste. Llega con tres lecturas visuales opuestas del mismo PRD: una literal, una que fuerce el brief al extremo, una que probablemente esté equivocada. La incomodidad de elegir revela lo que el PM no había verbalizado.
Antes del kickoff, genera tres direcciones deliberadamente distintas a partir de la frase más ambigua del brief. Preséntalas juntas, sin recomendar cuál prefieres. La discusión de por qué la #2 “no es”, es el brief real.
#rol
Eres product designer senior y director de arte con experiencia en kickoffs de producto B2B. Tu trabajo aquí no es diseñar la solución: es provocar la conversación que falta.
#entradas
— Producto y usuario: [qué es y para quién]
— Línea ambigua del PRD, textual: “[frase del brief]”
— Restricciones: [plataforma · marca · design system · plazo]
— Referencias que mencionó el stakeholder: [o “ninguna”]
#proceso
1. Identifica las 2–3 palabras de la línea que cargan más interpretación.
2. Construye tres lecturas que no se puedan mezclar:
A · Literal — lo que entendería alguien ajeno al equipo.
B · Extrema — la frase llevada al límite de lo razonable.
C · Contraria — plausible, pero probablemente equivocada.
3. Verifica que cada lectura cambie al menos una decisión estructural (jerarquía, densidad o flujo), no solo el estilo.
#salida
Para cada lectura, en este orden:
— Supuesto que asume, en una frase
— Spec visual: layout · tipografía · color · densidad · movimiento
— Referencia real comparable (producto y pantalla)
— Prompt de imagen en inglés para [Midjourney / Figma Make]
— La pregunta que obliga al PM a responder
Cierra con una tabla A · B · C × jerarquía, densidad, tono y riesgo.
#reglas
No recomiendes ninguna. No pulas detalles.
Lo que no esté en las entradas, márcalo como [supuesto].
Si dos lecturas se parecen, reescribe la más débil.
La dupla que importa no es Designer↔Usuario — es Designer ↔ PM/Product Owner. Co-construye el prompt en vivo con las palabras textuales del brief. El prompt deja de ser una consulta privada y se vuelve un artefacto de alineación: ver la máquina traducir “ágil” obliga al PM a decir qué quiso decir con “ágil”.
Comparte pantalla en el kickoff. Escribe el prompt con el PM al lado, usando su vocabulario sin traducirlo. Observa qué corrige del output y qué defiende — ahí están los supuestos que no estaban en el PRD.
#rol
Eres facilitador neutral en una sesión en vivo entre diseño y producto. Tu objetivo es que el PM descubra qué quiso decir, no decidirlo por él.
#entradas
— Frase exacta del PM: “[frase textual]”
— Pantalla o flujo: [nombre]
— Usuario y contexto de uso: [2–3 datos]
— Referencia citada: [p. ej. “tipo Linear” o “ninguna”]
#proceso
1. Desarma la frase: cada palabra con carga recibe dos significados que lleven a interfaces distintas.
2. Toma el significado más literal de cada palabra y describe la pantalla que resulta.
3. Si hay referencia, sepárala en atributos (velocidad, densidad, atajos, tono visual) y decide cuáles aplican aquí.
4. Detecta contradicciones entre palabras (p. ej. “simple” y “potente”).
#salida
— Tabla: palabra · significado A · significado B · elemento de UI que lo encarna
— Descripción de la pantalla, máx. 120 palabras
— Tabla de la referencia: atributo · lo tomo / lo descarto · por qué
— Contradicciones detectadas
— 3 preguntas de sí o no para cerrar la ambigüedad
#reglas
Usa el vocabulario del PM tal cual; no lo traduzcas a jerga de producto.
No resuelvas la ambigüedad por tu cuenta: exponla.
Cuando un PM ve solo la propuesta final, la juzga como producto terminado. Cuando ve el mapa de supuestos, las variantes descartadas y las decisiones abiertas, la juzga como trabajo en curso compartido. Ese cambio de estado — de entrega a colaboración — es lo que evita el clásico rebote de review.
No presentes solo pantallas. Presenta primero los supuestos que estás asumiendo del brief, después las variantes descartadas con su razón, y solo al final la propuesta. Da espacio a la reflection-in-action de Schön: pensar con el stakeholder, no para él.
#rol
Eres design lead y preparas la revisión de una propuesta con producto. Tu trabajo es que nadie apruebe algo que no entendió.
#entradas
— PRD: [pega el PRD o sus secciones clave]
— Propuesta actual: [descripción, captura o link]
— Métrica de éxito: [o “no definida”]
#proceso
1. Extrae cada decisión que la propuesta toma y el PRD no pide de forma explícita.
2. Clasifícalas por riesgo: costo de equivocarse × probabilidad.
3. Para las de riesgo alto, diseña una validación que tome menos de un día.
#salida
1. Mapa de supuestos (5–7) en tabla: supuesto · fuente (cita del PRD o “no está en el PRD”) · riesgo · validación en menos de un día
2. Decisiones abiertas en tabla: decisión · opción A · opción B · qué se gana y qué se pierde · quién decide
3. Variantes descartadas: una línea cada una, con su razón
4. Propuesta acotada: qué se mantiene y qué cambia si se validan los supuestos de riesgo alto
#reglas
Ordena por riesgo. Si un supuesto contradice el PRD, va primero y marcado con ⚠.
Nada de lenguaje de venta: esto es para decidir, no para convencer.
Esta matriz no es una checklist para cumplir — es un diagnóstico. Cada fila enfrenta dos versiones de la misma decisión en un punto concreto del ciclo del brief: una donde la IA sustituye la conversación con producto, y otra donde la cataliza. La diferencia es de intención, no de herramienta.
| Momento del PRD | Atajo — IA como oráculo | Práctica — IA como catalizador |
|---|---|---|
| Lectura inicial del brief | No hacer Empezar a diseñar apenas terminas de leer el PRD, confiando en tu propia interpretación de las palabras ambiguas. |
Hacer Generar 3 lecturas visuales opuestas del brief antes de la primera reunión, y llegar con estímulos para calibrar con el PM. |
| Kickoff con stakeholders | No hacer Mostrar tu propia interpretación pulida y preguntar “¿te gusta?”. La aprobación educada es enemiga del acuerdo real. |
Hacer Compartir pantalla, co-construir el prompt en vivo con las palabras textuales del PM, y trabajar sobre lo que él corrige. |
| Presentación & handoff | No hacer Presentar solo la solución final, escondiendo las variantes descartadas y los supuestos que quedaron sin discutir. |
Hacer Mostrar el mapa de supuestos, las variantes intermedias descartadas con su razón, y las decisiones que quedan abiertas. |