UX‑guidelines de OpenAI: cuándo mostrar App y cómo no «apoderarse» del diálogo

1. Chat‑first: ChatGPT es ante todo un chat, y después aplicaciones

En los primeros 6 módulos hemos visto todos los aspectos de la aplicación: desde la UI y MCP hasta el debug y el despliegue. Ahora volveremos a recorrer sus caras, pero más a fondo. No pensarías que todo sería tan sencillo, ¿verdad?

Y empezamos con UX, más concretamente con los UI requirements y UX‑guidelines oficiales. Querrás que tu aplicación pase la review, ¿no es así? Perfecto, entonces empecemos por lo más interesante: el cambio mental clave que necesita un frontender acostumbrado a SPA/Next.js: ChatGPT es, ante todo, una interfaz de diálogo, y la App es una invitada dentro de ese diálogo. No al revés.

OpenAI lo formula así en sus guías: las aplicaciones amplían lo que el usuario puede hacer sin romper el flujo de la conversación. Un widget no es una pestaña nueva del navegador, sino una inserción discreta en el chat que aporta estructura cuando el texto se queda corto.

La forma más sencilla de recordarlo es separando los roles.

Roles de GPT y App

Dentro de ChatGPT hay dos «personajes»:

GPT sigue siendo el narrador principal. Con palabras, explica qué va a ocurrir, por qué propone la App, qué significan los botones, y resume el resultado del widget. La App, por su parte, se centra en la parte visual y las acciones: elegir opciones, ajustar filtros, seguir los pasos de un asistente.

Una regla muy importante, para repetir como un mantra: todas las decisiones importantes deben explicarse explícitamente en la respuesta de texto de GPT, incluso si el usuario hace clic en la UI. El usuario no tiene por qué leer cada línea de la interfaz del widget: las consecuencias clave (por ejemplo, «hemos tramitado el pedido» o «has elegido estos parámetros») deben enunciarse en el chat.

2. Cuándo la App es realmente necesaria: criterios de visualización

Desde el punto de vista técnico puedes invocar un widget en cada mensaje. Pero desde UX, es como abrir un diálogo a pantalla completa por cada carácter que escribes en el input. Funcionar, funciona. Vivir con ello —no.

OpenAI y el Apps SDK proponen un principio simple: App es apropiada cuando pensar con ella resulta más fácil que solo con texto.

Peticiones con estructura y escenario repetible

La App encaja bien cuando la petición del usuario ya sugiere una estructura:

• «Elige 5 ideas de regalo para un colega por menos de $50».
• «Compara estos tres planes de tarifa».
• «Haz un itinerario de 3 días por Tokio».
• «Muestra mi lista de tareas de la semana y ayúdame a priorizar».

En todos estos casos hay entidades claras (regalos, tarifas, días del itinerario, tareas) que hay que manipular, y pasos: elegir, filtrar, comparar, confirmar. Aquí una UI con tarjetas, checkboxes y filtros está justificada e incluso salva la situación.

Ejemplos para GiftGenius

Tomemos a nuestro héroe favorito, GiftGenius. Esta es una petición típica:

Hay que elegir regalos para 10 invitados de una boda, con presupuestos e intereses diferentes.

Con texto puro, GPT podría enumerar 10 listas separadas, pero leerlo dolería. Mucho más agradable:

• mostrar una tabla de invitados, presupuesto e intereses,
• dar la posibilidad de filtrar «más barato/más caro»,
• mostrar un conjunto de tarjetas por cada invitado.

Aquí la App es prácticamente obligatoria: hay demasiadas entidades y parámetros como para manejarlo solo con texto.

A diferencia de esto:

¿Qué regalar a mi hermano con un presupuesto de 5000 ₽?

Es una pregunta pequeña, de un solo paso. GPT puede responder con texto y 3–5 ideas, y solo si el usuario pide «muestra opciones donde pueda filtrar por aficiones y edad», se puede pasar suavemente a la App.

Mini heurística

Es útil tener en mente una tabla simple:

Hablaremos en detalle de inline y fullscreen en próximas lecciones, pero ya se ve: la App es una herramienta para tareas estructuradas y de varios pasos, no para cada «estoy triste, ¿qué hago?».

3. Cuándo la App estorba: modo «charlar» y reflexiones

Ya hemos visto en qué casos la App simplifica la vida y ayuda a la estructura del diálogo. Pero también hay otra cara: hay situaciones en las que cualquier UI solo estorba.

Tanta conversación de «vamos a dibujar una UI» a menudo lleva al reflejo: «oh, el usuario ha preguntado algo —hora de lanzar el widget». Este es el punto donde, en la review del Store, puedes recibir un punto negativo en UX.

Hay toda una clase de peticiones donde la App a menudo perjudica:

1. Usuario en modo «charlar». Son reflexiones filosóficas, preguntas personales, dilemas de carrera, conversaciones de tipo terapéutico. En estos escenarios el usuario espera una charla de texto, preguntas de aclaración e incluso empatía. Insertar tarjetas y filtros se sentirá como un banner de spam.
2. Preguntas introductorias sobre el servicio. Si alguien escribe «¿Qué puede hacer GiftGenius?» —quiere una visión general, no la UI de inmediato. Aquí GPT hará mejor explicando primero brevemente para qué sirve la App, quizá dando ejemplos de peticiones, y solo después proponiendo probar el widget con cuidado.
3. Preguntas teóricas generales. «¿Cómo elegir regalos para introvertidos?» o «¿Cómo funciona el sistema de fidelización en las tiendas?» —es un escenario didáctico, no transaccional. GPT puede dar una buena respuesta textual y, al final, añadir sin insistencia: «Si quieres, puedo abrir GiftGenius y seleccionar algunas opciones concretas».

Siempre que la UI no aporte valor nuevo y solo duplique el texto, es mejor quedarse en el chat. Esto es respetar la intención del usuario, de lo que tanto hablan los gurús de UX.

4. Cómo proponer la App: auto‑launch frente a «cesión humilde»

Incluso si estás seguro de que la App es adecuada, la pregunta «cómo lanzarla» sigue abierta. La opción brusca: el widget se abre inesperadamente a pantalla completa sin aviso. La opción correcta: GPT primero explica con palabras lo que va a pasar, y pide consentimiento o al menos avisa.

En la documentación de UX de las ChatGPT Apps se distinguen dos patrones: auto‑launch y suggestion (humble handoff).

Auto‑launch: cuando el usuario lo pidió explícitamente

El auto‑launch es adecuado cuando el usuario expresa claramente su intención:

Inicia GiftGenius.
Abre los ajustes de GiftGenius.
Muestra mi carrito de regalos en GiftGenius.

Aquí las reglas son sencillas:

1. GPT escribe brevemente algo como «Abro GiftGenius…».
2. El modelo invoca de inmediato la herramienta / el widget.

El diálogo puede verse así:

Usuario: Inicia GiftGenius, quiero elegir un regalo para un amigo.
GPT: Abro el asistente GiftGenius para elegir regalos.
[Aparece el widget GiftGenius inline o a pantalla completa]

El inicio automático sin aclaraciones adicionales está justificado, porque el propio usuario pidió «abrirlo».

Suggestion (humble handoff): cuando la intención no es explícita

En muchos casos el usuario ni siquiera conoce tu aplicación. Escribe:

Necesito pensar en algo para un colega por su cumpleaños, el presupuesto es pequeño.

El patrón correcto es:

1. GPT analiza la petición y entiende que la App puede ayudar.
2. GPT hace 1–2 preguntas de aclaración o propone la App por texto.
3. Solo tras el consentimiento o una señal clara —lanza el widget.

Ejemplo:

Usuario: Necesito pensar en algo para un colega por su cumpleaños, el presupuesto es pequeño.
GPT: Puedo ayudarte con ideas directamente o abrir la aplicación GiftGenius, donde elegiremos opciones por presupuesto e intereses. ¿Prefieres solo consejos o probar la aplicación?
Usuario: Vamos con la aplicación.
GPT: Abro GiftGenius para elegir opciones de regalo.
[Aparece el widget]

Este enfoque destaca que la iniciativa sigue siendo del usuario, y la App es una opción, no un banner impuesto. Encaja bien con el principio «Respect user’s intent» de las guías de UX.

Mini ejemplo de «clasificador de intenciones» en TypeScript

Imagina que en tu backend ya clasificas de forma aproximada la petición del usuario (no confundir con el propio GPT, es lógica auxiliar):

// Tipo simplificado de intenciones del usuario
type UserIntent = 'chat' | 'ask_gift_advice' | 'open_app';

// Qué disparador para la App queremos usar
type AppTrigger = 'auto' | 'suggest' | 'avoid';

function decideAppTrigger(intent: UserIntent): AppTrigger {
  if (intent === 'open_app') return 'auto';      // "inicia GiftGenius"
  if (intent === 'ask_gift_advice') return 'suggest'; // petición no explícita
  return 'avoid';                                // chat normal, sin App
}

Esta lógica por sí sola no lanza el widget: es más bien una forma de formalizar tu enfoque UX. Después trasladas estas reglas al system‑prompt y a las descripciones de la App, para que el modelo se comporte en la misma línea.

5. Cómo no «apoderarse» del diálogo: patrones buenos y malos

En la documentación de OpenAI y en artículos de diseño UX para las ChatGPT Apps se formula con bastante claridad lo que no hay que hacer: no «robar» la conversación. Es decir, no convertir el chat en un canal para promocionar tu interfaz.

Antipatrones

El más doloroso —el «widget sorpresa». Es cuando el usuario está en una conversación profunda y, de repente, toda la pantalla la ocupa una aplicación fullscreen que no pidió. Se pierde el contexto y también la sensación de control.

Otro pecado frecuente es usar la App como publicidad. Por ejemplo, el usuario pregunta algo teórico, y el modelo responde: «Primero abriré nuestro super‑widget, allí está todo explicado» y muestra una UI donde la mitad es texto de marketing. Las guías oficiales llaman a estos escenarios «poor use cases».

El tercer antipatrón son los cambios frecuentes e innecesarios entre UI y texto. Si por cada pequeña aclaración se lanza y se cierra la App, el diálogo recuerda a una guirnalda parpadeante. El usuario, especialmente en móvil, se cansará rápido.

Buenas prácticas

En todos los escenarios donde finalmente abras la App, intenta ceñirte a tres reglas simples.

Primero, avisa. Que GPT diga explícitamente que va a abrir la aplicación y para qué. Por ejemplo: «Ahora abriré el asistente GiftGenius para mostrar opciones en forma de tarjetas». Son 1–2 líneas, pero cambian por completo la sensación del paso.

Segundo, explica qué hacer en la UI. No todos los usuarios están acostumbrados a una interfaz nueva. GPT puede añadir texto: «Abajo verás tarjetas de regalos; puedes paginar y pulsar “Más detalles” en cualquier opción». Si el widget tiene algo poco habitual (por ejemplo, «Mostrar N más» o filtros no estándar), mejor decirlo con palabras.

Tercero, resume el resultado con texto. Después de que la App haga algo (seleccionar, calcular, enviar), GPT debe contar brevemente: «He seleccionado 3 opciones de regalos. Las dos primeras están dentro del presupuesto de hasta $50; la tercera es algo más cara, pero con entrega rápida. ¿Quieres acotar la selección?». Es especialmente importante en dispositivos móviles y escenarios de voz: quizá la persona no mire la UI, pero oirá el resumen textual.

6. El papel del system‑prompt y las descripciones de la App en la gestión del UX

Ya has visto cómo el system‑prompt define la «personalidad» de la App y cómo el modelo usa las herramientas. Ahora añadimos reglas de UX: cuándo proponer la App, cómo anunciarla, cuándo abstenerse.

Qué especificar en el system‑prompt

Para GiftGenius, el system‑prompt puede incluir una sección «Diálogo y UX». En la documentación y artículos se recomienda describirlo de forma estructurada, mediante reglas separadas.

Ejemplo de fragmento (pseudocódigo, pero muy cercano a la realidad):

### Diálogo y UX

1. Si el usuario ofrece condiciones para seleccionar un regalo (para quién, presupuesto, motivo),
   primero haz 1–2 preguntas de aclaración por texto.
2. Tras las aclaraciones, propone abrir la App GiftGenius:
   "Puedo abrir el asistente GiftGenius para mostrar opciones de regalo. ¿Lo abro?"
3. Si el usuario pide explícitamente "inicia GiftGenius" o "muestra la lista de regalos",
   responde "Abro GiftGenius..." e invoca la App de inmediato sin preguntas adicionales.
4. Si el usuario pide teoría o consejos generales (por ejemplo, "cómo elegir regalos"),
   responde con texto y no abras la App hasta que él mismo lo pida.
5. Si el usuario dice "no abras la aplicación" o "responde solo con texto",
   no vuelvas a proponer la App en este diálogo.
6. Después de usar la App, resume siempre el resultado con texto (breve).

Aquí están condensados todos nuestros principios de UX: chat‑first, respeto al rechazo del usuario, diferencia entre auto‑launch y suggest, y resumen textual obligatorio.

Cómo ayudarte con configs de TypeScript

En proyectos reales es cómodo guardar parte de estas reglas de forma estructurada (para no rebuscarlas luego en los prompts). Por ejemplo, puedes crear un config sencillo:

// Tipo hipotético de configuración de disparadores UX de la App
type AppUxRule = {
  intent: 'gift_selection' | 'theory' | 'open_app';
  trigger: 'auto' | 'suggest' | 'avoid';
  askConfirmation?: boolean;
};

export const giftGeniusUxRules: AppUxRule[] = [
  { intent: 'open_app', trigger: 'auto' },
  { intent: 'gift_selection', trigger: 'suggest', askConfirmation: true },
  { intent: 'theory', trigger: 'avoid' },
];

Este config el modelo no lo lee por sí mismo: te sirve a ti, como desarrollador, para reunir en un lugar los acuerdos de producto/diseño y luego trasladarlos con cuidado al system‑prompt, a las descripciones de la App y a la documentación.

7. Ejemplo: cómo GPT anuncia GiftGenius y no se adueña de la conversación

Conectemos todo con nuestra aplicación. Imagina que el usuario escribe por primera vez en el chat:

Busco un regalo para un colega, aproximadamente hasta 3000 ₽; le gustan los juegos de mesa.

Una buena respuesta del modelo (según nuestro system‑prompt) podría ser así:

¡Entendido! Aclaremos un par de detalles y busquemos ideas.

Dime aproximadamente su edad y si es un regalo más bien formal o de un amigo cercano.

(Después de tu respuesta puedo abrir el asistente GiftGenius, donde veremos opciones en forma de tarjetas.)

Tras la aclaración, GPT escribe:

Perfecto, ya tengo información suficiente.

Ahora abriré la aplicación GiftGenius: en ella te mostraré varias opciones de regalo en forma de tarjetas; podrás ver detalles y acotar por presupuesto y tipo de juego.

Y solo entonces —se lanza la App. Ni una «sorpresa», todo explicado con palabras.

Pequeño componente de React de «anuncio de la App» dentro del widget

Desde el punto de vista del código, el widget normalmente se renderiza cuando lo invocan. Pero puedes incorporar en su UI la filosofía de «no adueñarse» del contexto, incluso cuando ya esté abierto.

Por ejemplo, la primera pantalla de GiftGenius puede ser muy simple:

// app/components/GiftGeniusIntro.tsx
export function GiftGeniusIntro() {
  return (
    <section style={{ padding: 16 }}>
      <h2 style={{ fontSize: 20, marginBottom: 8 }}>
        Selección de regalos con GiftGenius
      </h2>
      <p style={{ marginBottom: 12 }}>
        Voy a mostrar varias opciones en forma de tarjetas. Podrás
        elegir las que te gusten y ChatGPT explicará pros y contras.
      </p>
      <p style={{ fontSize: 12, color: '#666' }}>
        En cualquier momento puedes volver al chat normal y continuar la conversación.
      </p>
    </section>
  );
}

Este componente no hace nada «potente» técnicamente, pero desde el punto de vista UX es importante: recuerda que el chat sigue ahí y que el papel de GPT sigue siendo central.

A partir de esta pantalla de introducción pasarás a las tarjetas de regalos, asistentes, etc., pero eso ya es tema para próximas lecciones.

8. Práctica y ejercicios

Arriba hemos reunido un conjunto de principios —chat‑first, respeto a la intención del usuario, diferencia entre auto‑launch y propuesta de App. Para afianzar el enfoque de «cuándo y cómo mostrar la App», es útil pensar en peticiones reales y separar explícitamente dónde la App hace falta y dónde no. Para casa, puedes hacer dos ejercicios pequeños.

Primero, toma GiftGenius e inventa 5–7 peticiones de usuario. Para cada una respóndete con honestidad:

• si aquí conviene proponer abrir la App de inmediato;
• si solo conviene mencionar la App como opción;
• o si es mejor no relacionar la respuesta con la App en absoluto.

Por ejemplo:

1. «Regalo para mi mujer por el aniversario, presupuesto hasta $1000» — probablemente primero un par de preguntas de aclaración por texto, después proponer abrir la App.
2. «¿Cómo envolver un regalo de forma original?» — pregunta puramente teórica, se puede responder sin la App.
3. «Inicia GiftGenius, quiero elegir regalos para todo el equipo» — auto‑launch directo.

El segundo ejercicio —el texto de anuncio del lanzamiento de la App. Intenta escribir 1–2 frases cortas con las que GPT explique al usuario el paso a la App. Compara distintos tonos: más formal («Abro la aplicación GiftGenius…») y más cercano («Probemos el asistente GiftGenius: así será más fácil comparar opciones»).

Así aprenderás a pensar no solo como desarrollador, sino también como autor del diálogo.

9. Errores típicos en el UX de «cuándo mostrar la App»

Error n.º 1: Mostrar la App ante cualquier mención del tema.
Una exageración frecuente: si la App trata de regalos, cualquier palabra «regalo» en el diálogo dispara el widget. El usuario pregunta «cómo no meter la pata con el regalo para mi jefe», y en lugar de un consejo vivo recibe una UI con tarjetas. Se percibe como publicidad e ignora la intención real del usuario, lo que contradice directamente las UX‑guidelines oficiales y el principio «Respect user’s intent».

Error n.º 2: Pantalla completa sin aviso.
El «widget sorpresa» que de repente ocupa toda la pantalla es una forma segura de arruinar la experiencia. Especialmente feo en mitad de una conversación larga, cuando el usuario no esperaba un salto brusco del texto a la UI. Según las guías de OpenAI, estos escenarios son mala práctica; siempre hay que anunciar el paso y, si es posible, pedir consentimiento.

Error n.º 3: UI en lugar de respuesta.
A veces los autores de la App piensan: «¿Para qué responder con texto si tenemos una interfaz bonita?». Al final GPT casi no dice nada, y todas las «respuestas» están escondidas en el widget. El usuario, sobre todo en modo voz o en móvil, puede ni siquiera ver detalles importantes. El enfoque correcto: la UI complementa la respuesta, no la sustituye: la App muestra detalles y opciones; GPT explica qué significan.

Error n.º 4: Ignorar el rechazo del usuario a la App.
Si la persona ha dicho explícitamente «no abras la aplicación» o «responde solo con texto», la App debe asumirlo como regla estricta hasta el final del diálogo. Seguir proponiendo la App cada dos mensajes es como un pop‑up insistente de «valora nuestro servicio». Estas cosas empeoran el UX y pueden afectar a la review en el Store. En el system‑prompt hay que codificar explícitamente el respeto al rechazo.

Error n.º 5: No distinguir entre auto‑launch y «propuesta».
Cuando el desarrollador no distingue entre intenciones explícitas y no explícitas, o bien nunca lanza la App aunque el usuario lo pida, o bien la lanza siempre, incluso cuando el usuario solo dijo «quizá algún día pruebe vuestra App». De ahí el auto‑inicio del widget «solo porque la palabra se parece». La formalización de disparadores (auto / suggest / avoid) y una lógica pensada en el system‑prompt ayudan a evitar esta confusión.

Error n.º 6: Ausencia total de reglas UX en el system‑prompt.
A veces todas las decisiones de UX están solo «en la cabeza del equipo», y el system‑prompt se reduce a «Eres el asistente GiftGenius, ayuda con regalos». Como resultado, el modelo a veces propone la App, otras veces se olvida de ella, o la abre en un momento inadecuado. Reglas de UX escritas y estructuradas en el system‑prompt y en la documentación son un artefacto tan importante como el esquema JSON de las herramientas.

Error n.º 7: Intentar «añadir el UX después».
Un enfoque común —primero «hacer que todo funcione» y luego ya pensar en UX. En el caso de las ChatGPT Apps esto lleva a que ya te has atado a ciertos patrones de invocación de herramientas, y cambiar el system‑prompt y el comportamiento de GPT es más difícil. Es mejor sentar al menos unas UX‑guidelines básicas desde el principio: chat‑first, respeto al rechazo, criterios claros para mostrar la App y ausencia de «widgets sorpresa». Así todo el desarrollo posterior (patrones inline, pantalla completa, voz) se construirá sobre una base sólida.