Poniższy tekst stanowi notatki z prezentacji Pedro Moreira da Silva (Principal Product Designer, GitLab) wygłoszonej na LisboaUX podczas Lisbon AI Week. Wszystkie przemyślenia, obserwacje i wnioski pochodzą od prelegenta.

TL;DR

Użytkowników nie interesuje technologia AI sama w sobie – zależy im na wartości, spójności i przewidywalności
Zanim zapytasz „czy możemy użyć AI?”, zadaj pytanie „jak rozwiązać ten problem?” i „czy AI rozwiąże go w unikalny sposób?”
Automatyzacja sprawdza się przy zadaniach nudnych i powtarzalnych, natomiast augmentacja – gdy użytkownicy chcą zachować kontrolę
Ścieżki błędów (unhappy paths) w AI to nie edge cases, lecz kluczowe przepływy wymagające zaprojektowania
Wyrównanie oczekiwań zespołu przed projektowaniem okazuje się większym wyzwaniem niż sama technologia
Sam interfejs to „łatwa część” – prawdziwe wyzwanie leży w tym, co dzieje się wcześniej
Testowanie AI wymaga wyjścia poza użyteczność – GitLab stosuje 8 wymiarów oceny doświadczenia

Kontekst

Pedro Moreira da Silva pełni funkcję Principal Product Designer w GitLab, gdzie odpowiada za asystentów i agentów AI wspierających rozwój oprogramowania. GitLab to platforma używana przez ponad 30 milionów użytkowników oraz ponad połowę firm z listy Fortune 100. Organizacja działa w pełni zdalnie – zatrudnia ponad 2000 pracowników w 60 krajach, nie posiadając ani jednego biura.

Prezentacja powstała na bazie twardych lekcji. Da Silva przyznaje, że GitLab wprowadził funkcję AI z imponującymi metrykami technicznymi. Użytkownicy okazali się jednak zdezorientowani – nie wiedzieli, czego się spodziewać.

Problem z AI w branży

Każdego dnia pojawia się nowe narzędzie AI. Prawdopodobnie jedno uruchamia się właśnie teraz. W każdej prezentacji, w każdej firmie, w wiadomościach – wszyscy mówią tylko o AI. Do znudzenia.

Da Silva przytacza satyryczną definicję krążącą w branży: AI UX to praktyka zastępowania każdego pola input, tabeli i przycisku chatbotem o inkluzywnym, ale chwytliwym ludzkim imieniu. To celne podsumowanie problemu, a zarazem punkt wyjścia do lepszego podejścia.

AI czy nie-AI? Pierwsze pytanie projektowe

Tradycyjne produkty oparte na regułach „jeśli to, to tamto” mają istotną przewagę. Łatwiej je wdrożyć, szybciej trafiają na rynek, prościej je zmierzyć, a użytkownicy lepiej je rozumieją.

Da Silva stawia tezę, która może zaskakiwać: w większości przypadków produkt bez AI jest lepszy niż produkt z AI – przynajmniej jako pierwszy krok na rynek.

Zanim zespół przystąpi do prac projektowych, powinien zadać sobie fundamentalne pytanie. Nie brzmi ono „czy możemy użyć tu AI?”, lecz „jak możemy rozwiązać ten problem?”. Dopiero potem pojawia się kwestia: „czy AI rozwiąże go w unikalny sposób?”.

Kiedy AI dodaje realną wartość

Spersonalizowana treść
Predykcyjna inteligencja
Adaptacyjne uczenie się
Przetwarzanie języka naturalnego

Kiedy pominąć AI

Niezawodność jest krytyczna – nawigacja produktu nie powinna być „kreatywna” przy każdym użyciu; w branży medycznej czy finansowej nieprzewidywalność stanowi poważne ryzyko
Prostota działa lepiej – tradycyjny formularz bywa szybszy niż konwersacja z botem
Wymagana jest przejrzystość – w branżach regulowanych użytkownik musi znać dokładne przyczyny podjęcia danej decyzji
Użytkownicy preferują kontrolę – w sytuacjach wysokiego ryzyka ludzie często wolą wykonać zadanie samodzielnie

Badania w praktyce: jak GitLab identyfikuje potrzeby

Badanie 1: Optymalizacja procesu budowania oprogramowania

Da Silva przedstawia trzyetapowy proces badawczy stosowany w GitLab.

Etap 1: Drzewo decyzyjne. Badacze przeszli przez proces z uczestnikami, pytając przy każdym kroku: jaką decyzję podjąłeś? Dlaczego właśnie taką?

Etap 2: Eksperyment myślowy. Uczestnikom pokazano screenshot prostego interfejsu czatu. Następnie zadano pytania: czego byś oczekiwał? Czego się obawiasz?

Etap 3: Ankieta rankingowa. Uczestnicy oceniali przydatność konkretnych możliwości AI w badanym procesie.

Wnioski z badania:

Oczekiwania wobec czatu AI okazały się bardzo szerokie i bardzo wysokie – użytkownicy oczekują wszystkiego, a każdego dnia jeszcze więcej
Rekomendacje AI osadzone w kontekście istniejącego przepływu pracy działały znacznie lepiej niż oddzielny interfejs czatu
Wiele części procesu w ogóle nie wymagało AI – wystarczyła prosta automatyzacja w tle

Badanie 2: Naprawianie problemów w pipeline

Drugie badanie dotyczyło procesu naprawiania błędów w pipeline (budowanie i testowanie oprogramowania). Tym razem struktura wyglądała inaczej:

Etap 1: Sekwencja zdarzeń – jak wygląda proces krok po kroku

Etap 2: Zespoły – kto wchodzi na każdym etapie i jakie informacje wnosi

Etap 3: Pytania – co ludzie pytają sami siebie na każdym kroku

Wnioski z badania:

Zidentyfikowano najtrudniejsze i najdłuższe kroki, które stały się głównymi kandydatami do AI lub automatyzacji
Niektóre role wykazywały się większym konserwatyzmem wobec użycia AI w tym procesie niż inne
Możliwe jest stosowanie różnych poziomów automatyzacji w zależności od typu problemu
Wszyscy uczestnicy przyznali, że z czasem stawaliby się coraz bardziej „komfortowi” z automatyzacją – co rodzi pytanie o odpowiedzialność i ryzyko samozadowolenia

Automatyzacja vs augmentacja

Da Silva zauważa typowe myślenie zespołów: „jeśli możemy zautomatyzować wszystko za pomocą AI, użytkownicy będą szczęśliwi”. W praktyce jednak niekoniecznie tak to działa.

Automatyzacja sprawdza się świetnie w określonych przypadkach. Nikt nie tęskni za ręcznym sprawdzaniem pisowni. Użytkownicy GitLab świętowali, gdy dodano automatyczne skanowanie podatności – przeszukiwanie setek tysięcy linii kodu w poszukiwaniu luk bezpieczeństwa.

Augmentacja to jednak zupełnie inna sprawa. Da Silva używa konkretnego sformułowania: celem augmentacji jest sprawienie, by użytkownicy czuli się jak superbohaterowie. Nie chodzi wyłącznie o wsparcie – chodzi o wzmocnienie ich możliwości.

Checklista: Automatyzacja czy augmentacja?

Automatyzuj, gdy:

Użytkownicy nie mają wiedzy lub umiejętności do wykonania zadania
Zadanie jest nudne, powtarzalne lub niezręczne
Zadanie jest niebezpieczne dla człowieka
Nikt nie czerpie satysfakcji z wykonywania tego zadania

Augmentuj (wspieraj), gdy:

Użytkownicy lubią wykonywać to zadanie
Użytkownicy ponoszą osobistą odpowiedzialność za wynik
Stawka jest wysoka i użytkownicy chcą mieć pewność
Wizja jest trudna do wyrażenia słowami („poznam, gdy zobaczę”)

Efekt GPS: degradacja umiejętności

Da Silva przywołuje obrazowy przykład. Jedziesz samochodem z włączonym GPS-em. Wszystko działa, aż nagle GPS przestaje funkcjonować. Ogarnia cię panika – nie wiesz, co robić.

Prelegent komentuje: „To fascynująca psychologiczna konsekwencja próby automatyzowania zadań za użytkowników.”

Badacze nazywają to zjawisko out of the loop unfamiliarity. Wielu ludzi zapomniało, jak czytać mapy. To degradacja umiejętności – dzieje się z każdym z nas, czy tego chcemy, czy nie. Nadmierne poleganie na automatyzacji usypia czujność, a w razie awarii użytkownik pozostaje bezradny.

Da Silva przywołuje artykuł naukowy „A model for types and levels of human interaction with automation”, który wprowadza cztery wymiary automatyzacji (acquisition, analysis, decision, action) oraz kryteria oceny: obciążenie mentalne, świadomość kontekstu, samozadowolenie i degradacja umiejętności.

Prelegent pyta wprost: „Nagłówek 'GitLab powoduje poważną awarię, bo inżynierowie ufali automatyzacji’ – czy tego chcemy?”

Wyrównanie oczekiwań: większy problem niż technologia

W projektach AI, nad którymi pracował da Silva, największym problemem nie była technologia ani projektowanie interfejsu. Najtrudniejsze okazało się doprowadzenie wszystkich do wspólnego zrozumienia.

Co AI powinno robić? Czego nie powinno? Jak wygląda „dobrze”? Od inżyniera po CEO – każdy ma inną perspektywę, ponieważ AI jest z natury nieprzewidywalne.

Rozwiązanie: Interaction Design Policies (Google)

Google opracował prosty framework do ustalania reguł przed projektowaniem. Da Silva podkreśla jego prostotę – cztery elementy, które każdy może zrozumieć i do których może wnieść swój wkład:

Kategoria	Pytanie do odpowiedzi
Akceptowalne działania	Co AI może wykonywać autonomicznie?
Nieakceptowalne działania	Jakich treści system nie może generować (np. stereotypy)?
Progi niepewności	W jakich sytuacjach AI musi poprosić człowieka o weryfikację lub doprecyzowanie?
Podatności (luki)	Jakie są najgorsze możliwe konsekwencje błędu AI?

Na przykładzie aplikacji do planowania wydarzeń: użytkownicy zgodzą się poprawić kilka słów lub obrazów, nie będą jednak chcieli przepisywać całego zaproszenia. To właśnie jest próg niepewności, który trzeba ustalić z góry.

Human-AI Interaction Toolkit (Microsoft)

Po ustaleniu polityk projektowych da Silva rekomenduje HACS Toolkit od Microsoft, oparty na dekadach badań.

Learning: biblioteka wytycznych, wzorców projektowych i przykładów. Pokazuje, co działało, co nie działało oraz jak pomagać użytkownikowi na różnych etapach interakcji – początkowo, w trakcie i gdy coś idzie źle.

Planning: HACS Workbook do pracy zespołowej. Wybierasz wytyczne, wyobrażasz sobie ich wpływ, projektujesz wymagania i sprawdzasz, jak dana wytyczna odnosi się do konkretnej sytuacji.

Zmiana paradygmatu: od systemów deterministycznych do probabilistycznych

Da Silva podkreśla: sam interfejs to „łatwa część”. Prawdziwe wyzwanie leży wcześniej – w zrozumieniu problemu, wyrównaniu oczekiwań oraz określeniu polityk projektowych.

Istnieje jednak jeszcze jedna fundamentalna różnica między tradycyjnym a AI-owym projektowaniem.

Tradycyjne oprogramowanie jest deterministyczne – to samo działanie zawsze przynosi ten sam skutek. Kliknięcie przycisku daje skończony zestaw możliwych wyników.

Systemy AI są probabilistyczne – ten sam przycisk może za każdym razem wygenerować inną odpowiedź.

W konsekwencji, zamiast projektować przewidywalne wyniki, trzeba projektować dla interakcji z tym, co AI produkuje:

Jak użytkownicy formułują dane wejściowe
Jak rozumieją otrzymane wyniki
Jak mogą dostosować i doprecyzować wyniki
Jak mogą odzyskać kontrolę po błędach

Happy paths w AI

W kontekście AI happy path nie oznacza perfekcyjnych wyników. Oznacza natomiast: użytkownik potrafi obsłużyć niedoskonałe odpowiedzi. Pierwsza odpowiedź rzadko jest dokładnie tym, czego szukamy. Prosimy o doprecyzowanie – i to wciąż pozostaje happy path.

Unhappy paths jako core flows

W tradycyjnym projektowaniu unhappy paths to edge cases – te mityczne 1%. W AI unhappy paths stanowią kluczowe przepływy. Rolą projektanta przestaje być tworzenie idealnych odpowiedzi, a zaczyna być budowanie systemów odzyskiwania kontroli.

Przykład: prowadzisz długą rozmowę z ChatGPT lub Claude. Wszystko idzie świetnie, aż nagle uderzasz w limit rozmiaru konwersacji. Wszystko znika. To nie jest edge case – to wydarzy się podczas normalnego użytkowania.

Awarie techniczne do obsłużenia:

Błędne lub halucynowane odpowiedzi
Timeouty i przerwy w połączeniu
Limity tokenów i rozmiaru konwersacji

Warianty zachowań użytkownika do obsłużenia:

Bardzo złożone lub wielowątkowe zapytania
Zmiana kontekstu w trakcie zadania
Niezrozumienie możliwości i ograniczeń produktu
Nieodpowiednie lub nieetyczne prompty (czy żądanie jest legalne? Czy jest etyczne? Czy przekracza granice?)

Projektowanie wytycznych systemowych

Chociaż nie mamy pełnej kontroli nad tym, co wygeneruje model, możemy zaprojektować strukturę jego zachowań w sytuacjach awaryjnych. Da Silva pokazuje przykład diagramu przepływu, gdzie dla każdej negatywnej odpowiedzi określa się wytyczne dla instrukcji systemowej.

Zamiast pisać gotowe skrypty odpowiedzi, warto określić:

Typ reakcji – czy asystent ma przeprosić, dopytać o szczegóły, czy odesłać do dokumentacji?

Strukturę komunikatu – np. „jeśli pewność jest niska, najpierw wskaż brakujące informacje, a potem zasugeruj alternatywę”

Ton wypowiedzi w błędach – w jaki sposób asystent ma odmawiać wykonania zadania, aby zachować spójność z marką?

Nie kontrolujemy dokładnej odpowiedzi AI, możemy jednak dać mu wytyczne – podobnie jak dajemy je ludzkiemu asystentowi.

Testowanie poza użytecznością: 8 wymiarów AI experience

Standardowe testy użyteczności są niewystarczające w przypadku systemów probabilistycznych. Dlatego GitLab opracował i monitoruje jakość swoich rozwiązań AI w oparciu o osiem kluczowych wymiarów.

Checklista audytowa

[ ] Dokładność (Accuracy) – czy generowane odpowiedzi są poprawne merytorycznie?
[ ] Zaufanie (Trustability) – czy użytkownik czuje się bezpiecznie, opierając swoje decyzje na wynikach?
[ ] Wartość (Value) – czy funkcja rozwiązuje rzeczywisty problem użytkownika?
[ ] Kontrola (Control) – czy łatwo jest edytować, poprawić lub odrzucić wynik działania AI?
[ ] Obsługa błędów (Error Handling) – czy system skutecznie pomaga wrócić na właściwe tory po wystąpieniu problemu?
[ ] Bariery bezpieczeństwa (Guardrails) – czy system wprowadza celowe utrudnienia, wymuszając krytyczne myślenie tam, gdzie jest to konieczne?
[ ] Łatwość nauki (Learnability) – czy użytkownik rozumie, jak efektywnie komunikować się z modelem?
[ ] Limity – czy ograniczenia systemu są jasno i uczciwie zakomunikowane?

Wymiary te trafiają do ankiety śledzącej funkcje w czasie. Dają znacznie bogatszy obraz niż klasyczne testowanie użyteczności – pokazują rzeczy niewidoczne w samym interfejsie.

Trzy kluczowe wnioski

Da Silva zamyka prezentację trzema wnioskami, które ukształtowały podejście GitLab do AI:

Nie wszystko zyskuje na AI. Czasem prostsze podejście oparte na regułach okazuje się cenniejsze. Użytkownicy chcą rozwiązania problemu – nie obchodzi ich, czy jest tam AI. Może inwestorów obchodzi, ale to inna historia.
Unhappy paths to core flows w AI. Trzeba rozumieć, jak przywrócić użytkownika na właściwą ścieżkę, gdy coś pójdzie źle. Bo pójdzie.
Testowanie wykraczające poza użyteczność. Osiem wymiarów. Głębiej, bogaciej, szerzej. Śledzenie w czasie.

Na koniec da Silva przypomina: to maraton, nie sprint. Trzeba się ciągle uczyć, ponieważ codziennie pojawiają się nowe rzeczy. Projektowanie doświadczeń AI to prawdopodobnie największe wyzwanie UX naszego pokolenia – i jest tu na stałe.

Polecane zasoby

Human-AI Interaction Toolkit (HACS) – Microsoft
Interaction Design Policies – Google
A model for types and levels of human interaction with automation – artykuł naukowy o poziomach automatyzacji

Kluczowy insight

Paradoks użytecznego tarcia

Standardowo myślimy: Celem dobrego UX jest całkowite usunięcie barier i trudności. Interfejs powinien być płynny, a użytkownik nie powinien musieć się zastanawiać nad kolejnym krokiem.

W praktyce okazuje się, że: W systemach AI nadmierna płynność bywa niebezpieczna. Jeśli interakcja jest zbyt łatwa, użytkownicy wpadają w stan uśpionej czujności i bezrefleksyjnie akceptują błędne wyniki modelu. Da Silva mówi wprost o „świadomym tarciu” (mindful friction), które wymusza krytyczne myślenie tam, gdzie jest to konieczne.

Dlaczego to jest istotne: Brak celowego utrudnienia w kluczowych punktach decyzyjnych sprawia, że użytkownicy tracą zdolność krytycznej oceny. Prowadzi to do wdrażania błędów na produkcję i ostatecznie do utraty zaufania do narzędzia. To właśnie dlatego guardrails stanowią jeden z ośmiu wymiarów jakości AI w GitLab.

Test na jutro: Przeanalizuj proces, w którym AI generuje wynik. Zamiast pozwalać na automatyczne zastosowanie zmiany jednym kliknięciem, rozbij ten krok – wymuś na użytkowniku aktywne potwierdzenie kluczowej zmiennej. Następnie obserwuj, czy wzrasta liczba wychwyconych błędów przed wdrożeniem.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło – była to prezentacja Pedro Moreira da Silva na LisboaUX podczas Lisbon AI Week.

Tag: Guardrails

The AI Experience Playbook: Jak GitLab projektuje doświadczenia AI #EN354