Wzorce projektowe dla AI - lekcje z transformacji GitLaba #EN299

Uwaga: Poniższy tekst stanowi notatki z prezentacji Katie McCoy, product designer z zespołu AI Framework w GitLabie. Wszystkie przemyślenia, obserwacje i wnioski pochodzą od prelegentki oraz uczestników sesji UX Showcase.

TL;DR

Funkcje AI w produktach często są niespójne – od prostych przycisków po złożone przepływy interakcji
Projektanci pracują w silosach – brak świadomości o istniejących funkcjach AI i wzorcach używanych przez inne zespoły
Problem kontekstu – AI nie wie gdzie jest użytkownik ani co może dla niego zrobić w danej sytuacji
Podejście „table stakes first” – najpierw standaryzować podstawy (przyciski, ikony), potem abstrakcyjne wzorce
Trzy poziomy niespójności – elementy UI, przepływy użytkownika, abstrakcyjne wzorce interakcji
Sesje ideacyjne jako rozwiązanie – wspólne rozwiązywanie podobnych problemów w ramach funkcji AI
Praktyczna lista sprawdzająca – konkretne pytania kontrolne dla zespołów projektujących funkcje AI

Wprowadzenie

Produkty z wieloma funkcjami AI stają przed wspólnym wyzwaniem. Każdy zespół projektowy wymyśla własne rozwiązania, co prowadzi do chaosu w interfejsach i frustracji użytkowników. Katie McCoy z zespołu AI Framework w GitLabie przedstawiła doświadczenia z budowy systematycznego podejścia do wzorców projektowych dla AI.

Jak podkreśla McCoy, prezentacja dotyczy bardzo wczesnego etapu prac. Projektanci zostali przetasowani zaledwie tydzień wcześniej. Wcześniej pracowała nad konkretnymi funkcjami AI przypisanymi do zespołów inżynierskich, jednak teraz ma skupić się na wzorcach projektowych dla całej organizacji.

Kluczowe jest zrozumienie, kto stanowi główny cel tej pracy. McCoy precyzuje, że jej bezpośrednim „klientem” są wewnętrzne zespoły GitLaba – projektanci i deweloperzy. Usprawnienie ich pracy okazuje się najskuteczniejszą drogą do poprawy doświadczeń końcowego użytkownika.

Chaos w funkcjach AI – dlaczego potrzebujemy wzorców

Zgodnie z obserwacjami McCoy, GitLab ma wiele funkcji AI w różnych etapach dojrzałości. Problem polega na tym, że organizacja szybko rozwija się w przestrzeni AI i dlatego potrzebuje ustalić podstawowe standardy.

Długoterminowa wizja brzmi jasno: GitLab ma mieć kompleksowy zestaw wytycznych, wzorców projektowych i narzędzi zapewniających spójne doświadczenie użytkownika funkcji AI w całej organizacji.

McCoy zastanawia się nad praktycznym znaczeniem tej wizji. Z jednej strony wzorce mogą obejmować bardzo dosłowne rzeczy jak wygląd przycisku AI czy rodzaj ikony. Z drugiej strony dotyczą bardziej abstrakcyjnych kwestii jak informowanie użytkownika o kontekście, którym dysponuje AI.

Organizacja ma też szersze luki strategiczne – jak identyfikować które możliwości AI warto realizować, jaka jest przewaga GitLaba w krajobrazie AI, jak mierzyć sukces funkcji AI. McCoy świadomie ogranicza jednak swój fokus: skupia się na bardzo dosłownych rzeczach, które pomagają zespołowi już dziś. Takie podejście nazywa się w branży „table stakes” – absolutnymi fundamentami, które muszą być na miejscu, zanim zespół przejdzie do bardziej abstrakcyjnych rozwiązań.

Jako przykład podaje spójne wezwania do działania dla funkcji Duo, ale też bardziej złożone wyzwania specyficzne dla AI: „Wytyczne co robić, gdy AI nie produkuje rezultatu, którym użytkownik jest zadowolony – specjalne względy na to, że funkcje AI nie dostarczają przewidywalnego wyniku.”

Trzy poziomy niespójności w interfejsach AI

Elementy UI – najłatwiejsze do naprawienia

McCoy zidentyfikowała najbardziej podstawowy poziom problemów: niespójność w małych elementach interfejsu. Podczas audytu funkcji AI w GitLabie odkryła różnice w nazwach funkcji między dokumentacją a marketingiem, różne teksty na przyciskach wezwania do działania, a nawet różne ikony dla tych samych działań.

Jak opisuje swoje odkrycia: „Zrobiłam mały audyt tego, jak funkcja nazywa się w naszej dokumentacji, na stronie marketingowej, a potem call to action, nawet jaką ikonę używa – możemy być bardziej spójni.” Ten poziom jest stosunkowo prosty do standaryzacji.

Przepływy użytkownika – średni poziom złożoności

Drugi poziom dotyczy niespójności w przepływach. McCoy podaje przykład funkcji, gdzie AI pisze w edytorze tekstu – GitLab ma kilka przepływów, które dotykają tej funkcjonalności. Standaryzacja takich przepływów byłaby korzystna, choć McCoy rozumie, że niektóre funkcje będą miały swoje specyficzne wymagania.

Abstrakcyjne wzorce – największe wyzwanie

Najbardziej złożony poziom to abstrakcyjne wzorce interakcji. McCoy wymienia przykład: „AI wyjaśnia mi coś” – to bardzo ogólna kategoryzacja, jednak możliwe byłoby stworzenie najlepszych praktyk lub wytycznych dla projektantów.

Kluczowe pytania dla abstrakcyjnych wzorców:

Czy zbudowałeś mechanizm informacji zwrotnej?
Czy użytkownik może doprecyzować wynik, z którego nie jest zadowolony?
Jak użytkownik wie, co funkcja będzie robić i jak mu pomoże?
Jakie oczekiwania ustala interfejs wobec rezultatów AI?

McCoy widzi potencjał w standaryzacji przynajmniej listy sprawdzającej dla projektantów pracujących nad takimi przepływami.

Dodatkowy spostrzeżenie z analizy heurystycznej: podobne problemy użyteczności pojawiają się w wielu funkcjach AI. Dlatego byłoby interesujące zobaczyć, czy można rozwiązać te problemy raz, a potem zespoły mogłyby z nich korzystać, zamiast każdy zespół próbuje rozwiązać problem indywidualnie.

Wyzwania zespołów projektowych pracujących z AI

Złożoność ekosystemu i brak świadomości

Austin z zespołu identyfikuje fundamentalny problem: funkcje AI wykraczają poza zamknięty ekosystem aplikacji webowej. Działają w całym środowisku – od aplikacji webowej, przez rozszerzenia do VS Code i JetBrains, po portale klientów. Każda platforma ma własne wytyczne UX i ograniczenia, których projektanci wcześniej nie musieli brać pod uwagę.

Becca dodaje konkretny problem z perspektywy projektanta. Największym wyzwaniem jest trudność w poznaniu, jakie funkcje AI są obecnie w produkcie, jaki jest plan dojrzałości każdej funkcji zarówno z perspektywy funkcjonalności, jak i UI. W rezultacie projektanci często muszą pytać w kanałach UX AI czy ktoś pracuje nad podobnym rozwiązaniem, zamiast mieć centralny dostęp do informacji.

Dodatkowe wyzwania organizacyjne obejmują podstawowe kwestie infrastruktury. Jak McCoy zauważa, uruchomienie AI w środowisku programistycznym nie jest łatwe. To z kolei utrudnia projektantom testowanie i eksperymentowanie z funkcjami AI.

Problem kontekstu i oczekiwań użytkowników

Nick z zespołu zwraca uwagę na kluczowy problem techniczny: AI chat nie wie, w jakim kontekście znajduje się użytkownik. Z biznesowego punktu widzenia zapadła decyzja o uruchomieniu funkcji bez świadomości kontekstu.

Becca opisuje konkretny scenariusz problemu: z poziomu szczegółów podatności użytkownik kliknąłby na przycisk czatu, jednak system nie wiedziałby, że patrzy na podatność.

Nick przedstawia wizję technicznego rozwiązania. Ma nadzieję, że można naprawić to technicznie, żeby czat był świadomy wszystkiego, do czego użytkownik ma dostęp. Jego plan zakłada, że nawet jeśli początkowe doświadczenie będzie słabe, zespół uzyska cenniejszą informację zwrotną. Jeśli system wspiera wszystkie konteksty, nawet na słabym poziomie, zespół dostanie bardziej szczegółowe informacje – zamiast ogólnych skarg „to nic nie wie”, będzie mógł statystycznie analizować, jakich kontekstów użytkownicy faktycznie używają i na co się skarżą.

Wyzwania oznakowania w ograniczonej przestrzeni

Tyler podnosi problem praktyczny – w ograniczonej przestrzeni interfejsu trudno o jednoznaczną komunikację. Często komunikacja musi opierać się tylko na ikonach lub bardzo krótkich etykietach.

Konkretny przykład z IDE: na pasku stanu dual chat i sugestie kodu używają tej samej ikony. Gdy użytkownik wyłączy sugestie kodu, wygląda na to, że wszystkie funkcje AI są wyłączone, bo używają identycznego oznakowania. Podobny problem dotyczy ikony tanuki ze sparkles – ten sam symbol jest używany dla różnych, niezależnych funkcji AI, co wprowadza użytkowników w błąd.

Problem dotyczy też szerszego nazewnictwa: użytkownicy mówią „GitLab Duo” mając na myśli chat, jednak inne funkcje opisują nazwą funkcji jak „merge request summary”. Austin zauważa również zamieszanie z funkcjami, które wyglądają podobnie ale różnią się działaniem. Root cause analysis początkowo wydawał się Duo Chat – wychodzi w szufladzie podobnej do Duo Chat, wygląda prawie identycznie, mimo że to nie jest to samo.

Plan działania – od audytu do biblioteki wzorców

Sesje ideacyjne dla wspólnych problemów

McCoy planuje grupowe sesje ideacyjne dla projektantów pracujących nad funkcjami AI, skupione na wspólnych problemach użyteczności. Widziała wiele bardzo podobnych problemów w różnych funkcjach AI i dlatego dobrze byłoby podkreślić, że to problem istniejący w całej organizacji.

Pierwsza sesja ma się skupić na „ustalaniu właściwych oczekiwań” – jak użytkownik wie, co funkcja będzie robić i jak mu pomoże? Niektóre funkcje potknęły się o tę przeszkodę. W rezultacie zespoły będą miały przynajmniej początek rozwiązania do zbadania, wszyscy będą mogli sobie pomagać i uczyć się od siebie.

Podobne potrzeby zgłaszają inni projektanci – Vitika pyta czy format podawania promptu może liczyć się jako wzorzec. Opisuje funkcje zaprojektowane dla Duo, root cause analysis i inne, które pierwotnie zaprojektowane jako specyficzne dla kontekstu, po integracji mogą być dostępne z dowolnego miejsca używając standardowego podejścia jak „slash command RCIA job name”.

Audyt i dokumentacja istniejących funkcji

Drugi główny element planu to audyt wszystkich istniejących funkcji AI z identyfikacją luk i dokumentowaniem wzorców. McCoy definiuje typowe luki w funkcjach AI:

Brak mechanizmu informacji zwrotnej – jak użytkownik przekazuje GitLabowi opinię o funkcji AI?
Problemy z uprawnieniami – co się dzieje, gdy użytkownik nie ma odpowiedniego poziomu dostępu?
Niejasny kontekst AI – jakie informacje ma AI do udzielenia odpowiedzi?
Niespójne wezwania do działania – różne teksty i ikony dla podobnych funkcji

Rezultat audytu to pierwszy krok w kierunku biblioteki wzorców, zaczynając od łatwych rzeczy jak standaryzacja wezwań do działania i identyfikowanie przepływów nadających się do ujednolicenia.

Praktycznym rozwiązaniem problemu świadomości okazał się dokument, który McCoy przygotowała dla siebie. Wzięła heurystyki i umieściłą wszystkie funkcje AI w jednym miejscu – to było bardzo pomocne. Zastanawia się, czy nie należałoby po prostu opublikować tego pliku.

Zespół eksperymentuje też z godzinami konsultacji o bardziej ustrukturyzowanej agendzie – zamiast ogólnych rozmów, każdy dzieli się ekranem i pokazuje nieformalnie nad czym pracuje. Już pierwsze takie spotkanie przyniosło efekty – powstało kilka połączeń, których wcześniej nie było.

Wizja długoterminowa biblioteki wzorców

McCoy zastrzega, że termin „biblioteka wzorców” może nie być odpowiedni – wciąż szuka właściwych słów. Wzorce mają różną anatomię – mogą być nazywane szablonami lub zestawami naklejek.

Jak wyjaśnia: to nie ma być dogmatyczne i nie ma być jak system projektowy. Jeśli system projektowy to atomy, molekuły i organizmy, to jest bardziej jak organizm. Chodzi raczej o stworzenie „zestawu startowego” składającego się z gotowych komponentów i szablonów, który ułatwi pracę zespołom. Biblioteka ma pokazywać całe przepływy składające się z różnych komponentów:

Szerokie wzorce interakcji – „użytkownik rozmawia z AI w naturalnym języku” lub „AI wyjaśnia coś użytkownikowi”
Podkomponenty stanu – jak użytkownik wie, że AI wciąż pracuje nad odpowiedzią?
Kolekcje elementów – gdy treść generowana przez AI jest osadzona na stronie, jak sygnalizujemy, że to AI?
Język i ikonografia – jakich słów używamy, jakie ikony stosujemy?
Dostępne akcje – czy użytkownik może zregenerować treść? Jakie opcje ma?

Praktyczna lista sprawdzająca dla zespołów AI

Na podstawie doświadczeń zespołu GitLab, McCoy identyfikuje kluczowe pytania kontrolne:

Przy projektowaniu nowej funkcji AI

[ ] Jak użytkownik wie, co funkcja będzie robić i jak mu pomoże?
[ ] Czy zbudowałeś mechanizm informacji zwrotnej dla użytkownika?
[ ] Czy użytkownik może doprecyzować wynik, z którego nie jest zadowolony?
[ ] Jaki kontekst ma AI do udzielenia odpowiedzi?

Przy audycie istniejących funkcji

[ ] Jak użytkownik przekazuje informację zwrotną o tej funkcji AI?
[ ] Co się dzieje, gdy użytkownik nie ma odpowiedniego poziomu dostępu?
[ ] Czy wezwania do działania są spójne z innymi funkcjami AI?
[ ] Czy ikony i oznakowanie są jednoznaczne dla użytkownika?

Przykłady wzorców interakcji z AI

W trakcie dyskusji uczestnicy wskazali na konkretne prompty w formie komend, które są przykładem wzorca interakcji z AI. Standaryzacja ich formatu jest jednym z celów frameworku:

Prompt: /explain_vuln

Kiedy stosować: Komenda używana w oknie czatu GitLab Duo. Pozwala użytkownikowi poprosić o wyjaśnienie konkretnej podatności bezpieczeństwa, na którą aktualnie patrzy. Jest to sposób na wymuszenie działania kontekstowego w sytuacji, gdy czat nie jest jeszcze w pełni świadomy otoczenia.

Prompt: /rca <nazwa_zadania>

Kiedy stosować: Format komendy służący do uruchomienia analizy przyczyn źródłowych dla konkretnego zadania. Wzorzec /<komenda> <parametr> pozwala na wywołanie skomplikowanej akcji z dowolnego miejsca w aplikacji, dostarczając AI precyzyjnych danych do analizy.

Praktyczne wnioski dla zespołów produktowych

Mike z zespołu podnosi ważny punkt o patrzeniu w przyszłość. Widziałem, jak projektanci wykonują świetną robotę, jeśli komponenty lub wzorce są dostępne – korzystają z nich. Zazwyczaj widzimy rozbieżności we wzorcach i projektowaniu, gdy czegoś nie ma.

Moment innowacji pojawia się właśnie wtedy, gdy brakuje gotowego wzorca. Im bardziej przyszłościowe mogą być wzorce, tym lepiej – projektanci będą sięgać po gotowe rozwiązania zamiast wymyślać nowe. Jeremy dodaje praktyczny przykład: Pedro pracuje nad dual workflow, które jest bardziej przyszłościowe niż niektóre inne funkcje AI w aplikacji. To bardzo dobra informacja zwrotna, a gdy pracują nad dual workflow, pojawią się potrzeby nowych wzorców.

McCoy wyjaśnia różnicę w podejściach. Różnica między tym nad czym pracuje jej zespół a tym nad czym pracuje Pedro polega na tym, że oni pracują nad bardzo wąsko zakrojonymi funkcjami, podczas gdy funkcja Pedro automatyzuje dużą część workflow. Podąża za użytkownikiem przez produkt, może do IDE, z powrotem do produktu i AI robi wiele rzeczy w jego imieniu. To bardziej złożona interakcja i prawdopodobnie długoterminowa wizja, choć też na bardzo wczesnym etapie.

McCoy zgadza się z tym podejściem, jednak dzieli się lekcją z wcześniejszych prób. Na samym początku tego wysiłku pracowali nad kategoryzacją wzorców projektowych i ten plik Figma szybko się zakurzył, bo był trochę za daleko od rzeczywistości. Kluczem jest znalezienie balansu między przyszłościowym myśleniem a praktycznymi potrzebami dnia dzisiejszego.

Podsumowanie

Doświadczenia GitLaba pokazują, że systematyczne podejście do wzorców projektowych dla AI jest koniecznością, nie opcją. McCoy rozpoczyna od fundamentów – audytu, standaryzacji podstawowych elementów i budowania świadomości w zespołach, świadomie ograniczając fokus do rzeczy potrzebnych już dziś.

Najważniejsze lekcje dotyczą nie tylko designu, ale całej organizacji pracy. Zespoły potrzebują lepszej świadomości o tym nad czym pracują inni, łatwiejszego dostępu do narzędzi AI w środowisku programistycznym, oraz sposobów na nieformalne dzielenie się wiedzą.

Kluczowym spostrzeżeniem jest znaczenie balansu między pragmatyzmem a wizją przyszłości. Wcześniejsze próby tworzenia abstrakcyjnych kategoryzacji „zakurzyły się” bo były za daleko od rzeczywistości. Udane wzorce muszą być wystarczająco konkretne, żeby były użyteczne dziś, jednak na tyle uniwersalne, żeby skalować się w przyszłości.

Jak podsumowuje McCoy: zespół jest w bardzo wczesnych dniach – jednak kierunek jest jasny. Organizacje rozwijające wiele funkcji AI nie mogą pozwolić sobie na chaos. Potrzebują wspólnego języka projektowego, systematycznych procesów współpracy i praktycznych narzędzi, które sprawdzą się już dziś.

Kluczowy insight

Paradoks Wewnętrznego Klienta

Standardowo myślimy: Aby poprawić UX na dużą skalę, musimy skupiać się wyłącznie na badaniu i projektowaniu dla końcowego użytkownika.

W praktyce okazuje się, że: Największą dźwignię w skalowaniu jakości daje traktowanie wewnętrznych zespołów (projektantów, deweloperów) jak swoich głównych klientów. Usprawnienie ich pracy i narzędzi prowadzi do lepszych i spójniejszych produktów dla wszystkich.

Dlaczego to jest istotne: Takie podejście przenosi fokus z gaszenia pojedynczych pożarów na budowanie systemu, który zapobiega ich powstawaniu i multiplikuje dobre praktyki w całej organizacji.

Test na jutro: Następnym razem gdy będziesz planować zadania, zamiast dodawać kolejną małą poprawkę dla użytkownika, spróbuj dodać jedno zadanie, które usunie największą frustrację w pracy Twojego zespołu projektowego lub programistycznego i sprawdź, jak to wpłynie na jego tempo i jakość pracy w całym tygodniu.

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, znajdziesz je tutaj: https://www.youtube.com/watch?v=BvxFImVQXpQ

Wzorce projektowe dla AI – lekcje z transformacji GitLaba #EN299