Wytyczne UX od OpenAI: kiedy pokazywać App i jak nie „przejmować” dialogu

1. Chat‑first: ChatGPT — to przede wszystkim czat, a dopiero potem aplikacje

W ciągu pierwszych 6 modułów omówiliśmy wszystkie aspekty aplikacji: od UI i MCP po debug i deploy. Teraz przejdziemy jeszcze raz po wszystkich stronach, tylko głębiej. Nie sądziliście chyba, że to będzie takie proste, prawda?

Zaczniemy od UX, a dokładniej od oficjalnych wymagań UI i wytycznych UX. Chcecie, żeby wasza aplikacja przeszła review, prawda? Świetnie, to zacznijmy od najciekawszego: główna zmiana w myśleniu, której potrzebuje front‑endowiec przyzwyczajony do SPA/Next.js: ChatGPT — to przede wszystkim interfejs dialogowy, a App — gość wewnątrz tego dialogu. Nie odwrotnie.

OpenAI w swoich wytycznych formułuje to tak: aplikacje rozszerzają to, co może zrobić użytkownik, nie przerywając przepływu rozmowy. Widżet to nie nowa karta przeglądarki, tylko zgrabna wstawka w czat, która daje strukturę tam, gdzie sam tekst zaczyna być niewystarczający.

Najłatwiej zapamiętać przez podział ról.

Role GPT i App

Wewnątrz ChatGPT są dwie „postacie”:

GPT pozostaje głównym narratorem. Słowami wyjaśnia, co zaraz się wydarzy, dlaczego proponuje App, co oznaczają przyciski i podsumowuje wynik pracy widżetu. App z kolei koncentruje się na części wizualnej i działaniach: wybór opcji, ustawianie filtrów, przechodzenie kolejnych kroków kreatora.

Bardzo ważna zasada, którą warto powtarzać jak mantrę: wszystkie ważne decyzje muszą być jasno wypowiedziane w tekstowej odpowiedzi GPT, nawet jeśli użytkownik klika w UI. Użytkownik nie ma obowiązku czytać każdej linijki w interfejsie widżetu — kluczowe konsekwencje (np. „złożyliśmy zamówienie” lub „wybrałeś właśnie te parametry”) muszą być wypowiedziane w czacie.

2. Kiedy App jest naprawdę potrzebny: kryteria wyświetlania

Od strony technicznej możecie wywoływać widżet przy każdej wiadomości. Od strony UX — to jak otwieranie pełnoekranowego dialogu przy każdym wprowadzeniu znaku do input. Działa — owszem. Da się z tym żyć — niekoniecznie.

OpenAI i Apps SDK proponują prostą zasadę: App ma sens wtedy, gdy z nim myśli się łatwiej niż samym tekstem.

Zapytania ze strukturą i powtarzalnym scenariuszem

App świetnie sprawdza się, gdy samo zapytanie użytkownika sugeruje strukturę:

• „Dobierz 5 propozycji prezentów dla kolegi do $50”.
• „Porównaj te trzy plany taryfowe”.
• „Ułóż trasę na 3 dni po Tokio”.
• „Pokaż moją listę zadań na tydzień i pomóż ustawić priorytety”.

We wszystkich tych przypadkach są wyraźne byty (prezenty, taryfy, dni trasy, zadania), którymi trzeba manipulować, i kroki: wybrać, przefiltrować, porównać, potwierdzić. Tutaj UI z kartami, checkboxami, filtrami jest uzasadniony i wręcz ratuje sytuację.

Przykłady dla GiftGenius

Weźmy naszego ulubionego bohatera, GiftGenius. Oto typowe zapytanie:

Trzeba dobrać prezenty dla 10 gości na wesele, z różnymi budżetami i zainteresowaniami.

Czystym tekstem GPT może wypisać 10 osobnych list, ale czytanie tego będzie bolesne. O wiele przyjemniej:

• pokazać tabelę gości, budżetów i zainteresowań,
• dać możliwość filtrowania „taniej/drożej”,
• wyświetlić zestaw kart dla każdego gościa.

Tutaj App jest praktycznie obowiązkowy: zbyt wiele bytów i parametrów, by utrzymać to tylko tekstem.

W odróżnieniu od tego:

Co podarować bratu za 5000 ₽?

To jednorazowe, niewielkie pytanie. GPT może odpowiedzieć tekstem 3–5 pomysłami i dopiero gdy użytkownik poprosi „pokaż opcje, gdzie mogę przefiltrować po hobby i wieku”, można płynnie przejść do App.

Mini‑heurystyka

Warto mieć w głowie prostą tabelę:

Szczegółowo o inline i fullscreen porozmawiamy w kolejnych wykładach, ale już teraz widać: App to narzędzie do zadań strukturalnych, wieloetapowych, a nie do każdego „jest mi smutno, co robić?”.

3. Kiedy App przeszkadza: tryb „porozmawiać” i rozważania

Zobaczyliśmy, kiedy App realnie ułatwia życie i wspiera strukturę dialogu. Ale jest i druga strona medalu: bywają sytuacje, w których każdy UI tylko przeszkadza.

Nadmierne rozmowy o „rysowaniu UI” często prowadzą do odruchu: „o, użytkownik o coś zapytał — pora uruchomić widżet”. To ten moment, w którym w recenzji Store możecie dostać minusa za UX.

Jest cała klasa zapytań, w których App najczęściej szkodzi:

1. Użytkownik w trybie „porozmawiać”. To filozoficzne rozważania, osobiste pytania, dylematy zawodowe, rozmowy terapeutyczne. W takich scenariuszach użytkownik oczekuje rozmowy tekstowej, pytań doprecyzowujących, czasem empatii. Wstawka kart i filtrów będzie tu odczuwana jak baner spamowy.
2. Pytania wprowadzające o usługę. Jeśli ktoś pisze „Opowiedz, co potrafi GiftGenius?”, chce przeglądu, a nie od razu UI. Tutaj GPT lepiej najpierw krótko wyjaśni przeznaczenie App, ewentualnie poda przykłady zapytań, i dopiero potem delikatnie zaproponuje wypróbowanie widżetu.
3. Ogólne pytania teoretyczne. „Jak wybierać prezenty dla introwertyków?” albo „Jak działa system lojalności w sklepach?” — to scenariusz edukacyjny, a nie transakcyjny. GPT może dać dobrą odpowiedź tekstową, a na końcu nienachalnie dodać: „Jeśli chcesz, mogę otworzyć GiftGenius i dobrać kilka konkretnych opcji”.

Wszędzie tam, gdzie UI nie daje nowej wartości, a tylko dubluje tekst, lepiej pozostać w czacie. To właśnie szacunek dla intencji użytkownika, o którym tak lubią pisać guru UX.

4. Jak proponować App: auto‑launch kontra „humble handoff”

Nawet jeśli jesteście pewni, że App jest na miejscu, pytanie „jak go uruchomić” pozostaje otwarte. Gruba opcja: widżet niespodziewanie otwiera się na pełnym ekranie bez ostrzeżenia. Normalna opcja: GPT najpierw wyjaśnia słowami, co się wydarzy, i pyta o zgodę albo przynajmniej informuje.

W dokumentacji UX ChatGPT Apps wyróżnia się dwa wzorce: auto‑launch oraz suggestion (humble handoff).

Auto‑launch: gdy użytkownik poprosił wprost

Auto‑launch jest na miejscu, gdy użytkownik wyraził wyraźną intencję:

Uruchom GiftGenius.
Otwórz ustawienia GiftGenius.
Pokaż mój koszyk prezentów w GiftGenius.

Tu zasady są proste:

1. GPT krótko pisze coś w stylu: „Otwieram GiftGenius…”.
2. Model natychmiast wywołuje narzędzie/widżet.

Dialog może wyglądać tak:

Użytkownik: Uruchom GiftGenius, chcę dobrać prezent dla przyjaciela.
GPT: Otwieram pomocnika GiftGenius do doboru prezentów.
[Pojawia się widżet GiftGenius inline lub fullscreen]

Autostart bez zbędnych doprecyzowań jest uzasadniony, bo użytkownik sam poprosił o „otwarcie”.

Suggestion (humble handoff): gdy intencja jest niejawna

W wielu przypadkach użytkownik w ogóle nie zna waszej aplikacji. Pisze:

Trzeba coś wymyślić dla kolegi na urodziny, budżet niewielki.

Tutaj właściwy wzorzec to:

1. GPT analizuje zapytanie i rozumie, że App może pomóc.
2. GPT zadaje 1–2 pytania doprecyzowujące lub od razu proponuje App słowami.
3. Dopiero po zgodzie lub wyraźnej sugestii — uruchamia widżet.

Przykład:

Użytkownik: Trzeba coś wymyślić dla kolegi na urodziny, budżet niewielki.
GPT: Mogę podsunąć pomysły sam albo otworzyć aplikację GiftGenius, gdzie dobierzemy opcje według budżetu i zainteresowań. Wolisz po prostu porady czy chcesz spróbować aplikacji?
Użytkownik: Daj aplikację.
GPT: Otwieram GiftGenius, aby dobrać opcje prezentów.
[Pojawia się widżet]

Takie podejście podkreśla: inicjatywa wciąż należy do użytkownika, a App — to opcja, a nie narzucony baner. Dobrze współgra z zasadą „Respect user’s intent” z wytycznych UX.

Mini‑przykład „klasyfikatora intencji” w TypeScript

Załóżmy, że po stronie waszego backendu wstępnie klasyfikujecie zapytanie użytkownika (nie mylić z samym GPT — to logika pomocnicza):

// Uproszczony typ intencji użytkownika
type UserIntent = 'chat' | 'ask_gift_advice' | 'open_app';

// Jaki wyzwalacz dla App chcemy użyć
type AppTrigger = 'auto' | 'suggest' | 'avoid';

function decideAppTrigger(intent: UserIntent): AppTrigger {
  if (intent === 'open_app') return 'auto';      // "uruchom GiftGenius"
  if (intent === 'ask_gift_advice') return 'suggest'; // niejawne zapytanie
  return 'avoid';                                // zwykły czat, bez App
}

Ta logika sama w sobie nie uruchamia widżetu — to raczej sposób na sformalizowanie podejścia UX. Potem te reguły przenosicie do system‑prompt i opisów App, aby model zachowywał się w tym samym duchu.

5. Jak nie „przejmować” dialogu: dobre i złe wzorce

OpenAI w dokumentacji i artykułach o UX‑designie dla ChatGPT Apps dość jasno wskazuje, czego nie robić: nie „kraść” rozmowy. Czyli nie zamieniać czatu w kanał promowania waszego interfejsu.

Antywzorce

Najbardziej bolesny — „widżet‑niespodzianka”. To sytuacja, gdy użytkownik prowadzi głęboki dialog, a nagle cały ekran zajmuje pełnoekranowa aplikacja, o którą nie prosił. Kontekst się gubi, poczucie kontroli również.

Inny częsty grzech — używać App jako reklamy. Na przykład użytkownik zadaje pytanie teoretyczne, a model odpowiada: „Najpierw otworzę nasz superwidżet, tam wszystko jest opisane” i pokazuje UI, gdzie połowa to teksty marketingowe. Oficjalne wytyczne wprost nazywają takie scenariusze „poor use cases”.

Trzeci antywzorzec — częste, niepotrzebne przełączanie się między UI a tekstem. Jeśli przy każdym małym doprecyzowaniu uruchamiać i zamykać App, dialog zaczyna migać jak girlanda. Użytkownik, zwłaszcza na urządzeniu mobilnym, szybko się zmęczy.

Dobre praktyki

We wszystkich scenariuszach, w których mimo wszystko otwieracie App, trzymajcie się trzech prostych zasad.

Po pierwsze, uprzedzajcie. Niech GPT jasno powie, że zamierza otworzyć aplikację i po co. Na przykład: „Za chwilę otworzę pomocnika GiftGenius, aby pokazać opcje w formie kart”. To 1–2 linijki, ale całkowicie zmieniają odczucie przejścia.

Po drugie, wyjaśniajcie, co robić w UI. Nie wszyscy użytkownicy są przyzwyczajeni do nowego interfejsu. GPT może dodać tekst: „Na dole zobaczysz karty prezentów, możesz przełączać strony i kliknąć „Więcej szczegółów” przy dowolnej opcji”. Jeśli w widżecie jest coś nietypowego (np. „Pokaż jeszcze N” lub niestandardowe filtry), lepiej powiedzieć to słowami.

Po trzecie, podsumowujcie wynik tekstem. Po tym, jak App coś zrobi (dobrał, policzył, wysłał), GPT powinien krótko opowiedzieć: „Dobrałem 3 propozycje prezentów. Dwie pierwsze mieszczą się w budżecie do $50, trzecia jest nieco droższa, ale z szybką dostawą. Chcesz zawęzić wybór?” To szczególnie ważne na urządzeniach mobilnych i w scenariuszach głosowych: użytkownik może nie patrzeć na UI, ale usłyszy tekstowe podsumowanie.

6. Rola system‑prompt i opisów App w zarządzaniu UX

Wcześniej widzieliście, jak system‑prompt określa „osobowość” App i jak model korzysta z narzędzi. Teraz dodajemy tam reguły UX: kiedy proponować App, jak go zapowiadać, kiedy go unikać.

Co wpisać w system‑prompt

Dla GiftGenius system‑prompt może zawierać sekcję „Dialog i UX”. W dokumentacji i artykułach zaleca się opisywać to strukturalnie, oddzielnymi zasadami.

Przykładowy fragment (pseudokod, ale bardzo blisko realiów):

### Dialog i UX

1. Jeśli użytkownik podaje warunki doboru prezentu (dla kogo, budżet, okazja),
   najpierw zadaj 1–2 pytania doprecyzowujące tekstem.
2. Po doprecyzowaniu zaproponuj otwarcie App GiftGenius:
   "Mogę otworzyć pomocnika GiftGenius, aby pokazać opcje prezentów. Otworzyć?"
3. Jeśli użytkownik wyraźnie prosi "uruchom GiftGenius" lub "pokaż listę prezentów",
   odpowiedz "Otwieram GiftGenius..." i od razu wywołaj App bez dodatkowych pytań.
4. Jeśli użytkownik prosi o teorię lub ogólne porady (np. "jak wybierać prezenty"),
   odpowiadaj tekstem i nie otwieraj App, dopóki sam o to nie poprosi.
5. Jeśli użytkownik mówi "nie otwieraj aplikacji" albo "po prostu odpowiedz tekstem",
   w dalszej części dialogu nie proponuj App.
6. Po pracy App zawsze podsumuj wynik tekstem (krótko).

Tu w skrócie zapisaliśmy wszystkie nasze zasady UX: chat‑first, szacunek dla odmowy użytkownika, różnica między auto‑launch i suggest, obowiązkowe podsumowanie tekstowe.

Jak pomóc sobie konfiguracjami TypeScript

W prawdziwych projektach wygodnie trzymać część tych reguł w ustrukturyzowanej formie (żeby później nie szukać tekstu w promptach ręcznie). Na przykład można dodać prostą konfigurację:

// Umowny typ konfiguracji wyzwalaczy UX dla 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' },
];

Tę konfigurację sama w sobie modelu nie udostępniacie — jest wam potrzebna, jako deweloperom, by w jednym miejscu zebrać ustalenia produkt/design, a potem starannie przenieść je do system‑prompt, opisów App i dokumentacji.

7. Przykład: jak GPT anonsuje GiftGenius i nie przejmuje rozmowy

Połączmy wszystko z naszą aplikacją. Załóżmy, że użytkownik pisze po raz pierwszy w czacie:

Szukam prezentu dla kolegi, mniej więcej do 3000 ₽, lubi gry planszowe.

Dobry wynik modelu (z uwzględnieniem naszego system‑prompt) może wyglądać tak:

Rozumiem! Ustalmy kilka szczegółów i dobierzmy pomysły.

Powiedz, ile ma mniej więcej lat i czy to raczej formalny prezent, czy od bliskiego przyjaciela?

(Po Twojej odpowiedzi mogę otworzyć pomocnika GiftGenius, gdzie zobaczymy opcje w formie kart.)

Po doprecyzowaniu GPT pisze:

Świetnie, mam wystarczająco informacji.

Teraz otworzę aplikację GiftGenius — pokażę Ci kilka opcji prezentów w formie kart, będziesz mógł/mogła zobaczyć szczegóły i zawęzić wybór według budżetu oraz typu gry.

I dopiero potem — uruchomienie App. Ani jednej „niespodzianki” — wszystko wyjaśnione słowami.

Niewielki komponent React „zapowiedzi App” wewnątrz widżetu

Od strony kodu widżet zwykle po prostu się renderuje, gdy został wywołany. Ale możecie zaszyć w jego UI filozofię „nie przejmować” kontekstu, nawet jeśli jest już otwarty.

Na przykład pierwszy ekran GiftGenius może być bardzo prosty:

// app/components/GiftGeniusIntro.tsx
export function GiftGeniusIntro() {
  return (
    <section style={{ padding: 16 }}>
      <h2 style={{ fontSize: 20, marginBottom: 8 }}>
        Dobór prezentów z GiftGenius
      </h2>
      <p style={{ marginBottom: 12 }}>
        Pokażę kilka opcji w formie kart. Możesz wybrać te, które Ci się spodobają,
        a ChatGPT wyjaśni plusy i minusy.
      </p>
      <p style={{ fontSize: 12, color: '#666' }}>
        W każdej chwili możesz wrócić do zwykłego czatu i kontynuować rozmowę.
      </p>
    </section>
  );
}

Ten komponent nie robi „mocnych” rzeczy technicznie, ale z punktu widzenia UX jest ważny: przypomina, że czat nigdzie nie zniknął, a rola GPT pozostaje centralna.

Później właśnie z tego ekranu intro przejdziecie do kart prezentów, kreatorów itd., ale to już temat kolejnych wykładów.

8. Praktyka i ćwiczenia

Powyżej zebraliśmy zestaw zasad — chat‑first, szacunek dla intencji użytkownika, różnica między auto‑launch a propozycją App. Aby utrwalić podejście „kiedy i jak pokazywać App”, warto przemyśleć realne zapytania i jasno rozdzielić, gdzie App jest potrzebny, a gdzie — nie. W zadaniu domowym można zrobić dwa małe ćwiczenia.

Najpierw weźcie GiftGenius i wymyślcie 5–7 zapytań użytkowników. Dla każdego odpowiedzcie sobie szczerze:

• czy warto tutaj od razu zaproponować otwarcie App;
• czy lepiej tylko wspomnieć App jako opcję;
• czy może najlepiej w ogóle nie wiązać odpowiedzi z App.

Na przykład:

1. „Podaruj coś żonie na rocznicę, budżet do $1000” — najpewniej najpierw kilka pytań doprecyzowujących tekstem, potem propozycja otwarcia App.
2. „Jak oryginalnie zapakować prezent?” — czysto teoretyczne pytanie, można obyć się bez App.
3. „Uruchom GiftGenius, chcę wybrać prezenty dla całego zespołu” — bezpośredni auto‑launch.

Drugie ćwiczenie — tekst zapowiedzi uruchomienia App. Spróbujcie napisać 1–2 krótkie frazy, którymi GPT będzie wyjaśniał użytkownikowi przejście do App. Porównajcie różne tony: bardziej formalny („Otwieram aplikację GiftGenius…”) i bardziej przyjazny („Spróbujmy pomocnika GiftGenius — tak będzie łatwiej porównać opcje”).

Dzięki temu nauczysz się myśleć nie tylko jak deweloper, ale i jak autor dialogu.

9. Typowe błędy w UX „kiedy pokazywać App”

Błąd nr 1: Pokazywać App przy każdym wspomnieniu tematu.
Częsta skrajność: jeśli App dotyczy prezentów, każde słowo „prezent” w dialogu od razu wyzwala widżet. Użytkownik pyta „jak nie zawalić prezentu dla szefa”, a zamiast żywej porady dostaje UI z kartami. To jest odbierane jak reklama i ignoruje rzeczywistą intencję użytkownika, co wprost przeczy oficjalnym wytycznym UX i zasadzie „Respect user’s intent”.

Błąd nr 2: Fullscreen bez ostrzeżenia.
„Widżet‑niespodzianka”, który nagle zajmuje cały ekran, to sprawdzony sposób na popsucie wrażenia. Szczególnie źle wygląda to w środku długiej rozmowy, gdy użytkownik nie spodziewał się ostrego przejścia z tekstu do UI. Według wytycznych OpenAI takie scenariusze są złą praktyką; zawsze trzeba zapowiadać przejście i w miarę możliwości pytać o zgodę.

Błąd nr 3: UI zamiast odpowiedzi.
Czasem autorzy App myślą: „Po co odpowiadać tekstem, skoro mamy ładny interfejs!” W efekcie GPT prawie nic nie mówi, a wszystkie „odpowiedzi” są schowane w widżecie. Użytkownik, zwłaszcza w trybie głosowym lub mobilnym, może nawet nie zauważyć ważnych szczegółów. Właściwe podejście — UI uzupełnia odpowiedź, a nie ją zastępuje: App pokazuje detale i opcje, GPT wyjaśnia, co one znaczą.

Błąd nr 4: Ignorowanie odmowy użytkownika wobec App.
Jeśli ktoś jasno powiedział „nie otwieraj aplikacji” albo „odpowiedz po prostu tekstem”, App powinien przyjąć to jako twardą zasadę do końca dialogu. Ciągłe proponowanie App co dwa komunikaty to jak natrętny pop‑up „oceń nasz serwis”. Takie rzeczy pogarszają UX i mogą wpłynąć na review w Store. W system‑prompt trzeba jasno zaszyć szacunek dla odmowy.

Błąd nr 5: Brak rozróżnienia między auto‑launch a „propozycją”.
Gdy deweloper nie rozróżnia intencji jawnych i niejawnych, albo nigdy nie uruchamia App, nawet gdy użytkownik prosi wprost, albo zawsze uruchamia, nawet gdy użytkownik tylko rzucił „może kiedyś spróbuję waszej App”. Stąd i auto‑otwieranie widżetu „bo padło podobne słowo”. Formalizacja wyzwalaczy (auto / suggest / avoid) i przemyślana logika w system‑prompt pomagają uniknąć tego chaosu.

Błąd nr 6: Całkowity brak zasad UX w system‑prompt.
Czasem wszystkie decyzje UX są tylko „w głowach zespołu”, a system‑prompt ogranicza się do „Jesteś asystentem GiftGenius, pomagaj z prezentami”. W efekcie model raz proponuje App, raz o niej zapomina, raz otwiera w nieodpowiednim momencie. Zapisane, ustrukturyzowane zasady UX w system‑prompt i dokumentacji to równie ważny artefakt, jak JSON‑schemat narzędzi.

Błąd nr 7: Próba „dokręcenia UX później”.
Popularne podejście — najpierw „żeby działało”, a dopiero potem kiedyś pomyśleć o UX. W przypadku ChatGPT Apps prowadzi to do sytuacji, w której już przywiązaliście się do określonych wzorców wywoływania narzędzi, a zmiana system‑prompt i zachowania GPT jest trudniejsza. Lepiej od razu założyć choćby podstawowe wytyczne UX: chat‑first, szacunek dla odmowy, jasne kryteria pokazywania App i brak „widżetów‑niespodzianek”. Wtedy całe dalsze rozwijanie (wzorce inline, fullscreen, voice) będzie budowane na zdrowym fundamencie.