Problema
Una respuesta con botones, formularios y gráficos invita a actuar. El usuario deja de leer una explicación y empieza a manejar lo que parece un producto. Si el control no distingue simulación, cálculo y modificación real, la interfaz puede prometer más de lo que el sistema hace.
Una calculadora puede explorar un escenario sin guardar datos. Un formulario puede recoger una preferencia sin enviarla. Un botón visualmente convincente puede no estar conectado a ninguna operación. El diseño tiene que hacer comprensibles esas diferencias antes de la interacción.
Tesis
La interfaz generada necesita un contrato visible: qué modifica, qué conserva y cómo comunica el resultado. OpenAI presentó Intelligent UI el 7 de octubre de 2026 como respuestas que combinan texto, elementos visuales y controles interactivos. La implicación para producto es diseñar estados y límites, no añadir controles a todas las respuestas.
Las pautas de accesibilidad del W3C y sus patrones de diálogo ofrecen criterios para evaluar interacción y foco. No garantizan la calidad de una interfaz generada; permiten formular comprobaciones concretas.
Framework
Clasifica el efecto del control
Antes de renderizarlo, decide si un elemento sirve para explorar información, calcular un resultado o actuar sobre un sistema. La etiqueta debe expresar ese efecto. «Comparar escenarios» y «Enviar solicitud» requieren expectativas y confirmaciones distintas.
Presenta las hipótesis junto al resultado. Si el cálculo omite impuestos, usa datos inventados o depende de una estimación, esa condición forma parte de la herramienta. Esconderla en una explicación anterior dificulta que el usuario entienda qué está viendo.
Diseña el recorrido completo
Incluye estado inicial, carga, éxito, error y recuperación. Conserva el trabajo del usuario cuando falle una consulta y evita que reintentar duplique una operación. Si la respuesta cambia de estructura, comprueba qué ocurre con el foco y con la información introducida.
Una interfaz generada debe poder explicar su estado sin depender del color o de una animación. También necesita un camino utilizable con teclado. Es preferible una interacción pequeña y comprobable a un panel complejo cuya semántica cambia en cada respuesta.
Decide cuándo sobra la interactividad
Si la pregunta pide un dato o una recomendación breve, el texto puede resolverla mejor. El criterio es si el usuario necesita explorar variaciones o tomar una acción, no si el modelo puede producir un componente vistoso.
Un formulario de cita con estados que se pueden comprobar
Supuesto de producto: el usuario elige un horario y solicita una reserva. La disponibilidad mostrada es una consulta; la reserva depende de una escritura posterior. Esta propuesta de estados evita que la interfaz confunda ambas operaciones.
| Estado observable | Texto o acción visible | Evidencia necesaria para avanzar |
|---|---|---|
| Horario consultado | «Solicitar esta cita» | Resultado de disponibilidad vigente |
| Solicitud en curso | «Estamos comprobando la reserva» | Identificador de la operación iniciada |
| Respuesta perdida | «Estamos comprobando si se ha reservado» | Consulta del estado de esa misma operación |
| Reserva confirmada | «Cita reservada» y referencia | Confirmación del sistema de reservas |
| Reserva rechazada | Motivo y alternativa | Rechazo explícito, sin cita creada |
Si el usuario cambia de horario durante la espera, conserva la relación con la operación original. Una respuesta tardía no debe confirmar visualmente el horario nuevo. Y un timeout no basta para habilitar un segundo intento de escritura: puede haberse perdido la respuesta después de crear la cita.
La prueba de aceptación debe simular esa respuesta perdida. El usuario ve un estado pendiente, la aplicación consulta el destino y termina mostrando la referencia ya existente. Si no hay un mecanismo para consultar o deduplicar la operación, diseña una recuperación asistida en lugar de presentar un botón que repite el compromiso a ciegas.
Para teclado, el estado de carga debe conservar un recorrido comprensible; la confirmación se comunica como resultado de la tarea. Los textos son ejemplos de diseño, no garantías atribuidas a Intelligent UI. La integración que recibe la escritura sigue siendo quien debe confirmar el efecto.
Por qué importa ahora
Cuando la respuesta adopta forma de herramienta, los defectos de diseño pasan a formar parte de la calidad de la IA. Un resultado correcto presentado con un control ambiguo puede llevar a una decisión incorrecta. Por eso la evaluación debe observar la interacción, además de leer el contenido.
Anti-ejemplo
Caso hipotético: un asistente muestra un presupuesto con un botón «Confirmar». El usuario lo pulsa y cree que ha contratado el servicio. El componente solo guardaba una selección en la conversación. La interfaz ha creado una obligación aparente que la integración nunca ejecutó.
Protocolo (3 pasos)
| Paso | Decisión | Comprobación |
|---|---|---|
| Definir | Qué efecto tiene cada control | Etiqueta y resultado coinciden |
| Recorrer | Estados de éxito, error y reintento | El usuario puede recuperarse |
| Observar | Uso con teclado y lectura del estado | La interfaz comunica lo ocurrido |
Relacionado
- Figma o prototipo generado: empieza por la incertidumbre
- Output Verification Layer: el seguro invisible de los agentes en producción
Fuentes consultadas
- OpenAI — GPT-6 and Intelligent UI for everyone
- W3C — Web Content Accessibility Guidelines
- W3C — Patrón de diálogo modal
Próximo paso
Elige una respuesta interactiva de tu producto y pide a una persona que explique qué cree que hará cada botón antes de pulsarlo. Las diferencias con el comportamiento real son trabajo de diseño prioritario.