Dónde vive una decisión cuando diseñas con IA

Estás en la sala de juntas, proyectando la última versión del prototipo interactivo que armaste con inteligencia artificial. Todo fluye impecable hasta que el director comercial detiene la presentación, apunta a la pantalla y pregunta por qué el sistema le está ofreciendo un descuento del 15% a las cuentas corporativas medianas.

Tú sabes que el modelo generativo alucinó ese número para que el componente de la interfaz no se viera vacío. Él asume que es una decisión oficial del negocio aprobada por finanzas. En ese preciso instante, te das cuenta de que acabas de delegar la política comercial de la empresa a una máquina predictiva.

Hace poco terminé de liderar un prototipo bastante denso para un cliente. Cuando cerré la última iteración, le pedí a Copilot que generara un playbook del proceso, esperando que destilara los aprendizajes clave. La herramienta analizó la transcripción de 21 reuniones y escarbó en casi dos mil archivos. Su gran conclusión fue escupirme catorce fases genéricas atiborradas de plantillas. Plantillas había de sobra. Aprendizajes reales, ninguno.

La verdad incómoda es que mis aprendizajes estaban repartidos entre un documento de 93 láminas que nadie iba a leer completo, un repositorio desordenado, 24 versiones distintas del prototipo y mi propia cabeza. Como ya escribí antes sobre la arquitectura del contexto, cuando el criterio vive exclusivamente en la memoria del Diseñador, la empresa está perdiendo miles de dólares en retrabajo no facturado.

Así que me senté a comparar lo que definí inicialmente contra lo que la IA realmente construyó. De esa fricción salió una estructura operativa. Un mapa para que el siguiente proyecto no dependa de mi memoria ni de los caprichos del modelo de turno.

El triángulo de la verdad

Antes de escribir una sola línea de instrucción para la IA, tienes que decidir dónde vive cada cosa. Todo lo demás depende de esto. Yo utilizo tres lugares con un único sistema de nomenclatura cruzada:

1. La presentación: Guarda la narrativa y las decisiones de negocio aprobadas. Es el documento diseñado para que lo lea un ser humano.

2. Los registros: Archivos de texto plano (Markdown) en un repositorio que guardan la ingeniería del detalle: evidencia bruta, reglas, estados, datos falsos y los prompts originales. Es lo que lee la herramienta.

3. El prototipo: Guarda exclusivamente el comportamiento.

Cada regla, cada estado y cada decisión de Diseño lleva un identificador estable (R-001, S-04, D-012) que aparece idéntico en los tres lugares. Así, cuando en la versión 17 el corporativo pregunte por qué el botón de cancelar desapareció, la respuesta no es “creo que la IA lo quitó”, sino una referencia exacta a la regla que dictó esa restricción.

Tramo 1: Antes del prompt

Decide qué tiene que decidir la audiencia. Si no puedes resumir el objetivo del entregable en una sola frase con la estructura “al terminar, el comité podrá decidir si...”, tienes un problema grave. En mi caso, tenía una pregunta de experiencia de usuario compitiendo contra una métrica financiera, y la segunda terminó secuestrando el prototipo sin que nadie lo notara. Si tienes dos prioridades, no tienes ninguna.

Etiqueta tu evidencia. Cada hallazgo debe llevar su apellido: confirmado, respaldado, direccional, supuesto o prohibido. La evidencia de contexto (un benchmark, la guía de marca) moldea tu interpretación, pero por sí sola no justifica meter una funcionalidad cara en el producto final. Si un elemento del prototipo no tiene un identificador de evidencia claro, es una alucinación técnica.

Dibuja la barda eléctrica. Define explícitamente cuatro territorios: lo que el prototipo demuestra, lo que podría demostrar si hubiera más tiempo, lo que queda completamente fuera y lo que nunca debe afirmar. Un prototipo generado puede mostrar precios en dólares o disponibilidad de inventario con una convicción absoluta, y la junta directiva es justo el momento en que alguien decide creerle a la interfaz.

Diseña la falla. El momento que mejor demuestra la madurez operativa de un Diseñador no es el happy path, es la excepción. Define un caso de error completo: cuál es el detonante, qué variables cambian, qué datos siguen siendo válidos y qué resolución se le recomienda al usuario. En mi último proyecto, la pantalla de error crítico fue la única pieza que llegó completamente intacta a la versión 24 del prototipo.

Tramo 2: El prompt maestro

No generes el prompt principal hasta que todas las reglas críticas estén aprobadas por los stakeholders o etiquetadas en rojo como supuestos de alto riesgo. Si dejas una decisión abierta, la IA la va a tomar por ti basándose en el promedio estadístico de internet, no en la realidad financiera de tu empresa.

Elige la herramienta por el tipo de problema, no por inercia corporativa. Figma Make, Claude o Lovable resuelven cosas distintas. Si necesitas fidelidad visual impecable, usas una. Si requieres persistencia de datos complejos, te vas por otra. Evalúa el peso de la lógica versus la estética antes de casarte con un modelo. No existe el software definitivo.

Tramo 3: Después de la generación

Construye en capas aisladas. Primero la base estructural, luego el recorrido principal, después los datos inyectados y al final la capa visual. Mantén separadas las reglas del negocio del tema estético. Si mezclas todo en un solo bloque de instrucciones, arreglar el color de un botón terminará rompiendo la lógica del carrito de compras. Documenta cada iteración: qué le pediste a la máquina, qué tocó, qué mejoró y qué destruyó en el proceso.

Audita las mentiras de tu demo. La IA es una mentirosa complaciente. Antes de presentar, necesitas que alguien que no construyó el prototipo lo navegue buscando controles muertos, estados huérfanos y datos que se contradicen. Cada paso de tu guion de presentación debe tener una captura de pantalla estática de respaldo por si el código colapsa en vivo. Todo dato simulado se anuncia en voz alta antes de mostrar la primera pantalla.

Cierra la caja. Un proyecto no termina cuando se aprueba la interfaz. Termina con un registro final de decisiones: qué descubrimos, qué preguntas se quedaron sin responder y cuáles son los supuestos que siguen amenazando la rentabilidad del producto.

Lo que todavía me falta probar

Hay un límite honesto en esta estructura. Hasta ahora, solo la he validado yo mismo haciendo ingeniería inversa de un proyecto que ya estaba cerrado. Y la realidad es que un proceso de Diseño no está verdaderamente probado hasta que alguien que no lo inventó logra seguirlo sin que tú estés en la misma sala.

El siguiente ciclo de validación lo correrá alguien más de mi equipo. Estoy seguro de que en cuanto empiece a iterar, encontraremos fricciones y decisiones que yo asumí como obvias simplemente porque llevaban meses viviendo en mi cabeza.

Mañana a primera hora, abre el último archivo o repositorio que le entregaste a tu equipo de ingeniería. Busca un caso extremo, un mensaje de error o una restricción de datos. Intenta rastrear de dónde salió esa regla y quién la aprobó. Si no logras encontrar el origen documental en menos de cinco minutos, bórrala de inmediato y fuérzate a tomar la decisión en voz alta junto con el negocio.

Felices trazos.