UX‑guidelines от OpenAI: когда показывать App и как не «захватывать» диалог

1. Chat‑first: ChatGPT — это сначала чат, а уже потом приложения

За первые 6 модулей мы разобрались со всеми аспектами приложения: от UI и MCP до дебага и деплоя. Теперь мы еще раз пойдемся по всем его сторонам, только глубже. Вы же не думали, что все будет так просто, да?

И начнем мы с UX, а точнее с официальных UI‑requiremtnts и UX‑guidelines. Вы же хотите, чтобе ваше приложение прошло review, не так ли? Отлично, тогда начем с самого интересного: главный сдвиг в голове, который нужен фронтендеру, привыкшему к SPA/Next.js: ChatGPT — это в первую очередь диалоговый интерфейс, а App — гость внутри этого диалога. Не наоборот.

OpenAI в своих гайдлайнах формулирует это так: приложения расширяют то, что может сделать пользователь, не ломая поток разговора. Виджет — это не новая вкладка браузера, а аккуратная вставка в чат, которая даёт структуру там, где текстом уже тяжело.

Проще всего запомнить через разделение ролей.

Роли GPT и App

Внутри ChatGPT есть два «персонажа»:

GPT остается главным рассказчиком. Он словами объясняет, что сейчас произойдёт, почему он предлагает App, что означают кнопки, и подытоживает результат работы виджета. App, в свою очередь, сосредоточен на визуальной части и действиях: выбор вариантов, настройка фильтров, прохождение шагов мастера.

Очень важное правило, которое придётся повторять как мантру: все важные решения должны явно проговариваться в текстовом ответе GPT, даже если пользователь кликает по UI. Пользователь не обязан читать каждую строчку в интерфейсе виджета — ключевые последствия (например, «мы оформили заказ» или «вы выбрали вот эти параметры») должны быть озвучены в чате.

2. Когда App действительно нужен: критерии показа

С технической точки зрения вы можете вызывать виджет хоть при каждом сообщении. Но с точки зрения UX — это как открывать полноэкранный диалог при каждом вводе символа в input. Работает — да. Комфортно жить с этим — нет.

OpenAI и Apps SDK предлагают простой принцип: App уместен тогда, когда с ним думать проще, чем с одним только текстом.

Запросы со структурой и повторяемым сценарием

App хорошо заходит, когда пользовательский запрос уже намекает на структуру:

• «Подбери 5 вариантов подарков для коллеги до $50».
• «Сравни вот эти три тарифных плана».
• «Составь маршрут на 3 дня по Токио».
• «Покажи мой список задач на неделю и помоги расставить приоритеты».

Во всех этих случаях есть явные сущности (подарки, тарифы, дни маршрута, задачи), которыми нужно манипулировать, и шаги: выбрать, отфильтровать, сравнить, подтвердить. Здесь UI с карточками, чекбоксами, фильтрами оправдан и даже спасает.

Примеры для GiftGenius

Возьмём нашего любимого героя GiftGenius. Вот типичный запрос:

Нужно подобрать подарки для 10 гостей на свадьбу, с разными бюджетами и интересами.

Чистым текстом GPT может перечислить 10 отдельных списков, но читать это будет больно. Гораздо приятнее:

• показать таблицу гостей, бюджета и интересов,
• дать возможность фильтровать «дешевле/дороже»,
• вывести набор карточек по каждому гостю.

Здесь App практически обязателен: слишком много сущностей и параметров, чтобы держать это только текстом.

В отличие от этого:

Что подарить брату на 5000 BGN?

Это одношаговый, небольшой вопрос. GPT может ответить текстом с 3–5 идеями, и только если пользователь попросит «покажи варианты, где я могу отфильтровать по хобби и возрасту», можно плавно перейти к App.

Мини‑эвристика

Полезно держать в голове простую таблицу:

Подробно про inline и fullscreen мы будем говорить в следующих лекциях, но уже сейчас видно: App — инструмент для структурных, многошаговых задач, а не для каждого «мне грустно, что делать?».

3. Когда App мешает: режим «поговорить» и размышления

Мы уже посмотрели, в каких случаях App действительно упрощает жизнь и помогает структуре диалога. Но у этой медали есть и обратная сторона: бывают ситуации, где любой UI только мешает.

Столько разговоров о «давайте рисовать UI» часто приводят к рефлексу: «о, пользователь что‑то спросил — пора запускать виджет». Это тот момент, где в ревью Store вы можете получить минус к UX.

Есть целый класс запросов, где App чаще всего вреден:

1. Пользователь в режиме «поговорить». Это философские размышления, личные вопросы, карьерные дилеммы, терапевтические беседы. В таких сценариях пользователь ожидает текстовую беседу, вопросы‑уточнения, иногда эмпатию. Вставка карточек и фильтров здесь будет ощущаться как спам‑баннер.
2. Вводные вопросы о сервисе. Если человек пишет «Расскажи, что может GiftGenius?» — он хочет обзор, а не сразу UI. Здесь GPT лучше сначала кратко объяснит назначение App, возможно, приведёт примеры запросов, и только потом аккуратно предложит попробовать виджет.
3. Общие теоретические вопросы. «Как выбирать подарки интровертам?» или «Как работает система лояльности в магазинах?» — это обучающий, а не транзакционный сценарий. GPT может дать хороший текстовый ответ, а в конце ненавязчиво добавить: «Если захотите, могу открыть GiftGenius и подобрать несколько конкретных вариантов».

Везде, где UI не даёт новой ценности, а лишь дублирует текст, лучше оставаться в чате. Это и есть уважение к намерениям пользователя, про которое так любят писать UX‑гуру.

4. Как предлагать App: auto‑launch против «скромной передачи»

Даже если вы уверены, что App уместен, вопрос «как его запустить» остаётся открытым. Грубый вариант: виджет неожиданно открывается в fullscreen без предупреждения. Нормальный вариант: GPT сначала объясняет словами, что произойдёт, и спрашивает согласие или хотя бы уведомляет.

В документации по UX ChatGPT Apps выделяют два паттерна: auto‑launch и suggestion (humble handoff).

Auto‑launch: когда пользователь попросил явно

Auto‑launch уместен, когда пользователь дал явное намерение:

Запусти GiftGenius.
Открой настройки GiftGenius.
Покажи мою корзину подарков в GiftGenius.

Здесь правила простые:

1. GPT коротко пишет что‑то вроде «Открываю GiftGenius…».
2. Модель сразу вызывает инструмент / виджет.

Диалог может выглядеть так:

Пользователь: Запусти GiftGenius, хочу подобрать подарок другу.
GPT: Открываю помощника GiftGenius для подбора подарков.
[Появляется виджет GiftGenius inline или fullscreen]

Автозапуск без лишних уточнений оправдан, потому что пользователь сам попросил «открыть».

Suggestion (humble handoff): когда намерение неявное

Во многих случаях пользователь не знает про ваше приложение вообще. Он пишет:

Нужно что‑то придумать для коллеги на день рождения, бюджет небольшой.

Здесь правильный паттерн:

1. GPT анализирует запрос и понимает, что App может помочь.
2. GPT задаёт 1–2 уточняющих вопроса или сразу предлагает App текстом.
3. Только после согласия или явного намёка — запускает виджет.

Пример:

Пользователь: Нужно что‑то придумать для коллеги на день рождения, бюджет небольшой.
GPT: Могу помочь с идеями сам или открыть приложение GiftGenius, где мы подберём варианты по бюджету и интересам. Предпочитаете просто советы или попробовать приложение?
Пользователь: Давай приложение.
GPT: Открываю GiftGenius, чтобы подобрать варианты подарков.
[Появляется виджет]

Такой подход подчёркивает: инициатива всё равно за пользователем, а App — это опция, а не навязанный баннер. Это хорошо сочетается с принципом «Respect user’s intent» из UX‑гайдлайнов.

Мини‑пример «классификатора намерений» на TypeScript

Представим, что на стороне вашего backend’а вы уже примерно классифицируете пользовательский запрос (не путать с самим GPT, это вспомогательная логика):

// Упрощённый тип намерений пользователя
type UserIntent = 'chat' | 'ask_gift_advice' | 'open_app';

// Какой триггер для App мы хотим использовать
type AppTrigger = 'auto' | 'suggest' | 'avoid';

function decideAppTrigger(intent: UserIntent): AppTrigger {
  if (intent === 'open_app') return 'auto';      // "запусти GiftGenius"
  if (intent === 'ask_gift_advice') return 'suggest'; // неявный запрос
  return 'avoid';                                // обычный чат, без App
}

Эта логика сама по себе не вызывает виджет — это скорее способ формализовать ваш UX‑подход. Дальше эти правила вы переводите в system‑prompt и описания App, чтобы модель вела себя в том же духе.

5. Как не «захватывать» диалог: хорошие и плохие паттерны

У OpenAI в документации и в статьях по UX‑дизайну для ChatGPT Apps довольно чётко сформулировано, чего делать не надо: не «воровать» разговор. То есть не превращать чат в канал продвижения вашего интерфейса.

Антипаттерны

Самый больной — «сюрприз‑виджет». Это когда пользователь ведёт глубокий диалог, и внезапно весь экран занимает fullscreen‑приложение, о котором он не просил. Контекст теряется, ощущение контроля тоже.

Другой частый грех — использовать App как рекламу. Например, пользователь спрашивает теоретический вопрос, а модель отвечает: «Сначала открою наш супер‑виджет, а там всё написано» и показывает UI, где половина — маркетинговые тексты. Официальные гайдлайны прямо называют такие сценарии «poor use cases».

Третий антипаттерн — частые ненужные переключения между UI и текстом. Если при каждом небольшом уточнении запускать и закрывать App, диалог напоминает мигающую гирлянду. Пользователь, особенно на мобильном, быстро устанет.

Хорошие практики

Во всех сценариях, где вы всё‑таки открываете App, старайтесь придерживаться трёх простых правил.

Во‑первых, предупреждайте. Пусть GPT явно скажет, что собирается открыть приложение, и зачем. Например: «Сейчас открою помощник GiftGenius, чтобы показать варианты в виде карточек». Это 1–2 строки, но они полностью меняют ощущение от перехода.

Во‑вторых, объясняйте, что делать в UI. Не все пользователи привыкли к новому интерфейсу. GPT может добавить текст: «Внизу вы увидите карточки подарков, можно переключаться страницами и нажать “Подробнее” на любом варианте». Если в виджете есть что‑то непривычное (например, «Показать ещё N» или нестандартные фильтры), лучше озвучить это словами.

В‑третьих, резюмируйте результат текстом. После того как App что‑то сделал (подобрал, посчитал, отправил), GPT должен коротко рассказать: «Я подобрал 3 варианта подарков. Первые два в бюджете до $50, третий чуть дороже, но с быстрой доставкой. Хотите сузить выбор?» Это особенно важно на мобильных устройствах и в голосовых сценариях: человек может не смотреть на UI, но услышит текстовое резюме.

6. Роль system‑prompt и описаний App в управлении UX

До этого вы уже видели, как system‑prompt определяет «личность» App и как модель пользуется инструментами. Теперь добавляем туда UX‑правила: когда предлагать App, как его анонсировать, когда от него воздерживаться.

Что прописать в system‑prompt

Для GiftGenius system‑prompt может включать раздел «Диалог и UX». В документации и статьях рекомендуют описывать это структурированно, отдельными правилами.

Пример фрагмента (псевдокод, но очень близко к реальности):

### Диалог и UX

1. Если пользователь даёт условия подбора подарка (для кого, бюджет, повод),
   сначала задай 1–2 уточняющих вопроса текстом.
2. После уточнений предложи открыть App GiftGenius:
   "Могу открыть помощника GiftGenius, чтобы показать варианты подарков. Открыть?"
3. Если пользователь явно просит "запусти GiftGenius" или "покажи список подарков",
   ответь "Открываю GiftGenius..." и сразу вызывай App без дополнительных вопросов.
4. Если пользователь просит теорию или общие советы (например, "как выбирать подарки"),
   отвечай текстом и не открывай App, пока он сам об этом не попросит.
5. Если пользователь говорит "не открывай приложение" или "просто ответь текстом",
   в дальнейшем не предлагай App в этом диалоге.
6. После работы App всегда резюмируй результат текстом (кратко).

Здесь в сжатом виде зашиты все наши UX‑принципы: chat‑first, уважение к отказу пользователя, разница между auto‑launch и suggest, обязательное текстовое резюме.

Как помочь себе TypeScript‑конфигами

В реальных проектах удобно хранить часть этих правил в структурированном виде (чтобы не искать потом текст в промптах руками). Например, можно завести простой конфиг:

// Условный тип конфига UX-триггеров 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' },
];

Этот конфиг сам по себе модель не читает — он нужен вам, как разработчикам, чтобы в одном месте собрать договорённости продукт/дизайн и потом аккуратно перенести их в system‑prompt, описания App и документацию.

7. Пример: как GPT анонсирует GiftGenius и не перехватывает беседу

Свяжем всё с нашим приложением. Представим, что пользователь впервые пишет в чат:

Ищу подарок для коллеги, примерно до 3000 лв, он любит настольные игры.

Хороший ответ модели (с учётом нашего system‑prompt) может выглядеть так:

Понял! Давайте уточним пару деталей и подберём идеи.

Скажите, примерно сколько ему лет и это скорее формальный подарок или от близкого друга?

(После вашего ответа я могу открыть помощника GiftGenius, где мы посмотрим варианты в виде карточек.)

После уточнения GPT пишет:

Отлично, у меня достаточно информации.

Сейчас открою приложение GiftGenius — в нём я покажу вам несколько вариантов подарков в виде карточек, вы сможете посмотреть детали и сузить выбор по бюджету и типу игры.

И только затем — запуск App. Ни одного «сюрприза», всё объяснено словами.

Небольшой React‑компонент «анонса App» внутри виджета

С точки зрения кода виджет обычно просто рендерится, когда его вызвали. Но вы можете заложить в его UI философию «не перехватывать» контекст, даже если он уже открыт.

Например, первый экран GiftGenius может быть очень простым:

// app/components/GiftGeniusIntro.tsx
export function GiftGeniusIntro() {
  return (
    <section style={{ padding: 16 }}>
      <h2 style={{ fontSize: 20, marginBottom: 8 }}>
        Подбор подарков с GiftGenius
      </h2>
      <p style={{ marginBottom: 12 }}>
        Я покажу несколько вариантов в виде карточек. Вы сможете
        выбрать понравившиеся, а ChatGPT объяснит плюсы и минусы.
      </p>
      <p style={{ fontSize: 12, color: '#666' }}>
        В любой момент можно вернуться к обычному чату и продолжить обсуждение.
      </p>
    </section>
  );
}

Этот компонент не делает ничего «мощного» технически, но с UX‑точки зрения он важен: он напоминает, что чат никуда не делся, и роль GPT остаётся центральной.

В дальнейшем именно из этого интро‑экрана вы будете переходить к карточкам подарков, мастерам и т.д., но это уже тема следующих лекций.

8. Практика и упражнения

Выше мы собрали набор принципов — chat‑first, уважение к намерениям пользователя, различие между auto‑launch и предложением App. Чтобы закрепить подход «когда и как показывать App», полезно продумать реальные запросы и явно разделить, где App нужен, а где — нет. В домашней практике можно сделать два маленьких упражнения.

Сначала возьмите GiftGenius и придумайте 5–7 пользовательских запросов. Для каждого честно ответьте себе:

• стоит ли здесь сразу предлагать открыть App;
• стоит ли только упомянуть App как опцию;
• или лучше вообще не связывать ответ с App.

Например:

1. «Подари что‑нибудь жене на годовщину, бюджет до $1000» — скорее всего, сначала пара уточняющих вопросов текстом, затем предложение открыть App.
2. «Как оригинально упаковать подарок?» — чисто теоретический вопрос, можно обойтись без App.
3. «Запусти GiftGenius, хочу выбрать подарки для всей команды» — прямой auto‑launch.

Второе упражнение — текст анонса запуска App. Попробуйте написать 1–2 короткие фразы, которыми GPT будет объяснять пользователю переход в App. Сравните разные тона: более формальный («Открываю приложение GiftGenius…») и более дружелюбный («Давайте попробуем помощника GiftGenius — так будет проще сравнить варианты»).

Так вы научитесь мыслить не только как разработчик, но и как автор диалога.

9. Типичные ошибки при UX «когда показывать App»

Ошибка №1: Показывать App по любому упоминанию темы.
Часто встречающаяся крайность: если App про подарки, любое слово «подарок» в диалоге тут же триггерит виджет. Пользователь спрашивает «как не облажаться с подарком начальнику», а вместо живого совета получает UI с карточками. Это воспринимается как реклама и игнорирует истинное намерение пользователя, что прямо противоречит официальным UX‑гайдлайнам и принципу «Respect user’s intent».

Ошибка №2: Fullscreen без предупреждения.
«Сюрприз‑виджет», который внезапно занимает весь экран, — надёжный способ испортить впечатление. Особенно плохо это выглядит в середине длительной беседы, когда пользователь не ожидал резкого перехода из текста в UI. По гайдлайнам OpenAI такие сценарии считаются плохой практикой; всегда нужно анонсировать переход и по возможности спрашивать согласие.

Ошибка №3: UI вместо ответа.
Иногда авторы App думают: «Зачем отвечать текстом, у нас же есть красивый интерфейс!» В итоге GPT почти ничего не говорит, всё «ответы» спрятаны в виджете. Пользователь, особенно в голосовом или мобильном режиме, может даже не заметить важные детали. Правильный подход — UI дополняет ответ, а не заменяет его: App показывает детали и варианты, GPT объясняет, что это значит.

Ошибка №4: Игнорирование отказа пользователя от App.
Если человек явно сказал «не открывай приложение» или «давай просто текстом», App должен принять это как жёсткое правило до конца диалога. Продолжать каждые два сообщения предлагать App — это как навязчивый поп‑ап «оцените наш сервис». Такие вещи ухудшают UX и могут повлиять на ревью в Store. В system‑prompt нужно явно зашивать уважение к отказу.

Ошибка №5: Нет различия между auto‑launch и «предложением».
Когда разработчик не различает явные и неявные намерения, он либо никогда не запускает App, даже когда пользователь прямо просит, либо всегда запускает, даже когда пользователь просто обронил фразу «может, когда‑нибудь попробую ваш App». Отсюда и авто‑открытие виджета «просто потому что слово похоже». Формализация триггеров (auto / suggest / avoid) и продуманная логика в system‑prompt помогают избежать этой путаницы.

Ошибка №6: Полное отсутствие UX‑правил в system‑prompt.
Иногда все UX‑решения хранятся только «в голове команды», а system‑prompt ограничивается «Ты ассистент GiftGenius, помогай с подарками». В итоге модель то предлагает App, то забывает про него, то открывает в неподходящий момент. Записанные, структурированные UX‑правила в system‑prompt и документации — это такой же важный артефакт, как JSON‑схема инструментов.

Ошибка №7: Попытка «прикрутить UX потом».
Распространённый подход — сначала «сделать, чтобы всё заработало», а потом когда‑нибудь подумать о UX. В случае ChatGPT Apps это приводит к тому, что вы уже завязались на определённые паттерны вызова инструментов, а менять system‑prompt и поведение GPT сложнее. Лучше закладывать хотя бы базовые UX‑guidelines сразу: chat‑first, уважение к отказу, ясные критерии показа App и отсутствие «сюрприз‑виджетов». Тогда всё последующее развитие (inline‑паттерны, fullscreen, voice) будет строиться на здоровом фундаменте.