Інструкції щодо UX: анонс App, відмова від App і поведінка в діалозі

1. Навіщо взагалі керувати UX через інструкції

З погляду ChatGPT ваш App — це лише додаткові інструменти та віджети. А для користувача — окремий інтерфейс, який може раптово зʼявитися посеред розмови. Якщо не керувати поведінкою моделі, легко отримати два крайні сценарії.

У першому випадку GPT ігнорує App і намагається «розвʼязати все словами». Користувач просить підібрати подарунок, а модель замість запуску GiftGenius видає довге текстове есе з рекомендаціями «від себе». Іноді це справді доречно. Але ви створювали App не для того, щоб він припадав пилом на полиці.

У другому випадку GPT, навпаки, зловживає App. На будь‑яку дрібницю на кшталт «Що вміє ваш сервіс?» він запускає віджет, показує незрозумілу форму — і користувач лякається та закриває всю цю «красу». З погляду UX це виглядає надто навʼязливо.

Тому логіка проста: поведінку потрібно зафіксувати явно — так само, як ви фіксуєте JSON‑схему інструмента або пропси React‑компонента. System‑prompt (і супровідні інструкції) тут — ваш «UX‑протокол». У ньому ви описуєте, коли і як асистент:

• анонсує запуск App;
• свідомо не запускає App, а відповідає текстом;
• поводиться після того, як віджет уже показав результат;
• поважає запити користувача «без застосунків».

Усе це не про маркетинг і не про стиль спілкування. Це напряму впливає на те, як часто викликатиметься ваш App і наскільки комфортно почуватиметься користувач.

Далі крок за кроком розберемо, як асистент має анонсувати запуск App. Також зʼясуємо, у яких випадках краще свідомо не пропонувати віджет, як поводитися після того, як застосунок спрацював, і як поважати чіткі прохання користувача щодо формату діалогу. Наприкінці подивимося, як акуратно оформити всі ці правила в system‑prompt.

2. Анонс App: як модель має «попереджати» про віджет

Коли ChatGPT вирішує використати App, інтерфейс змінюється. У чаті зʼявляється картка віджета (іноді — у повноекранному вигляді), кнопки та інші елементи UI. Якщо асистент просто, без пояснень, покаже віджет, користувач може взагалі не зрозуміти, що сталося і звідки взявся цей блок.

Тому гарний тон — спочатку текстом пояснити, що зараз відбудеться, і лише потім запускати App. Це схоже на те, як браузер запитує: «Відкрити нове вікно?» або як мобільний застосунок попереджає: «Зараз ми попросимо у вас дозвіл на камеру».

Типи анонсів

Умовно можна виокремити три стилі анонсу.

Перший — мʼяка пропозиція. Асистент каже щось на кшталт: «Я можу відкрити для вас застосунок GiftGenius, який підбере подарунки за вашими параметрами. Відкрити його?» — і чекає відповіді «так/ні». Це добре працює в сценаріях, де користувач лише знайомиться із сервісом або може бути чутливим до зміни інтерфейсу.

Другий — упевнена рекомендація. Якщо ваш App — основний інтерфейс продукту, ви можете писати: «Зараз запущу застосунок GiftGenius і покажу кілька варіантів подарунків у вигляді карток». Асистент однаково має врахувати відмову, але за замовчуванням діє рішучіше.

Третій — нейтральне повідомлення. У цьому випадку асистент просто повідомляє: «Запускаю застосунок GiftGenius для підбору подарунків…» — без довгих пояснень. Такий стиль доречний, коли користувач уже багато разів бачив ваш App і очікує його появи.

Важливо, що всі ці варіанти можна й потрібно «зашити» в system‑prompt. Модель не вигадує UX‑фрази з нуля, якщо ви заздалегідь даєте їй «скелет».

Міні‑приклад коду: секція про анонс у system‑prompt

Уявіть, що у вашому Next.js‑шаблоні є файл appDefinition.ts, де ви задаєте system‑prompt для App:

// app/appDefinition.ts
export const systemPrompt = `
# Роль
Ти — ChatGPT App GiftGenius, допомагаєш підбирати подарунки.

# Діалог і UX — Анонс застосунку
Якщо вирішуєш запустити віджет GiftGenius,
спочатку одним‑двома реченнями поясни,
що зараз відкриється застосунок з добіркою подарунків
і чим він допоможе користувачу.
`;

Це ще не повноцінний контракт, але навіть така невелика вставка вже суттєво підвищує передбачуваність поведінки.

Коли анонс особливо важливий

Що складніший ваш UI, то важливіше заздалегідь проговорювати його запуск. Якщо віджет просто показує три картки подарунків — це відносно мʼяка зміна контексту. Якщо ж ви відкриваєте цілий багатокроковий майстер із фільтрами, бюджетом, категоріями тощо, користувач має розуміти, чому діалог раптово перетворився на «невеликий веб‑застосунок усередині чату».

Офіційні UX‑настанови також підкреслюють: асистент має явно повʼязувати текст і UI, а не мовчки «підкидати» віджет до відповіді.

3. Коли свідомо не пропонувати App

Найчастіша помилка на ранніх етапах розробки App — класичний ефект «якщо в руках молоток, то все здається цвяхами». Раз у нас є красивий GiftGenius, модель починає тягнути його в кожен діалог. Користувач запитує: «А що взагалі вміє ваш застосунок?», а ChatGPT уже: «Запускаю GiftGenius…», хоча людині хотілося просто двох рядків пояснення.

Щоб цього уникнути, у system‑prompt потрібно описати ситуації, коли App краще не пропонувати. Нижче — кілька типових сценаріїв.

• По‑перше, ознайомчі запитання. Якщо людина пише щось на кшталт «Що робить GiftGenius?» або «Як ви працюєте?», інструкції мають вимагати спочатку дати коротке текстове пояснення — без запуску UI. Віджет тут лише відволікає.
• По‑друге, надто загальний або розмитий запит. Користувач пише «Розкажи про подарунки на Новий рік» — це радше освітнє запитання, ніж конкретний підбір. Асистент може коротко пояснити загальні принципи, поставити уточнювальні запитання і лише тоді, коли зʼявляться конкретні параметри (бюджет, отримувач, категорія), запропонувати App.
• По‑третє, запити поза доменом App. Якщо людина каже: «Допоможи написати резюме», а ваш App заточений під подарунки, правильна поведінка — чесно відповісти як звичайний ChatGPT і нічого не запускати. Іноді можна акуратно згадати, для чого призначений App, але не варто навʼязувати його, коли він явно нерелевантний.
• По‑четверте, явна відмова від UI. Якщо користувач пише: «Тільки не відкривай жодних застосунків, просто поясни текстом», модель зобовʼязана підкоритися, навіть якщо бачить ідеальний сценарій для App.

Таблиця: тип запиту та поведінка асистента

Доповнюємо system‑prompt правилами відмови від App

Продовжимо той самий systemPrompt, додавши блок про те, коли App не запускати:

export const systemPrompt = `
# Роль
Ти — ChatGPT App GiftGenius, допомагаєш підбирати подарунки.

# Коли НЕ запускати віджет
Якщо користувач питає лише про те, що вміє сервіс,
або ставить загальне теоретичне питання про подарунки,
спочатку відповідай текстом і не запускай застосунок.

Якщо запит не пов’язаний із підбором подарунків,
відповідай як звичайний ChatGPT і не пропонуй GiftGenius.

Якщо користувач явно просить не використовувати застосунки,
обов’язково поважай це й працюй лише в чаті.
`;

Такий текст перетворюється на конкретні рішення моделі в прикордонних ситуаціях, де інакше вона могла б «перетягнути ковдру» в бік UI. Ми зафіксували, коли App не потрібен. Тепер важливо описати й зворотний бік: що робити асистенту, коли віджет уже спрацював і користувач бачить результат.

4. Поведінка після використання App: follow‑up і завершення сценарію

У модулі про віджет ви вже бачили, як follow‑up‑повідомлення допомагають продовжувати діалог після того, як UI спрацював. Віджет показує картки, а під ним асистент пише щось на кшталт: «Я знайшов такі‑то варіанти подарунків для колеги в бюджеті до $50. Бажаєте, покажу дешевші або зміню категорію?» — і пропонує кнопки з популярними діями.

Тепер наше завдання — зафіксувати цю поведінку в інструкціях, а не покладатися на «інтуїцію» моделі.

Що має робити асистент після віджета

В ідеальному сценарії відбувається кілька речей.

• Спочатку асистент коротко резюмує результат роботи App словами. Навіть якщо віджет показав десять карток, корисно написати: «Я підібрав 4 варіанти подарунків для колеги в бюджеті до $50. Серед них є горнятко з індивідуальним принтом, настільна рослина, набір доброї кави та стильний зошит».
• Потім він пропонує наступні кроки. Тут допомагають заздалегідь продумані follow‑up‑фрази: «Хочете побачити дешевші варіанти?», «Звузити вибір за інтересами?», «Показати лише ті, що доступні у вашому регіоні?». Саме ці фрази ви можете використовувати в sendFollowUpMessage у віджеті, а також рекомендувати моделі в system‑prompt.
• І нарешті, якщо користувач явно завершує сценарій («Дякую, цього достатньо»), асистент акуратно «закриває» тему: визнає, що завдання виконано, і пропонує допомогти ще з чимось.

Діаграма потоку: запит → віджет → follow‑up

Для наочності можна уявити поведінку асистента як простий автомат станів.

flowchart TD
    U[Користувач ставить задачу] --> G[GPT вирішує: запускати App?]
    G -->|Так| A[Анонсує запуск App]
    A --> W[Віджет GiftGenius підбирає варіанти]
    W --> S[Асистент резюмує результат]
    S --> F[Асистент пропонує follow-up варіанти]
    F -->|Користувач обирає дію| G
    G -->|Ні, не запускати App| T[Текстова відповідь без UI]
    F -->|"Користувач каже \"Дякую\""| E[Асистент завершує сценарій і пропонує іншу допомогу]

Такий потік ми фактично описуємо словами в system‑prompt.

Приклад коду: follow‑up з віджета

З боку UI ви вже вмієте надсилати follow‑up‑повідомлення. Для повноти — простий приклад компонента, який після натискання кнопки просить модель «розширити бюджет»:

// components/ExpandBudgetButton.tsx
export function ExpandBudgetButton() {
    const onClick = () => {
        window.openai?.sendFollowUpMessage(
            "Покажи варіанти з трохи більшим бюджетом"
        );
    };

    return <button onClick={onClick}>Хочу дорожчі варіанти</button>;
}

Тепер ми додамо в system‑prompt текст, який підкаже моделі, як обробляти такі follow‑up‑повідомлення.

// продовження systemPrompt
const followUps = `
# Поведінка після запуску застосунку
Після того як віджет показав список подарунків,
коротко опиши результат текстом.

Далі запропонуй 1–3 зрозумілі наступні кроки
(наприклад: показати дешевші, змінити бюджет, змінити категорію).
Якщо віджет надсилає follow-up‑повідомлення,
використовуй його як підказку для наступного кроку.
`;

З технічного погляду це звичайний рядок. А з погляду UX — основа передбачуваного сценарію.

5. Повага до намірів користувача

Усе, що ми обговорювали вище, — це ваші продуктові очікування від поведінки App. UX‑інструкції працюватимуть погано, якщо модель не вміє «слухати» користувача. Навіть ідеально спроєктований App має поступатися, якщо людина прямо просить не змінювати формат взаємодії.

Є кілька характерних ситуацій.

• Якщо користувач прямо каже, що не хоче запускати застосунки («Жодного UI, просто поясни, що мені купити»), асистент має сприймати це як жорстке обмеження й не намагатися його обійти. Можна ввічливо сказати: «Гаразд, відповідатиму лише текстом», — і далі справді тримати слово.
• Якщо користувач хвилюється, що щось запуститься автоматично, корисно дати йому відчуття контролю. Наприклад: «Я можу відкрити застосунок для підбору подарунків, але якщо вам зручніше, можемо обговорити варіанти просто в чаті. Як вам краще?» Тут ви прямо даєте вибір.
• Якщо користувач пише «Я з телефона, не запускай складні форми», це теж частина контексту. Асистент має врахувати це й, наприклад, обмежитися коротким списком ідей та уточнювальних запитань.

Вбудовуємо повагу в контракт

Усе це можна компактно відобразити в system‑prompt:

export const respectBlock = `
# Пріоритет намірів користувача
Завжди враховуй явні прохання користувача
щодо формату спілкування.

Якщо він просить не запускати застосунки чи віджети,
не пропонуй і не запускай GiftGenius,
навіть якщо це допомогло б розв’язати задачу.
Натомість допомагай текстом.
`;

Так ви чітко фіксуєте, «хто головний» у діалозі. І, до речі, це не ваша гордість за красивий UI, а жива людина по той бік екрана.

6. Як оформлювати UX‑інструкції всередині system‑prompt і в документації

Ми вже накидали доволі багато правил поведінки — від анонсу App до follow‑up‑повідомлень і поваги до формату діалогу. Тепер важливо не лише що ми говоримо моделі, а й як саме це оформлено в system‑prompt і документації.

System‑prompt у реальному App швидко розростається. Якщо писати його як суцільний літературний текст, уже за тиждень там ніхто нічого не знайде. Тому ставтеся до нього як до технічної специфікації або README: структуруйте.

Гарна практика — розбити промпт на кілька логічних секцій із заголовками. Наприклад: «Роль і зона відповідальності», «Коли використовувати App», «Коли не використовувати App», «Діалог і UX», «Безпека й обмеження». Усередині кожної секції пишіть простими, однозначними фразами.

Ще краще — винести system‑prompt в окремий файл поруч із кодом, а не вставляти його в рядковий літерал посеред компонента. Тоді його буде простіше переглядати, порівнювати зміни та обговорювати з продуктовими менеджерами або юристами.

Приклад організації system‑prompt у коді

Один із варіантів — зберігати частини промпта в окремих рядках і збирати в одне ціле:

// app/prompt/role.ts
export const roleSection = `
# Роль
Ти — ChatGPT App GiftGenius.
Допомагаєш користувачу підібрати подарунки під задачу та бюджет.
`;

// app/prompt/ux.ts
export const uxSection = `
# Діалог і UX
Перед запуском віджета GiftGenius
коротко поясни, що зараз відкриється застосунок із картками подарунків.
Не запускай застосунок для загальних або теоретичних питань,
якщо користувач явно не просить підбору.
Після роботи віджета резюмуй результат текстом
і запропонуй 1–3 наступні кроки.
`;

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

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

Таке розбиття допомагає думати про інструкції як про окремі модулі: UX‑частина, безпека, робота з інструментами тощо. Це особливо знадобиться, коли ви додаватимете нові можливості й доведеться узгоджувати поведінку з кількома командами.

Крім того, документацію щодо App (внутрішній README, Confluence, Notion) має сенс синхронізувати з цими секціями. Там ви можете людською мовою описати, чому саме так анонсуєте App і чому не запускаєте його для пробних запитів. Окремо зафіксуйте, якими мають бути follow‑up‑репліки. Тоді нові люди в команді не намагатимуться «полагодити» промпт, не розуміючи, що саме ви робили.

7. Практика: переписуємо UX‑частину для нашого GiftGenius

Зберемо все разом в один більш‑менш цілісний приклад system‑prompt. Припустімо, у нас був дуже скромний system‑prompt:

export const systemPrompt = `
Ти — застосунок GiftGenius.
Підбирай подарунки користувачу.
`;

Такий текст нічого не каже про те, коли запускати App, як його анонсувати і що робити після віджета. Додамо UX‑інструкції крок за кроком.

Спочатку чітко позначимо зону відповідальності та формат роботи:

const role = `
# Роль
Ти — ChatGPT App GiftGenius.
Твоє завдання — допомагати користувачу підібрати 3–7 релевантних подарунків
під заданий бюджет, отримувача та привід.
Ти можеш використовувати віджет GiftGenius для візуального підбору.
`;

Далі опишемо, як анонсувати запуск:

const announce = `
# Анонс застосунку
Якщо вважаєш, що віджет GiftGenius допоможе краще,
спочатку поясни в одному‑двох реченнях,
що зараз відкриється застосунок із картками подарунків
і що користувач зможе їх переглянути та відфільтрувати.
Лише після цього запускай застосунок.
`;

Додамо правила, коли не запускати App:

const noApp = `
# Коли не використовувати застосунок
Якщо користувач питає лише про те, що вміє сервіс,
або хоче загальну теоретичну інформацію про подарунки,
відповідай текстом і не запускай GiftGenius.

Якщо запит не стосується подарунків (наприклад, про резюме або код),
відповідай як звичайний ChatGPT і не пропонуй застосунок.

Якщо користувач просить не використовувати застосунки,
вважай це обов’язковим обмеженням.
`;

І завершимо поведінкою після використання віджета:

const afterWidget = `
# Поведінка після віджета
Після того як віджет показав варіанти подарунків,
коротко опиши результат своїми словами.
Запропонуй користувачу 1–3 наступні кроки
(наприклад: змінити бюджет, фільтрувати за інтересами,
показати лише дешевші варіанти).

Якщо віджет надіслав follow-up‑повідомлення,
використовуй його як основний сигнал для наступного кроку.
`;

Фінальний system‑prompt може виглядати так:

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

Це вже схоже на специфікацію поведінки, а не на «побажання всесвіту». У наступних модулях ви доповните цей контракт інструкціями про безпеку, галюцинації, комерцію та інші радощі дорослого життя App, але UX‑частина вже закладена як фундамент.

8. Типові помилки під час налаштування UX‑інструкцій

Помилка № 1: «App завжди кращий за текст».
Іноді розробники так пишаються своїм віджетом, що вимагають від моделі викликати його за будь‑якої нагоди. У результаті користувач отримує App навіть там, де хотів просто запитати: «Що це взагалі таке?». Модель стає навʼязливою, і люди починають ігнорувати застосунок. Правильний підхід — явно прописувати сценарії, коли App не потрібен, і поважати такі випадки.

Помилка № 2: відсутність явного анонсу перед запуском App.
Якщо асистент мовчки запускає віджет, користувач не розуміє, звідки взявся блок UI і що з ним робити. Настанови OpenAI та практичний досвід показують: одне‑два речення «зараз відкрию застосунок, який зробить X» різко покращують UX і зменшують розгубленість.

Помилка № 3: надто агресивна повторна пропозиція App.
Буває, що App після кожної відповіді знову пропонує запустити віджет: «Хочете ще раз відкрити застосунок? А зараз? А тепер?». Це швидко перетворюється на спам. Краще зафіксувати в інструкціях, що після першого використання App потрібно зважати на контекст: пропонувати його повторно лише якщо користувач явно змінює параметри завдання або сам просить «показати ще».

Помилка № 4: ігнорування явної відмови від застосунків.
Фрази на кшталт «тільки без застосунків, будь ласка» або «мені незручно із телефона працювати з формами» мають сприйматися як жорсткі обмеження. Якщо модель продовжує навʼязувати App, користувач втрачає довіру і до асистента, і до вашого продукту. У system‑prompt це легко фіксується двома‑трьома реченнями, але багато хто забуває це зробити.

Помилка № 5: відсутність резюме та follow‑up‑повідомлень після віджета.
Іноді віджет чесно показує варіанти, а асистент після цього мовчить. Користувач бачить UI, але не розуміє, що далі. Жодного тексту, жодного запитання, жодних кнопок із популярними діями. Такий сценарій виглядає незавершеним і ламає звʼязність діалогу. Завжди прописуйте в інструкціях, що після віджета має бути короткий текстовий підсумок і 1–3 зрозумілі наступні кроки.

Помилка № 6: змішування продуктового UX і «загального стилю ChatGPT» в одному абзаці.
Іноді system‑prompt перетворюється на довгий художній текст: «Будь дружнім, використовуй емодзі, іноді жартуй, якщо доречно. І так, можливо, колись запускай App». У такому тексті дуже складно помітити реальні UX‑правила. Краще виділяти окремі секції з чіткими заголовками: «Роль», «Діалог і UX», «Коли використовувати App», «Коли не використовувати App». Це допомагає і моделі, і людям, які працюватимуть із цим промптом після вас.