UX‑гайдлайни від OpenAI: коли показувати App і як не «перехоплювати» діалог

1. Chat‑first: ChatGPT — спочатку чат, а вже потім застосунки

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

Почнімо з UX — а точніше, з офіційних UI‑вимог і UX‑гайдлайнів. Ви ж хочете, щоб ваш застосунок пройшов ревʼю, чи не так? Тоді рушаймо до найцікавішого: до головного зсуву в мисленні, який потрібен фронтендеру, звиклому до 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 ₴?

Це невелике одноетапне запитання. 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

Уявімо, що на боці вашого бекенду ви вже приблизно класифікуєте користувацький запит (не плутайте із самим 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‑гайдлайни одразу: chat‑first, повага до відмови, чіткі критерії показу App і відсутність «сюрприз‑віджетів». Тоді весь подальший розвиток (inline‑патерни, fullscreen, voice) будуватиметься на здоровому фундаменті.