Instrukcje dotyczące UX: zapowiedź App, rezygnacja z App i zachowanie w dialogu

1. Po co w ogóle zarządzać UX przez instrukcje

Z punktu widzenia ChatGPT wasz App to tylko dodatkowe narzędzia i widżety. Dla użytkownika to jednak osobny interfejs, który niespodziewanie pojawia się w środku rozmowy. Jeśli nie sterujemy zachowaniem modelu, można otrzymać dwa skrajne scenariusze.

W jednym przypadku GPT ignoruje App i próbuje „załatwić wszystko słowami”. Użytkownik prosi o dobór prezentu, a model zamiast uruchomić GiftGenius wypisuje długie tekstowe eseje z rekomendacjami „od siebie”. Czasem to nie jest złe, ale App nie został napisany po to, by kurzył się na półce.

W drugim przypadku GPT, przeciwnie, nadużywa App. Na każde kichnięcie w stylu „Co potrafi wasza usługa?” uruchamia widżet, renderuje niejasny formularz, użytkownik się płoszy i zamyka całe to „piękno”. Z punktu widzenia UX wychodzi natrętnie.

Dlatego logika jest prosta: zachowanie trzeba ustalić explicite, tak jak utrwalacie schemę JSON narzędzia czy propsy komponentu React. System‑prompt (i towarzyszące instrukcje) to tutaj wasz „protokół UX”. Opisujecie w nim, kiedy i jak asystent:

• zapowiada uruchomienie App;
• świadomie nie uruchamia App, tylko odpowiada tekstem;
• zachowuje się po tym, jak widżet już pokazał wynik;
• szanuje prośby użytkownika „bez aplikacji”.

To nie jest kwestia marketingu ani stylu rozmowy. To realnie wpływa na to, jak często wasz App będzie wywoływany i jak komfortowo będzie się czuł użytkownik.

Dalej omówimy krok po kroku: jak asystent powinien zapowiadać uruchomienie App, w jakich przypadkach lepiej świadomie nie proponować widżetu, jak zachowywać się po tym, gdy aplikacja zakończy pracę, jak szanować wyraźne prośby użytkownika dotyczące formatu dialogu oraz jak zgrabnie ująć te wszystkie zasady w system‑prompt.

2. Zapowiedź App: jak model powinien „uprzedzać” o widżecie

Gdy ChatGPT postanawia użyć App, interfejs się zmienia: w czacie pojawia się karta widżetu, czasem w trybie pełnoekranowym, pojawiają się przyciski i inne elementy UI. Jeśli asystent po prostu bez wyjaśnień pokaże widżet, użytkownik może w ogóle nie zrozumieć, co się stało i skąd wziął się ten blok.

Dlatego dobrym tonem jest najpierw tekstowo wyjaśnić, co zaraz nastąpi, i dopiero potem uruchamiać App. To przypomina sytuację, gdy przeglądarka pyta: „Otworzyć nowe okno?” albo aplikacja mobilna ostrzega: „Zaraz poprosimy o zgodę na dostęp do aparatu”.

Typy zapowiedzi

Można umownie wyróżnić trzy style zapowiedzi.

Pierwszy — delikatna propozycja. Asystent mówi coś w rodzaju: „Mogę otworzyć dla ciebie aplikację GiftGenius, która dobierze prezenty według twoich parametrów. Otworzyć ją?” i czeka na odpowiedź „tak/nie”. To dobrze działa w scenariuszach, w których użytkownik dopiero poznaje usługę lub może być wrażliwy na zmianę interfejsu.

Drugi — stanowcza rekomendacja. Jeśli wasz App to podstawowy interfejs produktu, możecie pisać: „Teraz uruchomię aplikację GiftGenius i pokażę kilka propozycji prezentów w formie kart.” Asystent nadal może uwzględnić odmowę, ale domyślnie działa bardziej zdecydowanie.

Trzeci — neutralne powiadomienie. W tym przypadku asystent po prostu informuje: „Uruchamiam aplikację GiftGenius do doboru prezentów…”, bez długich wyjaśnień. Taki styl jest adekwatny, gdy użytkownik wiele razy widział już wasz App i oczekuje jego pojawienia się.

Ważne, że wszystkie te warianty można i warto zaszyć w system‑prompt. Model nie wymyśla fraz UX od zera, jeśli wcześniej dostanie szkielet.

Mini‑przykład kodu: sekcja o zapowiedzi w system‑prompt

Wyobraźcie sobie, że w waszym szablonie Next.js jest plik appDefinition.ts, gdzie definiujecie system‑prompt dla App:

// app/appDefinition.ts
export const systemPrompt = `
# Rola
Jesteś ChatGPT App GiftGenius, pomagasz dobierać prezenty.

# Dialog i UX — Zapowiedź aplikacji
Jeśli decydujesz się uruchomić widżet GiftGenius,
najpierw w jednym–dwóch zdaniach wyjaśnij,
że teraz otworzy się aplikacja z selekcją prezentów
i w czym pomoże użytkownikowi.
`;

To jeszcze nie pełnoprawny kontrakt, ale nawet taka mała wstawka znacząco podnosi przewidywalność zachowania.

Kiedy zapowiedź jest szczególnie ważna

Im bardziej złożony macie UI, tym ważniejsze jest z wyprzedzeniem zakomunikować jego uruchomienie. Jeśli widżet pokazuje po prostu trzy karty prezentów — to relatywnie łagodna zmiana kontekstu. Jeśli jednak otwieracie wieloetapowego kreatora z filtrami, budżetem, kategoriami itd., użytkownik powinien rozumieć, czemu dialog nagle zamienił się w „małą aplikację webową w czacie”.

Oficjalne wytyczne UX również podkreślają, że asystent powinien jednoznacznie łączyć tekst i UI, a nie dorzucać widżet do odpowiedzi po cichu.

3. Kiedy świadomie nie proponować App

Najczęstszy błąd na wczesnych etapach rozwoju App — klasyczny efekt „gdy w ręku masz młotek, wszystko wygląda jak gwóźdź”. Skoro mamy ładny GiftGenius, model próbuje wciągać go w każdy dialog. Użytkownik pyta: „A co właściwie potrafi wasza aplikacja?”, a ChatGPT już: „Uruchamiam GiftGenius…”, chociaż człowiek chciał tylko dwa zdania wyjaśnienia.

Aby tego uniknąć, w system‑prompt trzeba opisać sytuacje, kiedy App lepiej nie proponować. Poniżej kilka typowych scenariuszy.

• Po pierwsze, pytania zapoznawcze. Jeśli ktoś pisze coś w rodzaju „Co robi GiftGenius?” albo „Jak działacie?”, instrukcje powinny wymagać, by najpierw krótko odpowiedzieć tekstem, bez uruchamiania UI. Widżet tylko rozprasza.
• Po drugie, zbyt ogólne lub nieostre zapytanie. Użytkownik pisze „Opowiedz o prezentach na Nowy Rok” — to raczej pytanie edukacyjne niż konkretny dobór. Asystent może krótko wyjaśnić ogólne zasady, zadać pytania doprecyzowujące i dopiero gdy pojawią się konkretne parametry (budżet, obdarowywany, kategoria), zaproponować App.
• Po trzecie, zapytania poza domeną App. Jeśli ktoś mówi: „Pomóż napisać CV”, a wasz App jest do prezentów, właściwe zachowanie to uczciwie odpowiedzieć jak zwykły ChatGPT i niczego nie uruchamiać. Czasem można grzecznie wspomnieć, do czego służy App, ale nie trzeba go narzucać, gdy jest ewidentnie nierelewantny.
• Po czwarte, wyraźna odmowa UI. Jeśli użytkownik pisze: „Tylko nie otwieraj żadnych aplikacji, wyjaśnij po prostu tekstem”, model musi się podporządkować, nawet jeśli widzi idealny scenariusz dla App.

Tabela: typ zapytania i zachowanie asystenta

Uzupełniamy system‑prompt zasadami rezygnacji z App

Kontynuujmy ten sam systemPrompt, dodając blok o tym, kiedy App nie uruchamiać:

export const systemPrompt = `
# Rola
Jesteś ChatGPT App GiftGenius, pomagasz dobierać prezenty.

# Kiedy NIE uruchamiać widżetu
Jeśli użytkownik pyta wyłącznie o to, co potrafi usługa,
albo zadaje ogólne teoretyczne pytanie o prezenty,
najpierw odpowiedz tekstem i nie uruchamiaj aplikacji.

Jeśli zapytanie nie dotyczy doboru prezentów,
odpowiadaj jak zwykły ChatGPT i nie proponuj GiftGenius.

Jeśli użytkownik wyraźnie prosi, by nie używać aplikacji,
koniecznie to uszanuj i pracuj tylko w czacie.
`;

Taki tekst przekłada się na konkretne decyzje modelu w sytuacjach granicznych, w których inaczej mógłby „przeciągać w stronę” UI. Ustaliliśmy, kiedy App nie jest potrzebny. Teraz ważne jest opisać stronę przeciwną: co ma robić asystent, gdy widżet już wykonał pracę, a użytkownik widzi wynik.

4. Zachowanie po użyciu App: follow‑up i domknięcie scenariusza

W module o widżecie już widzieliście, jak follow‑up‑wiadomości pomagają kontynuować dialog po tym, jak UI wykonał swoją część. Widżet pokazuje karty, a pod nim asystent pisze coś w stylu: „Znalazłem takie‑a‑takie propozycje prezentów dla współpracownika w budżecie do $50. Chcesz, żebym pokazał tańsze, czy zmienił kategorię?” i proponuje przyciski z popularnymi działaniami.

Teraz naszym zadaniem jest utrwalić to zachowanie w instrukcjach, a nie liczyć na „intuicję” modelu.

Co asystent powinien robić po widżecie

W idealnym scenariuszu dzieje się kilka rzeczy.

• Najpierw asystent krótko streszcza wynik działania App słowami. Nawet jeśli widżet pokazał dziesięć kart, warto napisać: „Dobrałem 4 propozycje prezentów dla współpracownika w budżecie do $50. Są wśród nich kubek z indywidualnym nadrukiem, roślina biurkowa, zestaw dobrej kawy i stylowy notatnik.”
• Następnie proponuje kolejne kroki. Pomagają tu wcześniej przemyślane frazy follow‑up: „Chcesz zobaczyć tańsze opcje?”, „Trzeba zawęzić wybór do zainteresowań?”, „Pokazać tylko te dostępne w twoim regionie?”. Właśnie tych fraz możecie używać w sendFollowUpMessage w widżecie, a także rekomendować modelowi w system‑prompt.
• I wreszcie, jeśli użytkownik wyraźnie kończy scenariusz („Dziękuję, to wystarczy”), asystent delikatnie „zamyka” temat: potwierdza, że zadanie zostało rozwiązane, i proponuje pomoc w czymś innym.

Diagram przepływu: pytanie → widżet → follow‑up

Dla czytelności można wyobrazić sobie zachowanie asystenta jako prostą maszynę stanów.

flowchart TD
    U[Użytkownik formułuje zadanie] --> G[GPT decyduje: uruchomić App?]
    G -->|Tak| A[Ogłasza uruchomienie App]
    A --> W[Widżet GiftGenius dobiera opcje]
    W --> S[Asystent podsumowuje wynik]
    S --> F[Asystent proponuje opcje follow-up]
    F -->|Użytkownik wybiera działanie| G
    G -->|Nie, nie uruchamiać App| T[Odpowiedź tekstowa bez UI]
    F -->|"Użytkownik mówi \"Dziękuję\""| E[Asystent kończy scenariusz i proponuje dalszą pomoc]

Taki przepływ faktycznie opisujemy słowami w system‑prompt.

Przykład kodu: follow‑up z widżetu

Od strony UI potraficie już wysyłać wiadomości follow‑up. Dla kompletności poniżej prosty przykład komponentu, który po kliknięciu prosi model o „zwiększenie budżetu”:

// components/ExpandBudgetButton.tsx
export function ExpandBudgetButton() {
    const onClick = () => {
        window.openai?.sendFollowUpMessage(
            "Pokaż opcje z nieco większym budżetem"
        );
    };

    return <button onClick={onClick}>Chcę droższe opcje</button>;
}

Teraz dodamy w system‑prompt tekst, który podpowie modelowi, jak obsługiwać takie wiadomości follow‑up.

// kontynuacja systemPrompt
const followUps = `
# Zachowanie po uruchomieniu aplikacji
Po tym, jak widżet pokaże listę prezentów,
krótko opisz wynik tekstem.

Następnie zaproponuj 1–3 zrozumiałe kolejne kroki
(np.: pokazać tańsze, zmienić budżet, zmienić kategorię).
Jeśli widżet wysyła wiadomość follow-up,
użyj jej jako wskazówki do następnego kroku.
`;

Z technicznego punktu widzenia to zwykły łańcuch znaków. Z punktu widzenia UX — podstawa przewidywalnego scenariusza.

5. Szacunek dla intencji użytkownika

Wszystko, o czym mówiliśmy wyżej, to wasze produktowe oczekiwania wobec zachowania App. Instrukcje UX będą działały słabo, jeśli model nie umie „słuchać” użytkownika. Nawet idealnie zaprojektowany App powinien ustąpić, jeśli człowiek wyraźnie prosi, by nie zmieniać formatu interakcji.

Jest kilka charakterystycznych sytuacji.

• Jeśli użytkownik wprost mówi, że nie chce uruchamiać aplikacji („Żadnego UI, po prostu wyjaśnij, co kupić”), asystent powinien traktować to jako twarde ograniczenie i nie próbować go obchodzić. Można grzecznie powiedzieć: „OK, będę odpowiadać tylko tekstem”, i dalej rzeczywiście dotrzymać słowa.
• Jeśli użytkownik obawia się, że coś włączy się automatycznie, warto dać mu poczucie kontroli. Na przykład: „Mogę otworzyć aplikację do doboru prezentów, ale jeśli wolisz, możemy omówić opcje po prostu w czacie. Jak ci wygodniej?” Tutaj wyraźnie dajecie wybór.
• Jeśli użytkownik pisze „Jestem na telefonie, nie uruchamiaj złożonych formularzy” — to też część kontekstu. Asystent powinien to przyjąć i np. ograniczyć się do krótkiej listy pomysłów i pytań doprecyzowujących.

Wpisujemy szacunek do kontraktu

To wszystko można zwięźle odzwierciedlić w system‑prompt:

export const respectBlock = `
# Priorytet intencji użytkownika
Zawsze uwzględniaj wyraźne prośby użytkownika
co do formatu rozmowy.

Jeśli prosi, by nie uruchamiać aplikacji ani widżetów,
nie proponuj i nie uruchamiaj GiftGenius,
nawet jeśli to pomogłoby rozwiązać zadanie.
Zamiast tego pomagaj tekstem.
`;

W ten sposób jednoznacznie ustalacie „kto tu rządzi” w dialogu. I spoiler: to nie duma z pięknego UI, lecz żywy człowiek po drugiej stronie ekranu.

6. Jak opracowywać instrukcje UX w system‑prompt i dokumentacji

Zebraliśmy już sporo zasad zachowania — od zapowiedzi App po wiadomości follow‑up i szacunek dla formatu dialogu. Teraz ważne jest nie tylko co mówimy modelowi, ale też jak jest to sformatowane w system‑prompt i dokumentacji.

System‑prompt w realnym App szybko się rozrasta. Jeśli pisać go jako ciągły tekst literacki, po tygodniu nikt już tam niczego nie znajdzie. Dlatego traktujcie go jak specyfikację techniczną lub README: strukturyzujcie.

Dobrą praktyką jest podzielenie promptu na kilka logicznych sekcji z nagłówkami. Na przykład: „Rola i zakres odpowiedzialności”, „Kiedy używać App”, „Kiedy nie używać App”, „Dialog i UX”, „Bezpieczeństwo i ograniczenia”. W każdej sekcji pisać prosto i jednoznacznie.

Jeszcze lepiej — wynieść system‑prompt do osobnego pliku obok kodu, zamiast wciskać go do literału łańcuchowego w środku komponentu. Wtedy łatwiej go recenzować, porównywać zmiany i omawiać z product managerami lub prawnikami.

Przykład organizacji system‑prompt w kodzie

Jedna z opcji — przechowywać części promptu w osobnych łańcuchach i składać w całość:

// app/prompt/role.ts
export const roleSection = `
# Rola
Jesteś ChatGPT App GiftGenius.
Pomagasz użytkownikowi dobrać prezenty do zadania i budżetu.
`;

// app/prompt/ux.ts
export const uxSection = `
# Dialog i UX
Przed uruchomieniem widżetu GiftGenius
krótko wyjaśnij, że zaraz otworzy się aplikacja z kartami prezentów.
Nie uruchamiaj aplikacji dla ogólnych lub teoretycznych pytań,
jeśli użytkownik wyraźnie nie prosi o dobór.
Po pracy widżetu podsumuj wynik tekstem
i zaproponuj 1–3 kolejne kroki.
`;

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

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

Taki podział pomaga myśleć o instrukcjach jak o osobnych modułach: część UX, bezpieczeństwo, praca z narzędziami itd. To szczególnie przydatne, gdy będziecie dodawać nowe możliwości i trzeba będzie uzgadniać zachowanie z kilkoma zespołami.

Ponadto dokumentację App (wewnętrzne README, Confluence, Notion) warto zsynchronizować z tymi sekcjami. Tam możecie ludzkim językiem opisać, dlaczego w taki sposób zapowiadacie App i czemu nie uruchamiacie go dla próbnych zapytań. Osobno utrwalcie, jakie powinny być wypowiedzi follow‑up. Dzięki temu nowi członkowie zespołu nie będą próbowali „naprawiać” promptu, nie rozumiejąc, co zrobiliście.

7. Praktyka: przepisujemy część UX dla naszego GiftGenius

Zbierzmy wszystko w jeden w miarę spójny przykład system‑promptu. Załóżmy, że mieliśmy bardzo skromny system‑prompt:

export const systemPrompt = `
Jesteś aplikacją GiftGenius.
Dobieraj prezenty użytkownikowi.
`;

Taki tekst nic nie mówi o tym, kiedy uruchamiać App, jak go zapowiadać i co robić po widżecie. Dodajmy instrukcje UX krok po kroku.

Najpierw jasno określmy zakres odpowiedzialności i format pracy:

const role = `
# Rola
Jesteś ChatGPT App GiftGenius.
Twoim zadaniem jest pomóc użytkownikowi dobrać 3–7 trafnych prezentów
pod zadany budżet, odbiorcę i okazję.
Możesz użyć widżetu GiftGenius do wizualnego doboru.
`;

Następnie opiszemy, jak zapowiadać uruchomienie:

const announce = `
# Zapowiedź aplikacji
Jeśli uważasz, że widżet GiftGenius lepiej pomoże,
najpierw wyjaśnij w jednym–dwóch zdaniach,
że zaraz otworzy się aplikacja z kartami prezentów
i że użytkownik będzie mógł je przejrzeć i odfiltrować.
Dopiero potem uruchamiaj aplikację.
`;

Dodajmy zasady, kiedy nie uruchamiać App:

const noApp = `
# Kiedy nie używać aplikacji
Jeśli użytkownik pyta tylko o to, co potrafi usługa,
albo chce ogólnych informacji teoretycznych o prezentach,
odpowiedz tekstem i nie uruchamiaj GiftGenius.

Jeśli zapytanie nie dotyczy prezentów (np. o CV lub kod),
odpowiadaj jak zwykły ChatGPT i nie proponuj aplikacji.

Jeśli użytkownik prosi, by nie używać aplikacji,
traktuj to jako obowiązkowe ograniczenie.
`;

I zakończmy zachowaniem po użyciu widżetu:

const afterWidget = `
# Zachowanie po widżecie
Po tym, jak widżet pokaże propozycje prezentów,
krótko opisz wynik własnymi słowami.
Zaproponuj użytkownikowi 1–3 kolejne kroki
(np.: zmienić budżet, filtrować według zainteresowań,
pokazać tylko tańsze opcje).

Jeśli widżet wysłał wiadomość follow-up,
użyj jej jako głównego sygnału do następnego kroku.
`;

Finalny system‑prompt może wyglądać tak:

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

To już przypomina specyfikację zachowania, a nie „życzenie do wszechświata”. W kolejnych modułach będziecie uzupełniać ten kontrakt instrukcjami o bezpieczeństwie, halucynacjach, komercji i innych urokach dorosłego życia App, ale część UX stanowi już fundament.

8. Typowe błędy przy ustawianiu instrukcji UX

Błąd nr 1: „App zawsze lepsze od tekstu”.
Czasem deweloperzy są tak dumni ze swojego widżetu, że wymagają od modelu wywoływania go przy każdej okazji. W efekcie użytkownik dostaje App nawet tam, gdzie chciał po prostu zapytać „co to w ogóle jest?”. Model staje się nachalny, a ludzie zaczynają ignorować aplikację. Właściwe podejście — jasno zapisać scenariusze, kiedy App nie jest potrzebny, i te przypadki szanować.

Błąd nr 2: brak wyraźnej zapowiedzi przed uruchomieniem App.
Jeśli asystent po cichu uruchamia widżet, użytkownik nie rozumie, skąd wziął się blok UI i co z nim zrobić. Wytyczne OpenAI i praktyka pokazują: jedno–dwa zdania „teraz otworzę aplikację, która zrobi X” wyraźnie poprawiają UX i zmniejszają zagubienie.

Błąd nr 3: zbyt agresywne ponowne proponowanie App.
Zdarza się, że App po każdej odpowiedzi znów proponuje uruchomienie widżetu: „Chcesz jeszcze raz otworzyć aplikację? A teraz? A może teraz?”. To szybko staje się spamem. Lepiej utrwalić w instrukcjach, że po pierwszym użyciu App trzeba patrzeć na kontekst: proponować go ponownie tylko wtedy, gdy użytkownik wyraźnie zmienia parametry zadania albo sam prosi „pokaż więcej”.

Błąd nr 4: ignorowanie wyraźnej odmowy aplikacji.
Frazy w rodzaju „tylko bez aplikacji, proszę” lub „nie wygodnie mi z telefonu pracować z formularzami” należy traktować jako twarde ograniczenia. Jeśli model wciąż narzuca App, użytkownik traci zaufanie zarówno do asystenta, jak i do waszego produktu. W system‑prompt łatwo to utrwalić dwoma–trzema zdaniami, ale wiele osób o tym zapomina.

Błąd nr 5: brak podsumowania i wiadomości follow‑up po widżecie.
Czasem widżet uczciwie pokazuje propozycje, a asystent po tym milczy. Użytkownik widzi UI, ale nie wie, co dalej. Brak tekstu, brak pytania, brak przycisków z popularnymi akcjami. Taki scenariusz wygląda na niedomknięty i psuje spójność dialogu. Zawsze zapisujcie w instrukcjach, że po widżecie powinno iść krótkie podsumowanie tekstowe i 1–3 zrozumiałe kolejne kroki.

Błąd nr 6: mieszanie produktowego UX i „ogólnego stylu ChatGPT” w jednym akapicie.
Czasem system‑prompt zamienia się w długi tekst artystyczny: „Bądź przyjazny, używaj emotikonów, czasem żartuj, jeśli to na miejscu. I tak, być może kiedyś uruchamiaj App.” W takim tekście trudno zauważyć realne zasady UX. Lepiej wydzielać osobne sekcje z jasnymi nagłówkami: „Rola”, „Dialog i UX”, „Kiedy używać App”, „Kiedy nie używać App”. Pomaga to i modelowi, i ludziom, którzy będą z tym promptem pracować po was.