Instrucciones en torno al UX: anuncio de App, no usar App y comportamiento en el diálogo

1. Por qué gestionar el UX mediante instrucciones

Desde el punto de vista de ChatGPT, tu App no es más que herramientas y widgets adicionales. Pero para el usuario es toda una interfaz aparte que aparece de repente en medio de la conversación. Si no controlas el comportamiento del modelo, puedes obtener dos escenarios extremos.

En un caso, GPT ignora la App e intenta «resolverlo todo con palabras». El usuario pide elegir un regalo y, en lugar de iniciar GiftGenius, el modelo suelta un ensayo textual largo con recomendaciones «por su cuenta». A veces no está mal, pero no escribiste tu App para que coja polvo en la estantería.

En el segundo caso, GPT, por el contrario, abusa de la App. Ante cualquier estornudo del tipo «¿Qué puede hacer su servicio?» lanza un widget, renderiza un formulario confuso, el usuario se asusta y cierra todo ese despliegue. Desde el punto de vista del UX resulta muy intrusivo.

Por eso la lógica es sencilla: el comportamiento hay que fijarlo explícitamente, igual que fijas el esquema JSON de una herramienta o las props de un componente de React. El system‑prompt (y las instrucciones asociadas) aquí es tu «protocolo de UX». En él describes cuándo y cómo el asistente:

• anuncia el inicio de la App;
• deliberadamente no inicia la App y responde con texto;
• se comporta después de que el widget ya haya mostrado el resultado;
• respeta las peticiones del usuario de «sin aplicaciones».

Todo esto no va de marketing ni de estilo de conversación. Realmente influye en con qué frecuencia se invocará tu App y en lo cómodo que se sentirá el usuario.

A continuación, paso a paso, veremos: cómo debe el asistente anunciar el inicio de la App, en qué casos es mejor no proponer el widget, cómo comportarse después de que la aplicación haya hecho su trabajo, cómo respetar peticiones explícitas del usuario sobre el formato del diálogo y cómo plasmar con cuidado todas estas reglas en el system‑prompt.

2. Anuncio de la App: cómo debe la modelo «avisar» del widget

Cuando ChatGPT decide usar la App, la interfaz cambia: en el chat aparece una tarjeta del widget, a veces en modo de pantalla completa, aparecen botones y otros elementos de la UI. Si el asistente muestra el widget sin explicaciones, el usuario puede no entender en absoluto qué ha pasado ni de dónde ha salido ese bloque.

Por eso es buena práctica explicar primero con texto qué va a ocurrir y solo después iniciar la App. Es parecido a cuando el navegador pregunta: «¿Abrir una ventana nueva?» o como cuando una app móvil te avisa: «Ahora te pediremos permiso para la cámara».

Tipos de anuncio

Se pueden distinguir, a grandes rasgos, tres estilos de anuncio.

El primero es una propuesta suave. El asistente dice algo como: «Puedo abrir la aplicación GiftGenius, que elegirá regalos según tus parámetros. ¿La abro?» y espera una respuesta «sí/no». Esto funciona bien en escenarios donde el usuario está conociendo el servicio o puede ser sensible al cambio de interfaz.

El segundo es una recomendación firme. Si tu App es la interfaz principal del producto, puedes decir: «Ahora iniciaré la aplicación GiftGenius y te mostraré varias opciones de regalos en forma de tarjetas». El asistente igualmente puede tener en cuenta un rechazo, pero por defecto actúa con más decisión.

El tercero es un aviso neutral. En este caso, el asistente simplemente informa: «Inicio la aplicación GiftGenius para seleccionar regalos…», sin largas explicaciones. Este estilo encaja cuando el usuario ya ha visto muchas veces tu App y espera su aparición.

Lo importante es que todas estas variantes se pueden y deben codificar en el system‑prompt. El modelo no se inventa frases de UX desde cero si le das de antemano el esqueleto.

Mini ejemplo de código: sección sobre el anuncio en el system‑prompt

Imagina que en tu plantilla de Next.js hay un archivo appDefinition.ts, donde defines el system‑prompt para la App:

// app/appDefinition.ts
export const systemPrompt = `
# Rol
Eres el ChatGPT App GiftGenius; ayudas a seleccionar regalos.

# Diálogo y UX — Anuncio de la aplicación
Si decides iniciar el widget GiftGenius,
primero explica en una o dos frases
que ahora se abrirá una aplicación con una selección de regalos
y en qué ayudará al usuario.
`;

Esto todavía no es un contrato completo, pero incluso una inserción tan pequeña ya aumenta mucho la previsibilidad del comportamiento.

Cuándo es especialmente importante el anuncio

Cuanto más complejo sea tu UI, más importante es anticipar su inicio. Si el widget solo muestra tres tarjetas de regalos, es un cambio de contexto relativamente suave. Pero si abres un asistente de varios pasos con filtros, presupuesto, categorías, etc., el usuario debe entender por qué el diálogo se convirtió de repente en una «mini aplicación web dentro del chat».

Las directrices oficiales de UX también subrayan que el asistente debe vincular explícitamente el texto y la UI, y no «colar» el widget silenciosamente junto a la respuesta.

3. Cuándo deliberadamente no proponer la App

El error más común en las primeras fases de desarrollo de una App es el clásico efecto «si tienes un martillo, todo te parecen clavos». Como tenemos un bonito GiftGenius, el modelo intenta meterlo en cada conversación. El usuario pregunta: «¿Qué puede hacer su aplicación?» y ChatGPT ya: «Inicio GiftGenius…», cuando en realidad la persona quería solo dos líneas de explicación.

Para evitarlo, en el system‑prompt hay que describir las situaciones en las que es mejor no proponer la App. A continuación, algunos escenarios típicos.

• En primer lugar, preguntas introductorias. Si alguien escribe algo como «¿Qué hace GiftGenius?» o «¿Cómo funcionáis?», las instrucciones deben exigir dar primero una breve explicación textual, sin iniciar la UI. El widget aquí solo distrae.
• En segundo lugar, peticiones demasiado generales o difusas. El usuario escribe «Háblame de regalos para Año Nuevo»; esto es más bien una pregunta educativa que una selección concreta. El asistente puede explicar brevemente los principios generales, hacer preguntas aclaratorias y, solo cuando aparezcan parámetros concretos (presupuesto, destinatario, categoría), proponer la App.
• En tercer lugar, peticiones fuera del dominio de la App. Si alguien dice: «Ayúdame a escribir un currículum», y tu App está orientada a regalos, el comportamiento correcto es responder honestamente como ChatGPT normal y no iniciar nada. A veces se puede mencionar con delicadeza para qué está pensada la App, pero no hay que imponerla cuando es claramente irrelevante.
• En cuarto lugar, rechazo explícito de la UI. Si el usuario escribe: «No abras ninguna aplicación, explícamelo en texto», el modelo debe obedecer, incluso si ve un escenario ideal para la App.

Tabla: tipo de petición y comportamiento del asistente

Ampliamos el system‑prompt con reglas para no usar la App

Continuemos con el mismo systemPrompt, añadiendo un bloque sobre cuándo no iniciar la App:

export const systemPrompt = `
# Rol
Eres el ChatGPT App GiftGenius; ayudas a seleccionar regalos.

# Cuándo NO iniciar el widget
Si el usuario solo pregunta qué puede hacer el servicio
o plantea una cuestión teórica general sobre regalos,
responde primero con texto y no inicies la aplicación.

Si la petición no está relacionada con la selección de regalos,
responde como ChatGPT normal y no propongas GiftGenius.

Si el usuario pide explícitamente no usar aplicaciones,
respétalo y trabaja solo en el chat.
`;

Este texto se convierte en decisiones concretas del modelo en situaciones límite, donde de otro modo podría «tirar del hilo» hacia la UI. Ya hemos fijado cuándo la App no es necesaria. Ahora es importante describir la otra cara: qué debe hacer el asistente cuando el widget ya ha hecho su trabajo y el usuario ve el resultado.

4. Comportamiento tras usar la App: follow‑up y cierre del escenario

En el módulo sobre el widget ya viste cómo los mensajes de follow‑up ayudan a continuar el diálogo tras ejecutarse la UI. El widget muestra tarjetas y, debajo, el asistente escribe algo como: «He encontrado estas opciones de regalo para un colega con presupuesto de hasta $50. ¿Quieres que te muestre opciones más baratas o que cambie la categoría?» y propone botones con acciones populares.

Ahora nuestra tarea es fijar este comportamiento en las instrucciones, y no depender de la «intuición» del modelo.

Qué debe hacer el asistente después del widget

En el escenario ideal ocurren varias cosas.

• Primero, el asistente resume brevemente con palabras el resultado del trabajo de la App. Aunque el widget haya mostrado diez tarjetas, es útil escribir: «He seleccionado 4 opciones de regalo para un colega con presupuesto de hasta $50. Entre ellas hay una taza con impresión personalizada, una planta de escritorio, un buen set de café y una libreta con estilo».
• Después, propone los siguientes pasos. Aquí ayudan frases de follow‑up pensadas de antemano: «¿Quieres ver opciones más baratas?», «¿Necesitas acotar por intereses?», «¿Mostrar solo las disponibles en tu región?». Estas mismas frases puedes usarlas en sendFollowUpMessage en el widget, y también recomendarlas al modelo en el system‑prompt.
• Y por último, si el usuario cierra explícitamente el escenario («Gracias, es suficiente»), el asistente «cierra» el tema con cuidado: reconoce que la tarea está resuelta y ofrece ayudar con algo más.

Diagrama de flujo: pregunta → widget → follow‑up

Para mayor claridad, podemos imaginar el comportamiento del asistente como un sencillo autómata de estados.

flowchart TD
    U[El usuario plantea la tarea] --> G[GPT decide: ¿lanzar App?]
    G -->|Sí| A[Anuncia el inicio de la App]
    A --> W[El widget GiftGenius selecciona opciones]
    W --> S[El asistente resume el resultado]
    S --> F[El asistente propone opciones de follow-up]
    F -->|El usuario elige una acción| G
    G -->|No, no lanzar App| T[Respuesta textual sin UI]
    F -->|"El usuario dice \"Gracias\""| E[El asistente cierra el escenario y ofrece otra ayuda]

Este flujo es, de hecho, lo que describimos con palabras en el system‑prompt.

Ejemplo de código: follow‑up desde el widget

Del lado de la UI ya sabes enviar mensajes de follow‑up. Para completarlo, aquí tienes un ejemplo sencillo de un componente que, tras pulsar un botón, pide al modelo «ampliar el presupuesto»:

// components/ExpandBudgetButton.tsx
export function ExpandBudgetButton() {
    const onClick = () => {
        window.openai?.sendFollowUpMessage(
            "Muestra opciones con un presupuesto un poco mayor"
        );
    };

    return <button onClick={onClick}>Quiero opciones más caras</button>;
}

Ahora añadiremos al system‑prompt el texto que sugiera al modelo cómo procesar estos mensajes de follow‑up.

// continuación de systemPrompt
const followUps = `
# Comportamiento tras iniciar la aplicación
Después de que el widget haya mostrado la lista de regalos,
describe brevemente el resultado con texto.

Luego propone 1–3 siguientes pasos claros
(por ejemplo: mostrar más baratos, cambiar el presupuesto, cambiar de categoría).
Si el widget envía un mensaje de follow-up,
úsalo como pista para el siguiente paso.
`;

Desde el punto de vista técnico es una cadena normal. Desde el punto de vista del UX, es la base de un escenario predecible.

5. Respeto a las intenciones del usuario

Todo lo que hemos comentado arriba son tus expectativas de producto sobre el comportamiento de la App. Las instrucciones de UX funcionarán mal si el modelo no sabe «escuchar» al usuario. Incluso una App perfectamente diseñada debe ceder si la persona pide explícitamente no cambiar el formato de interacción.

Hay varias situaciones características.

• Si el usuario dice claramente que no quiere iniciar aplicaciones («Nada de UI, solo dime qué comprar»), el asistente debe interpretarlo como una restricción estricta y no intentar sortearla. Se puede decir con cortesía: «De acuerdo, responderé solo con texto», y cumplirlo de verdad.
• Si el usuario teme que algo se inicie automáticamente, es útil darle sensación de control. Por ejemplo: «Puedo abrir la aplicación para elegir regalos, pero si lo prefieres, podemos comentar opciones solo en el chat. ¿Cómo te resulta más cómodo?». Aquí ofreces una elección explícita.
• Si el usuario escribe «Estoy con el móvil, no inicies formularios complejos», eso también forma parte del contexto. El asistente debe aceptarlo y, por ejemplo, limitarse a una lista corta de ideas y preguntas aclaratorias.

Incorporamos el respeto al contrato

Todo esto puede reflejarse de forma compacta en el system‑prompt:

export const respectBlock = `
# Prioridad de las intenciones del usuario
Ten siempre en cuenta las peticiones explícitas del usuario
sobre el formato de comunicación.

Si pide no iniciar aplicaciones o widgets,
no propongas ni inicies GiftGenius,
aunque eso ayudara a resolver la tarea.
En su lugar, ayuda con texto.
`;

Así fijas claramente «quién manda» en el diálogo. Y spoiler: no es tu orgullo por una UI bonita, sino la persona al otro lado de la pantalla.

6. Cómo estructurar las instrucciones de UX dentro del system‑prompt y en la documentación

Ya hemos reunido bastantes reglas de comportamiento — desde el anuncio de la App hasta los mensajes de follow‑up y el respeto al formato del diálogo. Ahora importa no solo el qué le decimos al modelo, sino también el cómo está redactado en el system‑prompt y la documentación.

El system‑prompt en una App real crece rápido. Si lo escribes como un texto literario corrido, en una semana nadie encontrará nada. Por eso trátalo como una especificación técnica o un README: estructúralo.

Es buena práctica dividir el prompt en varias secciones lógicas con títulos. Por ejemplo: «Rol y ámbito de responsabilidad», «Cuándo usar la App», «Cuándo no usar la App», «Diálogo y UX», «Seguridad y limitaciones». Dentro de cada sección escribe frases simples y unívocas.

Mejor aún: extrae el system‑prompt a un archivo separado junto al código, en lugar de meterlo como literal de cadena en medio de un componente. Así será más fácil revisarlo, comparar cambios y discutirlo con product managers o jurídicos.

Ejemplo de organización del system‑prompt en el código

Una opción es guardar partes del prompt en cadenas separadas y componerlas en un todo:

// app/prompt/role.ts
export const roleSection = `
# Rol
Eres el ChatGPT App GiftGenius.
Ayudas al usuario a seleccionar regalos según la tarea y el presupuesto.
`;

// app/prompt/ux.ts
export const uxSection = `
# Diálogo y UX
Antes de iniciar el widget GiftGenius,
explica brevemente que se abrirá una aplicación con tarjetas de regalos.
No inicies la aplicación para preguntas generales o teóricas,
a menos que el usuario pida explícitamente una selección.
Después de que el widget trabaje, resume el resultado con texto
y propone 1–3 siguientes pasos.
`;

// app/appDefinition.ts
import { roleSection } from "./prompt/role";
import { uxSection } from "./prompt/ux";

export const systemPrompt = `
${roleSection}
${uxSection}
`;

Esta división ayuda a pensar en las instrucciones como módulos separados: parte de UX, seguridad, trabajo con herramientas, etc. Resulta especialmente útil cuando vayas añadiendo nuevas capacidades y tengas que alinear el comportamiento con varios equipos.

Además, tiene sentido sincronizar la documentación de la App (README interno, Confluence, Notion) con estas secciones. Allí puedes explicar en lenguaje natural por qué anuncias la App de esa manera y por qué no la inicias para peticiones de prueba. Fija aparte cómo deben ser las réplicas de follow‑up. Así, la gente nueva del equipo no intentará «arreglar» el prompt sin entender lo que hicisteis.

7. Práctica: reescribimos la parte de UX para nuestro GiftGenius

Vamos a reunir todo en un ejemplo más o menos completo de system‑prompt. Supongamos que teníamos un system‑prompt muy escueto:

export const systemPrompt = `
Eres la aplicación GiftGenius.
Selecciona regalos para el usuario.
`;

Ese texto no dice nada sobre cuándo iniciar la App, cómo anunciarla y qué hacer tras el widget. Añadamos las instrucciones de UX paso a paso.

Primero, delimitemos claramente el ámbito de responsabilidad y el formato de trabajo:

const role = `
# Rol
Eres el ChatGPT App GiftGenius.
Tu tarea es ayudar al usuario a seleccionar 3–7 regalos relevantes
según el presupuesto, el destinatario y el motivo.
Puedes usar el widget GiftGenius para una selección visual.
`;

A continuación, describamos cómo anunciar el inicio:

const announce = `
# Anuncio de la aplicación
Si consideras que el widget GiftGenius ayudará más,
explica primero en una o dos frases
que se abrirá una aplicación con tarjetas de regalos
y que el usuario podrá verlas y filtrarlas.
Solo después inicia la aplicación.
`;

Añadimos reglas sobre cuándo no iniciar la App:

const noApp = `
# Cuándo no usar la aplicación
Si el usuario solo pregunta qué puede hacer el servicio
o quiere información teórica general sobre regalos,
responde con texto y no inicies GiftGenius.

Si la petición no se refiere a regalos (por ejemplo, sobre CV o código),
responde como ChatGPT normal y no propongas la aplicación.

Si el usuario pide no usar aplicaciones,
trátalo como una restricción obligatoria.
`;

Y terminamos con el comportamiento tras usar el widget:

const afterWidget = `
# Comportamiento tras el widget
Después de que el widget muestre opciones de regalos,
describe brevemente el resultado con tus palabras.
Propón al usuario 1–3 siguientes pasos
(por ejemplo: cambiar el presupuesto, filtrar por intereses,
mostrar solo opciones más baratas).

Si el widget envió un mensaje de follow-up,
úsalo como señal principal para el siguiente paso.
`;

El system‑prompt final puede verse así:

export const systemPrompt = `
${role}
${announce}
${noApp}
${afterWidget}
`;

Esto ya se parece a una especificación de comportamiento y no a un «deseo al universo». En los siguientes módulos completarás este contrato con instrucciones sobre seguridad, alucinaciones, comercio y otras alegrías de la vida adulta de una App, pero la parte de UX ya queda como cimiento.

8. Errores típicos al configurar instrucciones de UX

Error n.º 1: «La App siempre es mejor que el texto».
A veces los desarrolladores están tan orgullosos de su widget que le exigen al modelo invocarlo a la mínima. Como resultado, el usuario recibe la App incluso donde solo quería preguntar «¿qué es esto?». El modelo se vuelve intrusivo y la gente empieza a ignorar la aplicación. El enfoque correcto es especificar explícitamente los escenarios en los que la App no es necesaria y respetar esos casos.

Error n.º 2: ausencia de un anuncio explícito antes de iniciar la App.
Si el asistente inicia el widget en silencio, el usuario no entiende de dónde ha salido el bloque de UI ni qué hacer con él. Las directrices de OpenAI y la experiencia práctica muestran que una o dos frases del tipo «ahora abriré una aplicación que hará X» mejora drásticamente el UX y reduce la confusión.

Error n.º 3: propuesta demasiado agresiva de volver a usar la App.
Ocurre que, después de cada respuesta, la App vuelve a proponer iniciar el widget: «¿Quieres abrir la aplicación otra vez? ¿Y ahora? ¿Y ahora?». Esto se convierte rápidamente en spam. Mejor fijar en las instrucciones que, tras el primer uso de la App, hay que atender al contexto: proponerla de nuevo solo si el usuario cambia explícitamente los parámetros de la tarea o pide «mostrar más».

Error n.º 4: ignorar un rechazo explícito a usar aplicaciones.
Frases como «solo sin aplicaciones, por favor» o «me resulta incómodo trabajar con formularios desde el móvil» deben tratarse como restricciones estrictas. Si el modelo sigue imponiendo la App, el usuario pierde confianza tanto en el asistente como en tu producto. En el system‑prompt esto se fija fácilmente con dos o tres frases, pero muchos se olvidan de hacerlo.

Error n.º 5: ausencia de resumen y mensajes de follow‑up tras el widget.
A veces el widget muestra honestamente las opciones y, después, el asistente se queda callado. El usuario ve la UI, pero no entiende qué hacer luego. Sin texto, sin pregunta, sin botones con acciones populares. Ese escenario parece incompleto y rompe la coherencia del diálogo. Especifica siempre en las instrucciones que, tras el widget, debe venir un breve resumen en texto y 1–3 siguientes pasos claros.

Error n.º 6: mezclar el UX de producto y el «estilo general de ChatGPT» en un mismo párrafo.
A veces el system‑prompt se convierte en un texto literario largo: «Sé amigable, usa emojis, haz bromas a veces si encaja. Y sí, quizá, alguna vez, inicia la App». En un texto así es muy difícil detectar reglas reales de UX. Es mejor separar secciones con títulos claros: «Rol», «Diálogo y UX», «Cuándo usar la App», «Cuándo no usar la App». Esto ayuda tanto al modelo como a las personas que trabajarán con el prompt después de ti.