El Prototipo Empieza Mucho Antes de Escribir un Prompt

Abrir una ventana de chat y pedirle a una inteligencia artificial que escupa un sitio web en tres minutos te convierte en un simple espectador de tus propias omisiones. La facilidad con la que hoy podemos generar pantallas funcionales genera la falsa ilusión de que hemos resuelto un problema comercial, cuando en realidad solo hemos automatizado nuestras suposiciones.

Llevo dos días enteros sin tocar una sola de las herramientas que el mercado asocia con el desarrollo de interfaces generativas. Nada de Claude, nada de v0, nada de plataformas que prometen renderizar tu producto con un enter. En su lugar, tengo abierto un documento crudo que ya roza las noventa páginas. Lo sigo actualizando, reestructurando y cuestionando cada pocas horas. Cada vez que lo reviso, encuentro una restricción que faltaba o un flujo que estaba mal planteado.

El encargo original de un corporativo regional con el que estoy colaborando era engañosamente simple: construir un prototipo funcional para llevar a una junta directiva y demostrar viabilidad técnica. La urgencia siempre empuja hacia el mismo lado. La tentación natural, la que yo mismo sentí antes de pensarlo dos veces, es ceder al teatro corporativo de las entregas rápidas, abrir el modelo de turno y pedirle algo genérico. Y sí, funciona. Sale algo en minutos.

Y ese algo, con casi total seguridad, va a ser un desastre operativo encubierto de pixeles bonitos.

Estará mal de una manera muy particular. Tal vez resuelva el problema equivocado con una interfaz impecable. O peor aún, inventará una regla de negocio que suena sumamente razonable pero que nadie en la organización validó jamás. Corregir una alucinación algorítmica cuando ya hay pantallas generadas y los directores ya se hicieron una idea mental del producto, te cuesta miles de USD en desarrollo inútil y horas de equipo tiradas a la basura. Modificar un documento de texto cuesta centavos.

El Diseño ocurre antes del lienzo

En lugar de caer en el juego de la inmediatez, empecé a documentar. Fui metiendo los objetivos comerciales, los requerimientos legales que el cliente mandó a medias, un benchmark completo de la competencia local, evidencia del comportamiento de compra y los principios de Diseño que vamos a defender a capa y espada. Todo eso mucho antes de escribir una sola instrucción generativa.

Y aquí está lo que se sentía extraño al principio pero que ahora resulta evidente: llevo dos días haciendo trabajo de Diseño puro y duro, aunque no he abierto un solo programa de diseño visual. Estructurar el contexto crudo del negocio es la nueva infraestructura operativa. Es el mismo criterio analítico que usas al defender una jerarquía visual frente a un stakeholder, aplicado ahora a decidir qué necesita saber una máquina antes de que se le pueda confiar el ensamblaje visual.

Es exactamente igual a preparar los ingredientes en la cocina antes de siquiera pensar en encender la estufa. Si te pones a picar la cebolla mientras el aceite ya está humeando, vas a quemar la cena. La preparación de los insumos es, en sí misma, el acto de cocinar.

En las mentorías que doy a Diseñadores mid-senior, la ansiedad toma casi siempre la misma forma. Me preguntan para qué les van a pagar una iguala si el gerente de marketing ya puede generar la interfaz en segundos. La respuesta pasa por el criterio técnico, y esta misma semana me tocó verla materializada. Si no sabes leer un mercado, cruzar la evidencia contra los patrones de interacción y decidir qué se debe simplificar sin romper el modelo de rentabilidad, no tienes manera de darle instrucciones a la máquina. Simplemente no sabes qué preguntas hacerle a la información que tienes enfrente.

La arquitectura de las prohibiciones

Hay una sección de este inmenso documento que me tomó más horas de las presupuestadas, y es la que más claridad me ha dado: decidir explícitamente qué le voy a prohibir inventar a la IA.

Suena a trámite administrativo. “No inventes datos falsos”, dirían los manuales básicos. En la práctica, significa sentarse a mapear con precisión quirúrgica qué sabemos con certeza, qué es una suposición temporal y qué vacíos ignoramos por completo. Esta semana, revisando la lista de las veintidós restricciones que el prompt final va a necesitar, me di cuenta de un patrón recurrente. Tenía anotadas varias reglas sueltas: una política de logística, un horario de servicio al cliente y una limitante de configuración técnica. Después de analizarlas, me di cuenta de que eran la misma categoría repetida bajo distintos nombres: información propietaria que el modelo jamás podría adivinar.

Encontrar esos huecos y unificarlos es hacer arquitectura de información. Solo que ahora no ordenamos botones en un menú, ordenamos las restricciones lógicas sobre las que un sistema va a iterar.

Todavía me falta cerrar el documento y convertir todo ese contexto curado en el prototipo final. Cuando lo haga, seguramente habrá diferencias entre lo planeado y lo generado, y tendré que hacer ajustes. Pero el trabajo fundacional ya está hecho. El valor real de un Diseñador contemporáneo reside en ese esfuerzo invisible, el que no cabe en un caso de estudio tradicional y que jamás se ve en el producto final.

Si estás a punto de meterte a construir algo complejo y sientes la tentación de saltarte la documentación porque crees que “ya casi lo tienes en la cabeza”, detente. Esa misma urgencia es la señal inequívoca de que todavía te falta entender la mitad del problema.

Felices trazos.