Te piden un prototipo. ¿Para qué?

La semana pasada te conté del paper que publiqué sobre Arquitectura de Contexto. Desde entonces me ronda una pregunta. El marco dice cómo ordenar el contexto con el que trabajamos con IA, pero no dice hacia dónde se está moviendo el trabajo de Diseño. Para eso necesito evidencia, y la más honesta que tengo es lo que los clientes piden.

Lo pienso como un vector. Para quien dejó las matemáticas en la prepa: un vector es una flecha, con un punto de origen y una dirección. El origen es la demanda, es decir, lo que llega en los encargos, lo que piden las vacantes y lo que exigen los documentos de compra. La dirección la pone mi marco. Lo que quiero es empezar a dibujar hacia dónde apunta la flecha.

Esta pieza es el primer trazo, y es una hipótesis. Son tendencias vistas desde el estudio de Diseño que dirijo y desde vacantes públicas, no un estudio formal.

El origen: qué está pidiendo la gente

Hay cuatro cosas que se repiten.

1. La IA dejó de ser tema y se volvió requisito. Hace un año aparecía de vez en cuando en un encargo; hoy viene escrita en muchos. Además llega en tres sabores que conviene no mezclar. Uno es diseñar productos con IA, donde importan la confianza, los errores y cuándo pasarle el caso a una persona. Otro es usar IA para hacer el trabajo de Diseño. El tercero es habilitar a un cliente o a un equipo para que trabaje con IA. Cada uno pide evidencia distinta.

2. Las vacantes piden prototipar. Comparé las mismas empresas en 2024 y en 2026, y cada vez más posiciones piden prototipar, diseñar usando IA y llevar el Diseño a código.

3. Los clientes piden que funcione. El prototipo aparece una y otra vez en los documentos de compra. Junto con él aparece algo que me parece más revelador: reglas sobre cómo usa la IA el proveedor. Qué herramientas, con qué datos, cómo se declara y quién revisa.

4. Y el trabajo viene pegado a sistemas. Cuando hay IA de por medio, el encargo arrastra con más frecuencia el sistema de Diseño, la colaboración con ingeniería y el paso a código.

Mi lectura, y aquí es lectura mía, es que muchos clientes están pidiendo menos el artefacto y más el resultado funcionando. Quieren ver la cosa comportándose como debe, además de verse terminada.

El hueco: piden el prototipo, no la pregunta

Esto es lo que más me llama la atención. El encargo dice “queremos un prototipo” y casi nunca dice para qué. Y hay por lo menos cinco profundidades de prototipo, cada una con su pregunta:

• Conceptual. ¿La propuesta tiene sentido? Expone el valor, los actores y las dependencias.

• Navegable. ¿La gente entiende y recorre la secuencia? Expone la jerarquía, las etiquetas y la navegación.

• Realista en sistema. ¿La experiencia aguanta en su contexto real? Expone componentes, contenido, estados y datos representativos.

• Funcional. ¿La interacción se comporta como debe? Expone entradas, lógica, errores y recuperación.

• Conectado a producción. ¿El Diseño se integra con la implementación? Expone código, servicios y componentes.

Ninguna es mejor que otra, y no hay que subirlas de una en una como escalera: se escoge por la pregunta. Cuando nadie dice cuál es la pregunta, el equipo escoge por default, casi siempre la más vistosa. Así terminas pagando un prototipo funcional para contestar algo que un concepto resolvía en dos días. O al revés: entregas un navegable precioso que no dice nada de cómo se porta el sistema cuando falla.

Si el para qué no viene en el encargo, alguien lo tiene que producir. Mi hipótesis es que, cada vez más, ese alguien es el Diseñador. En el paper le llamo Decisión: es el primer componente del paquete de contexto y la primera etapa del método. Las reglas que pone el cliente sobre la IA también tienen lugar ahí. Son Criterio y límites: lo que la IA tiene prohibido hacer o afirmar en ese proyecto.

Eso cambia cómo arranca el trabajo. Antes de abrir cualquier herramienta, propongo seis preguntas para aclarar un encargo con IA:

1. ¿Qué comportamiento o resultado tiene que entregar el Diseño?

2. ¿Es diseñar un producto con IA, usar IA para hacer el trabajo, habilitar a un equipo, o una mezcla?

3. ¿Qué tiene que funcionar, además de verse terminado?

4. ¿Cuánto involucramiento hay con el sistema, el código o la implementación?

5. ¿Qué reglas pone el cliente sobre datos, herramientas, declaración y aprobación humana?

6. ¿Qué evidencia va a demostrar que la calidad es aceptable?

Si el encargo no las contesta, contestarlas con el cliente ya es trabajo de Diseño. Probablemente es el más valioso de la primera semana.

Hacia dónde apunta la flecha

Con el origen y la dirección, el primer trazo apunta a tres cosas. Las tres son hipótesis.

El esfuerzo experto se mueve a escoger y criticar. Cuando generar alternativas cuesta poco, el trabajo difícil es compararlas contra criterios compartidos y dejar registro de por qué una dirección sobrevive y otra no. Producir sigue siendo necesario, pero deja de ser donde se gana la discusión.

Los portafolios van a tener que enseñar otra cosa. Las decisiones, las alternativas descartadas, las revisiones, qué hizo la IA y qué rechazó el Diseñador. En el paper lo dejé como conjetura, y en lo que piden las vacantes ya se empieza a asomar.

Y queda una pregunta incómoda sobre la gente que va empezando. Si producir pantallas repetibles ya no alcanza para aprender el oficio, alguien tiene que diseñar a propósito cómo aprenden los juniors: síntesis de research supervisada, diseño de estados y evaluación con retroalimentación. Ese trabajo hoy casi nadie lo tiene asignado.

Es un trazo, todavía no un mapa. Está visto desde un estudio y desde una muestra de vacantes, y lo voy a ir corrigiendo con lo que encuentre en las siguientes piezas.

Mientras tanto, llévate las seis preguntas a tu próximo encargo. Y piensa en el último prototipo que te pidieron: ¿alguien te dijo qué tenía que contestar? Si nadie lo hizo, ahí está el trabajo que nadie te encargó, y que probablemente es el que más importa.