Spis treści
Funkcja AI w produkcie rzadko odpada przez model. Odpada przez interfejs: użytkownik nie wie, że rozmawia z maszyną, nie ma jak sprawdzić odpowiedzi, nie umie jej cofnąć, a gdy funkcja się nie wykona, widzi pusty prostokąt. Model odpowiada świetnie, a wskaźnik użycia stoi.
Ten tekst jest o czterech miejscach, w których to się rozstrzyga, i o siedmiu stanach, których nie ma w pierwszej makiecie. To jest strona projektowa.
Strona prawna ma własny materiał: obowiązki przejrzystości z artykułu 50 AI Act obowiązują od 2 sierpnia 2026 i rozkładamy je osobno - kogo dotyczą, co trzeba znakować i w jakich terminach - w tekście o tym, co musi znaleźć się w interfejsie produktu z AI. Tutaj przepis pojawia się tylko tam, gdzie zmienia decyzję projektową.
Trzy poziomy ekspozycji - i dlaczego czat jest najdroższy
Nie każda funkcja AI kosztuje tyle samo. Dokumentacja Google „UX patterns” dla funkcji AI dzieli je według tego, ile kontroli oddajesz użytkownikowi. Ten podział jest użyteczny, bo poziom ekspozycji przesądza o koszcie projektowym, zanim napiszesz pierwszą linijkę promptu.
AI w tle działa bez udziału użytkownika: podsumowanie opinii pod produktem, sortowanie wyników, wykrywanie duplikatów. Nikt niczego nie wpisuje, nikt nie musi rozumieć, jak to działa. Ryzyko jest najniższe, bo produkt zachowuje wartość nawet wtedy, gdy funkcja się nie wykona.
AI ograniczone to jedno zadanie za jednym przyciskiem: „zaproponuj tytuł”, „skróć opis”, „wypełnij na podstawie umowy”. Użytkownik wie, że uruchamia funkcję, ale nie formułuje jej dowolnie. Wynik jest przewidywalny, a przestrzeń błędu - policzalna.
AI otwarte to pole tekstowe, w które można wpisać cokolwiek. Największa elastyczność i wielokrotnie największy koszt projektowy, bo trzeba obsłużyć pytania, których nikt nie przewidział, oraz odpowiedzi, których nikt nie zatwierdził.
Czat jest najdroższą formą interfejsu AI, a bywa wybierany jako pierwsza, a nie ostatnia opcja - bo wygląda na najprostszy do zbudowania. Jest odwrotnie: przenosi na użytkownika całą pracę wymyślenia, o co zapytać.
Reguła, którą stosujemy w projektach: schodź na najniższy poziom ekspozycji, który realizuje cel. Jeżeli 80% zapytań do asystenta to cztery powtarzalne intencje, to nie jest przypadek na czat - to cztery przyciski, które zawsze działają tak samo, mają własne stany błędu i dają się przetestować.
Wzorzec 1. Ujawnienie, które nie jest disclaimerem
Zespoły projektują komunikat „to jest AI” tak, jak projektuje się klauzulę: mały tekst, szary, jak najdalej od głównej akcji. To jest optymalizacja pod „żeby nikt nie zauważył” - i przegrywa dwa razy naraz, bo użytkownik i tak się orientuje, tylko później i z gorszym wrażeniem.
Ujawnienie działa wtedy, gdy stoi przy funkcji, a nie przy stronie, i gdy jest tekstem, nie samym symbolem.
Ujawnienie pozorne
- Gwiazdka i zdanie w stopce strony, poza kontekstem funkcji.
- Akapit w regulaminie, do którego trzeba dotrzeć z osobnego linku.
- Sama ikonka iskierki przy przycisku, bez etykiety tekstowej.
- Informacja pokazana raz w onboardingu i nigdy więcej.
- „Twój wirtualny doradca Ania” z awatarem twarzy i bez słowa o AI.
Ujawnienie, które działa
- Pasek informacyjny w oknie asystenta, widoczny przy pierwszej wiadomości.
- Nazwa funkcji, która sama niesie informację: „Podsumowanie AI”, nie „Szybki wgląd”.
- Etykieta przy wyniku, nie tylko przy przycisku, który go wywołał.
- Trwały, dyskretny znacznik w interfejsie - nie komunikat do zamknięcia raz na zawsze.
- Ta sama informacja w kanale głosowym, wypowiedziana na początku rozmowy.
Jest tu jedna pułapka, której nie widać z wewnątrz zespołu: „przecież to oczywiste, że to AI” prawie nigdy nie jest oceną użytkownika, tylko oceną osoby, która spędziła przy tej funkcji kwartał. Jeśli chcesz to rozstrzygnąć, rozstrzygnij badaniem, a nie na spotkaniu.
Wzorzec 2. Pokaż, skąd wziął się wynik
Wynik, którego nie da się sprawdzić, jest wart tyle, ile zaufanie do niego - a zaufanie bez podstawy zamienia się w jedno z dwóch: ślepą akceptację albo porzucenie funkcji. Oba są złe, tylko drugie widać w danych.
Trzy rzeczy, które to rozwiązują, w kolejności od najtańszej:
Wskaż źródło. Jeśli odpowiedź powstała z dokumentów klienta, pokaż który dokument i którą sekcję, z linkiem otwierającym oryginał w tym samym kontekście. To najsilniejszy pojedynczy element budujący zaufanie do funkcji opartej na danych firmowych.
Pokaż zakres, nie tylko wynik. „Na podstawie 128 opinii z ostatnich 90 dni” mówi więcej niż każde zapewnienie o dokładności. Użytkownik sam oceni, czy próbka mu wystarcza.
Pisz językiem, który nie udaje pewności. To jest ustawienie systemowego promptu, nie zadanie dla copywritera na końcu. „Wygląda na to, że umowa nie zawiera klauzuli o wypowiedzeniu” i „Umowa nie zawiera klauzuli o wypowiedzeniu” to zdania o różnej odpowiedzialności. Jeśli model nie ma podstaw do drugiego, nie może go napisać.
Wzorzec 3. Kontrola - cofnij, popraw, wyłącz
Funkcja AI, której nie da się odwrócić, przenosi na użytkownika ryzyko, którego on nie kontroluje. Minimum to trzy wyjścia: cofnięcie rezultatu, edycja zamiast akceptacji lub odrzucenia w całości, oraz wyłączenie funkcji na stałe.
To ostatnie bywa kwestionowane przez zespoły produktowe („po co dawać opcję wyłączenia czegoś, co jest naszą przewagą”). Argument jest odwrotny: opcja wyłączenia zamienia użytkownika sceptycznego w użytkownika, który zostaje. Bez niej sceptyk zostaje utraconym użytkownikiem, a Ty nie dowiadujesz się dlaczego.
I rzecz, która wygląda na oczywistą, a bywa pomijana: produkt musi działać, gdy funkcja AI nie działa. Model bywa niedostępny, przekroczysz limit, dostawca zmieni warunki. Jeśli podsumowanie się nie wygeneruje, użytkownik ma zobaczyć pełną listę opinii, a nie pusty prostokąt z komunikatem o błędzie.
Wzorce zaufania i kontroli nie są zresztą wynalazkiem ery AI. Dokładnie ten sam problem - „maszyna policzyła, użytkownik ma w to uwierzyć i podjąć decyzję” - rozwiązywaliśmy w kalkulatorach ofert i panelach B2B, na długo zanim doszedł do tego model językowy:
W obu przypadkach praca projektowa polegała na tym samym: pokazać składniki wyniku, pozwolić zmienić założenia i nie kazać użytkownikowi przyjmować liczby na słowo. Funkcja AI stawia to samo pytanie, tylko przy większej niepewności po stronie systemu.
Wzorzec 4. Siedem stanów, o których zapomina pierwszy projekt
Makieta funkcji AI prawie zawsze pokazuje jeden stan: udany wynik. Produkcja pokazuje siedem. Lista poniżej to nie teoria - to zestaw ekranów, których brak wychodzi na pierwszym demie z realnymi danymi:
- Ładowanie / strumieniowanie. Odpowiedź pojawiająca się stopniowo wymaga innego traktowania niż spinner: trzeba zdecydować, czy da się ją przerwać i co się dzieje z połową tekstu.
- Pusty. Brak danych do podsumowania to nie błąd. To komunikat wyjaśniający, czego brakuje i co zrobić.
- Niepewny. Model odpowiedział, ale bez pokrycia w źródłach. Ten stan trzeba zaprojektować świadomie, inaczej wygląda identycznie jak stan pewny.
- Odmowa. System nie odpowie, bo pytanie wykracza poza zakres. Powiedz, jaki jest zakres, zamiast zostawiać ścianę.
- Limit. Wyczerpany pakiet zapytań. Kiedy się odnowi i co można zrobić teraz.
- Błąd techniczny. Z zachowaniem tego, co użytkownik już napisał - utrata wpisanego tekstu jest tu najdotkliwsza.
- Wyłączone. Funkcja niedostępna w tym planie albo wyłączona przez administratora.
Cztery rzeczy, które psują dostępność tego komponentu
Pasek z informacją o AI jest małym elementem, w którym mieści się zaskakująco dużo błędów - i akurat ten element bywa projektowany „na szybko”, bo wygląda na drobiazg. Wymagania dostępności obowiązują go tak samo jak resztę interfejsu; pisaliśmy osobno o tym, kogo naprawdę dotyczy Polski Akt o Dostępności.
- informacja niesiona wyłącznie ikoną - bez tekstu dostępnego dla czytnika ekranu.
- odpowiedź strumieniowana bez
aria-live- czytnik nie zapowiada, że pojawia się nowa treść, albo zapowiada każdy fragment osobno. - kontrast poniżej progu na etykiecie „AI”, bo z założenia miała być dyskretna.
- fokus przenoszony do odpowiedzi w trakcie generowania, który wyrzuca użytkownika klawiatury z pola wpisywania.
Gdzie te wzorce mieszkają - w design systemie, nie na ekranie
Do tego wniosku dochodzi każdy zespół, ale zwykle po trzeciej funkcji AI w tym samym produkcie: jeżeli ujawnienie, źródło, kontrola i stany są projektowane osobno dla każdej funkcji, to za trzecim razem masz trzy różne odpowiedzi na to samo pytanie. Trzy etykiety, trzy komunikaty błędu, trzy zachowania przycisku „cofnij”.
Wzorce AI należą do warstwy systemowej dokładnie tak samo jak przycisk czy pole formularza:
- komponent ujawnienia w wariantach (pasek w oknie, etykieta przy wyniku, znacznik w treści).
- wzorzec wyniku AI z gniazdem na źródła i zakres danych.
- zestaw stanów jako pełnoprawne warianty komponentu, nie jako uwagi w dokumentacji.
- mikrocopy - jedno miejsce, w którym zapada decyzja, że mówimy „Wygląda na to”, a nie „Na pewno”.
- token czasu strumieniowania i reguła zachowania przy
prefers-reduced-motion.
Design system, który to trzyma, ma jeszcze jedną własność, o której pisaliśmy przy okazji design systemu napędzającego AI przy wdrożeniach: jest czytelny dla narzędzi generujących kod. Wzorzec zapisany jako komponent z nazwanymi stanami wraca z generatora jako ten sam komponent. Zapisany jako akapit w dokumencie - wraca jako <div>.
Co zmierzyć, żeby wiedzieć, czy to działa
Liczba uruchomień funkcji AI nie mówi nic o jej wartości. Cztery wskaźniki, które mówią:
Udział wyników zaakceptowanych bez edycji. Zbyt niski oznacza, że funkcja generuje pracę zamiast ją odbierać. Zbyt wysoki, przy odpowiedziach, których nie da się zweryfikować, oznacza ślepe zaufanie - i to jest sygnał ostrzegawczy, nie sukces.
Udział wyników poprawionych, a nie odrzuconych. Poprawka to najlepszy możliwy wynik: użytkownikowi opłaciło się zacząć od propozycji systemu.
Częstość cofnięć. Rosnąca krzywa cofnięć przy stałej liczbie uruchomień znaczy, że funkcja zaczyna działać inaczej, niż użytkownicy się spodziewają.
Udział wyłączeń funkcji. Najbardziej niewygodny wskaźnik i dlatego najczęściej nieinstrumentowany. Jeżeli rośnie, żaden inny wynik tego nie równoważy.
Checklista projektowa
Do przejścia przed wypuszczeniem funkcji AI do użytkowników. To jest lista projektowa - obowiązki formalne mają własną checklistę w tekście o artykule 50.
- Funkcja stoi na najniższym poziomie ekspozycji, który realizuje cel - czat jest decyzją, nie domyślną formą.
- Informacja o AI pojawia się przy funkcji, przy pierwszej interakcji, i jest tekstem, nie samą ikoną.
- Wynik pokazuje źródło i zakres danych, na których powstał.
- Język odpowiedzi nie udaje pewności, której model nie ma - i jest to zapisane w systemowym prompcie.
- Użytkownik może cofnąć, poprawić i wyłączyć - wszystkie trzy, nie jedno z nich.
- Produkt zachowuje wartość, gdy funkcja AI nie zadziała.
- Wszystkie siedem stanów ma zaprojektowany ekran, nie tylko stan udany.
- Komponent przechodzi test czytnika ekranu, kontrastu i klawiatury.
- Wzorce siedzą w design systemie, nie w pliku jednego ekranu.
- Masz instrumentację akceptacji, poprawek, cofnięć i wyłączeń.
Jeżeli odpowiedź na którykolwiek z punktów 2–8 brzmi „zrobimy w następnej iteracji”, to funkcja nie jest gotowa - niezależnie od tego, jak dobrze odpowiada model.
Współzałożyciel i Prezes Agencji UX Wzór. Analityk biznesowy - prowadzi projekty interfejsów aplikacji mobilnych, desktopowych i e-commerce, od analizy biznesowej, badań i architektury informacji po dopracowane UI.
