Elementy User Experience w erze AI – jak 25-letni model projektowy odnajduje się w świecie algorytmów #EN347

Uwaga redakcyjna: To są notatki z prezentacji „The Elements of UX in the Age of AI” Jesse’ego Jamesa Garretta, wystąpienia poświęconego 25-leciu stworzenia modelu Elements of User Experience. Wszystkie tezy, obserwacje i wnioski pochodzą od Garretta, nie od autora tych notatek.

TL;DR

„Elements of UX” działa dziś jako mapa decyzji w pracy z AI
LLM-y mają wzmacniać, nie zastępować kompetencje zespołu
Klucz: dokumentacja przystępna dla ludzi i maszyn oraz systemy projektowe z interfejsem LLM
Projektuj pod probabilistykę: łatwe cofanie zmian, dialog, kontrolowana eksploracja
„Kto kontroluje polecenia, ten kontroluje produkt”
Ścieżka zmiany: eksperyment → pilotaż → podnoszenie kompetencji → szerokie wdrożenie + architektura poleceń

Jak model narodził się z desperacji

W marcu 2000 roku Jesse James Garrett stanął przed problemem. Jako information architect w niewielkiej agencji projektowej Studio Verso w San Francisco regularnie siadał na spotkaniach klienckich i rozglądał się po sali z rosnącą frustracją. Nikt nie wiedział, dlaczego tam jest. Tematy, które poruszał, wydawały się irrelewantne dla pozostałych uczestników. Jednak problem nie leżał w złej woli – information architecture było wówczas czymś całkowicie nowym.

Stanął przed dylematem egzystencjalnym. Bez umiejętności wytłumaczenia swojej wartości mógł stracić pracę. Dlatego potrzebował strukturalnego sposobu prowadzenia dialogu o decyzjach projektowych.

Chaos branży tech w roku 2000

Rok 2000 był momentem ekstremalnego chaosu w branży technologicznej. Garrett opisuje ten czas przez szereg charakterystycznych cech, które brzmią dziś zaskakująco znajomo w kontekście AI:

Web miał zaledwie kilka lat
Wszyscy – od najmniejszych startupów po korporacje – wymyślali wszystko na bieżąco
Nie istniały sprawdzone metody ani standardy
Inwestorzy i media wywierali presję, krzycząc, że każda firma musi mieć stronę internetową
Klienci rozumieli, jak kupować tradycyjne usługi projektowe, ale digital design był dla nich zagadką
Graficzne agencje reklamowe rozszerzyły ofertę o „Internet”, mimo że nie miały pojęcia, jak to robić
Zatrudniały samouków znających technologie webowe

To właśnie w tym chaosie Garrett był jednym z takich samouków.

Od chaosu do diagramu

Garrett rozpoczął pracę od porównywania decyzji podejmowanych przy tradycyjnych projektach graficznych z nowymi decyzjami wymaganymi w środowisku interaktywnym. Sporządzał listy, sortował tematy rozmów z klientami i układał je w siatki. Początkowo nic nie działało.

Widział rozróżnienie między tradycyjnymi aspektami (treść, typografia) a nowymi warstwami funkcjonalności. Mimo prób uporządkowania i przesuwania elementów, nic nie pasowało do siebie.

Pewnego dnia wracał z podróży służbowej. Idąc przez lotnisko, poczuł, jak jego umysł „skręca za róg” i nagle zobaczył coś, czego wcześniej nie dostrzegał. Rozwiązaniem było obrócenie niektórych stosów pomysłów i spłaszczenie ich w płaszczyzny, co pozwoliło im łączyć się na różne sposoby.

Natychmiast po wejściu do samolotu wyciągnął notes i naszkicował pierwszy trójwymiarowy widok elementów user experience. Mimo że wciąż nie wszystko było dopracowane, wrócił do San Francisco i stworzył pierwszy w pełni dopracowany szkic.

Z tego szkicu powstał dokument opublikowany 30 marca 2000 roku – prawie dokładnie 25 lat przed prezentacją.

Pięć płaszczyzn, zero polityki

Garrett podkreśla istotny kontekst historyczny: w momencie publikacji 30 marca 2000 roku prawie nic z tego, co uchwycił w modelu, nie było jeszcze zdefiniowane. Terminologia była mglista, płynna, gąbczasta.

Najgąbczastszym terminem było samo „user experience”. Nie istniał jeszcze skrót UX. To nie było stanowisko pracy, nie było procesów UX. Ledwo istniała społeczność, nie było książek ani kursów. Był to jedynie abstrakcyjny pomysł.

Jednak najważniejsze było to, że nie istniała polityka wokół tych terminów. Nikt jeszcze nie był emocjonalnie przywiązany do etykiet. Pod pewnymi względami był to niewinny czas.

Pięć płaszczyzn decyzji

Model organizuje decyzje wzdłuż continuum od abstrakcyjnych na dole do konkretnych na górze. Przy czym decyzje z niższych płaszczyzn wpływają na te wyżej:

1. Strategia (Strategy)
Odpowiada na pytania: Co chcemy osiągnąć? Czego chcą użytkownicy?

2. Zakres (Scope)
Przekształca strategię w wymagania i definiuje funkcje, które produkt musi zawierać.

3. Struktura (Structure)
Określa, jak elementy łączą się i zachowują w przepływach, tworząc page-level pieces lub flow przez strony i ekrany oraz dynamikę użytkownika.

4. Szkielet (Skeleton)
Opisuje konkretne komponenty na poziomie strony oraz definiuje elementy umożliwiające użycie struktury.

5. Powierzchnia (Surface)
Obejmuje wygląd i feel – pierwsze, co widzi użytkownik.

Model można podzielić pionowo na dwa sposoby patrzenia: produkt jako platforma technologiczna i produkt jako źródło informacji. Dwoistość ta, jak zauważył później Garrett, jest wbudowana we wszystkie technologie informacyjne, nie tylko w web.

Globalna podróż modelu

Po opublikowaniu w 2000 roku stały się rzeczy, których Garrett się nie spodziewał. Pierwszym, który stworzył tłumaczenie Elements, był Javier Velasco – przetłumaczył model na hiszpański. Następnie przyszła Livia Labate z portugalskim oraz Antonio Volpone z włoskim. Potem nastąpiła eksplozja: słoweński, wietnamski, chiński i dziesiątki innych języków.

Wszyscy ci ludzie wolontaryjnie poświęcili swój czas, energię, wiedzę i umiejętności wielojęzyczne, żeby uczynić tę pracę bardziej dostępną.

Drugi oddech: książka jako podręcznik

Globalne zainteresowanie doprowadziło do oferty wydawniczej. W 2002 roku Garrett napisał pierwszą edycję książki, która prawie całkowicie przypadkiem okazała się świetnym podręcznikiem. Z powodu struktury, sposobu uproszczenia i organizacji decyzji, książka stała się doskonałym wprowadzeniem do tej dziedziny.

Druga edycja przyszła w 2010, gdzie Garrett rozszerzył model poza web, mówiąc szerzej o produktach cyfrowych. Następnie przyszły tłumaczenia na całym świecie.

Żywotność modelu: od lodowych gór po tęcze

Inspiracja, którą Elements stworzył w świecie, była fascynująca. Z jakiegoś powodu ludzie ciągle chcieli go przerysowywać. W obiegu funkcjonują liczne wizualizacje:

Spłaszczenia – niektóre wizualizacje tracą trójwymiarowość (co według Garretta odbiera część wartości)

Rozszerzenia – inne dodają aktywności i deliverables, schodki, koła w kołach, birthday cakes

Warianty z programowaniem – pojawiają się wersje z „programming” na dole lub na górze

Zakrzywione „tęcze” – niektóre zginają płaszczyzny w łuki

Jednak zdecydowanie najpopularniejszym sposobem wizualizacji Elements stały się lodowe góry. Garrett nie rozumie, co jest takiego fascynującego w metaforze góry lodowej, ale faktycznie jest ich tam mnóstwo.

Czasami coś ważnego ginie w uproszczeniu tego i tak już prostego modelu.

Co sprawia, że to działa

Garrett analizuje, dlaczego model okazał się tak funkcjonalny w tak wielu kontekstach. Identyfikuje pięć właściwości będących fundamentem jego skuteczności:

Alignment dzieli przestrzeń problemową na uporządkowane obszary, wyrównuje te obszary z różnymi sposobami patrzenia na problem i tworzy balans w ramach każdej płaszczyzny.

Balance godzi różne względy, które muszą się spotkać na każdej płaszczyźnie.

Clarity pozwala skupić się na poszczególnych domenach i zidentyfikować ograniczenia.

Focus sprawia, że decyzje na każdej płaszczyźnie definiują i ograniczają decyzje na płaszczyznach wyższych.

Decisiveness tworzy momentum w kierunku rozwiązania na każdym etapie procesu.

Garrett ilustruje to zygzakowatym wzorem. W ramach każdej płaszczyzny istnieje zakres możliwych wyborów – „przestrzeń możliwości”. Jednak wybory, które podejmujesz, zawężają zakres dostępny wyżej. Poruszasz się więc zygzakiem przez zawężające się przestrzenie możliwości, aż dojdziesz do rozstrzygnięć.

Model to narzędzie do lepszych rozmów o intencjach i ich konsekwencjach. Tworzy wspólne rozumienie relacji między decyzjami, systematyzuje jakościowe, nieprogramowalne decyzje oraz daje sposób uczenia kogoś, jak myśleć o problemie razem z tobą.

Długa podróż Garretta z AI

Garrett używa konkretnej definicji AI, z którą pracuje od lat: systemy, które dostosowują swoje zachowanie w oparciu o ekspozycję na dane. To jest innowacja, którą reprezentuje sztuczna inteligencja i machine learning – idea, że można nakarmić coś wieloma przykładami, a ono dostosuje i zmodyfikuje własne zachowanie w oparciu o to.

Najwcześniejsze ślady jego myślenia o AI pochodzą z wystąpienia z 2004 roku zatytułowanego „Frontiers of User Experience”. Wówczas mówił o „instrumentowanych interfejsach” – technologiach typu wizjer Jordy’ego LaForge’a, które pozwoliłyby bliżej obserwować zachowania użytkowników. Przewidywał, że te interfejsy dostarczą wystarczająco dużo danych, by algorytm mógł kształtować doświadczenia i dostosowywać je do potrzeb użytkowników.

Już wtedy ostrzegał przed konsekwencjami etycznymi związanymi z prywatnością użytkowników. Mimo to prezentacja była dla niego frustrująca, ponieważ nic z tego jeszcze nie istniało.

Co się sprawdziło, a czego nie przewidział

Instrumentowane interfejsy przekształciły się w dzisiejszą analitykę, która stała się fundamentem wielu praktyk w digital product design. Algorytmy kształtujące doświadczenia powstały, podobnie jak customizacja doświadczeń do potrzeb użytkowników.

Jednak Garrett naprawdę wierzył, że to designerzy będą tworzyć algorytmy i że design będzie ustalał zasady ewolucji doświadczeń. Nie przewidział wzrostu growth hackerów i mniej user-centrycznych podejść. Nie spodziewał się także całej branży podwajającej stawkę na „schmethics” – grę słów od „ethics”.

Mozilla, Capital One i poskramianie lwów

Kolejne spotkanie z AI nastąpiło w projekcie dla Mozilla Labs (2007-2008). Garrett prowadził zespół tworzący wizję internetu w dalekim przyszłym roku 2018. Wiele przewidzieli trafnie, jednak centralna część nie zmaterializowała się.

Wyobrażali sobie, że przeglądarka sama będzie systemem AI – copilot dla całego doświadczenia internetowego. System znajdowałby wzorce w zachowaniach użytkownika, grupował podobne elementy i semantycznie organizował osobistą przestrzeń informacyjną według tego, co było najbardziej relewantne. Wyszukiwanie pogody wyglądałoby inaczej w kontekście sadzenia wiosennego ogrodu niż planowania wyjazdu na narty.

Kilka lat później Garrett znalazł się w Capital One, gdzie AI był w powietrzu. Firma zainwestowała ogromne środki w machine learning, a zespół designu chciał być na czele i mieć mocny punkt widzenia. Uruchomili wiele inicjatyw:

Eno – chatbot obsługi klienta z niezwykle wyrafinowanym algorytmem machine learning responsywnym na emocjonalny stan rozmowy. Niestety większość tej pracy nigdy nie ujrzała światła dziennego. Rynkowa wersja Eno różni się od prototypu.

Humanity AI – seria wydarzeń łącząca ekspertów na przecięciu UX i AI, mająca na celu budowanie wewnętrznego przywództwa w organizacji.

Responsible AI – Garrett spędził ponad rok jako szef tego zespołu, pomagając budować strukturę prewencyjnej redukcji szkód przez wewnętrzny nadzór, z mocnym naciskiem na transparentność, wytłumaczalność i głębokie rozumienie wpływu technologii na użytkowników.

Lew kontra pies: kluczowa metafora

W jednym ze spotkań zespołowych Garrett sformułował obserwację, która towarzyszyła mu od tamtej pory w całej pracy z AI. Stwierdził, że ludzie myślą o tym jak o tresurze psa, podczas gdy w rzeczywistości jest to poskramianie lwa. Różnica polega na tym, że można skończyć tresować psa, natomiast nigdy nie kończy się poskramiać lwa, ponieważ lew nigdy nie jest naprawdę oswojony.

Dwa przełomy, które wszystko zmieniły

Około 2014 roku AI stało się super-skalowalne dzięki dwóm artykułom naukowym. Alex Krushevsky udowodnił w 2014, że nie potrzebujesz wielkich superkomputerów jak te od IBM – wystarczy mnóstwo kart graficznych (GPU dla sieci neuronowych). W 2017 grupa badaczy stworzyła model Transformer, architekturę oprogramowania umożliwiającą jeszcze większą skalowalność.

Nagle wszystko, co było tylko teoretyczne w XX wieku, stało się realne. Wystarczyło dużo pieniędzy na centrum danych i dużo danych do nakarmienia.

Ciemna strona AI

Garrett nie ukrywa problemów. Wszyscy gonią rynkową okazję z lekkomyślnym porzuceniem ostrożności, a to porzucenie jest rzeczywiście lekkomyślne.

Dane, na których trenowane są te modele, pochodzą zewsząd i skądkolwiek – często bez pozwolenia, często wątpliwymi metodami, często z wątpliwych źródeł. W AI jest wiele podejrzanych praktyk i musimy uznać tę prawdę.

Lista problemów jest długa:

Znaczące obawy o wybory firm dotyczące fair use
Znaczące obawy o miejsca pracy i źródła utrzymania ludzi
Znaczące obawy o wpływ na klimat

Ale dla digital product design to nowy materiał

Garrett zauważa, że pewnie są branże, gdzie AI nigdy nie zrobi wielkiego wpływu. Jednak dla tych, którzy pracują w projektowaniu i rozwoju produktów cyfrowych, konieczne jest zaangażowanie się z tym jako z nowym surowym materiałem.

Wielkie inicjatywy zaczęły karmić masywne ilości danych do algorytmów. Cel był prosty: zbudować wielką kulę matematyki, która miała tylko przewidywać następne słowo w zdaniu.

Zaczęło się od czatu, ale stało się coś zadziwiającego. System okazał się dobry w znacznie więcej niż tylko czat. Nigdy nie był zaprogramowany do robienia matematyki, a potrafi robić matematykę. Jeśli prawie każdy problem da się przekształcić w coś podobnego do języka, można użyć LLM do jego eksploracji. Dlatego tak wiele współczesnych produktów i funkcji AI ma LLM w rdzeniu, nawet jeśli czat nie jest modelem interakcji.

Jak rozumieć LLM: trzy operacyjne metafory

Garrett używa trzech metafor, które pomagają zrozumieć, jak faktycznie działają LLM-y i jak z nimi pracować.

1. Play-Doh Fun Factory: proces „ściskania”

Play-Doh Fun Factory to ulubiona zabawka amerykańskich dzieci z klasy średniej przez dekady. Dostarcza sposób na przekształcenie niewyróżniającej się kuli glutu z puszki Play-Doh w ciekawszy kształt.

To jest zasadniczo sposób działania LLM. Zrobili wielką kulę matematyki, a twoja praca polega na wsadzeniu jej do prasy i ustawieniu małych ekstruderów tak, żeby dostać coś, co jest mniej więcej w pożądanym kształcie.

Proces zawężania:

Pre-training (P w GPT) – GPT oznacza Generative Pre-trained Transformer. Transformer to podstawowa architektura technologiczna, a pre-training to proces, który kształtuje to w coś faktycznie używalnego przez ludzi, ale używalnego w dość szerokim zakresie przypadków użycia.

System prompts – jeśli chcemy zawęzić do bardziej konkretnego przypadku użycia, musimy nałożyć systemowe polecenia, które zawężają fokus i dają więcej kierunku dla pracy LLM.

User context – dostarczenie dodatkowego kontekstu przez użytkownika.

Iteration – dodatkowa iteracja promptowania, żeby kontynuować rafinację i wyostrzenie, aż ostatecznie dostaniemy coś tak skupionego, że możemy przekształcić rozproszone światło w wiązkę lasera.

2. Context overload sickness: paradoks kontekstu

Jeśli masz właściwy kontekst i ustawiłeś go wystarczająco wąsko, możesz trzymać losowość, która jest częścią tych modeli, w ryzach.

Niektórzy myślą: co jeśli po prostu zmaksymalizujemy kontekst? Co jeśli mielibyśmy nieskończenie duże okna kontekstowe i te niesamowicie ogromne podstawowe LLM? Czy to nie rozwiązałoby problemu?

Dzieje się jednak ciekawa rzecz. Jeśli nakarmisz LLM za dużo kontekstu, dostajesz coś, co Garrett nazywa „context overload sickness”.

Myślenie maszyny zaczyna robić się rozmazane. Garrett widział LLM dosłownie wpadające w analysis paralysis, bo próbują połączyć za dużo rzeczy z za wielu kierunków. Albo po prostu schodzą na tangentę, która nie ma nic wspólnego z tematem rozmowy.

To jest szeroko obserwowane, ale słabo rozumiane zjawisko, które kształtuje sposób, w jaki angażujemy się z tą technologią.

3. Magic Cocoa Puff Machine: potrzeba detektora bzdur

Cocoa Puffs to popularne w USA czekoladowe płatki śniadaniowe – małe, czekoladowe kulki.

Wyobraź sobie, że LLM to magiczna maszyna produkująca nieskończone ilości Cocoa Puffs. Byłoby świetnie, czy jesteś osobą jedzącą płatki, czy prowadzisz biznes płatkowy. Jest jednak jeden problem. W losowych, nieprzewidywalnych momentach z maszyny nie wychodzi Cocoa Puff, lecz królicza bobka – wizualnie nie do odróżnienia od Cocoa Puffa.

Jeśli nie potrafisz odróżnić Cocoa Puffa od króliczej bobki, będziesz miał problem z obsługą magicznej maszyny. Losowość wbudowana w system tworzy probabilistyczny charakter. Zawsze musisz monitorować swój stosunek króliczych bobków do Cocoa Puffs.

Musisz przynieść własny detektor króliczych bobków. Musisz potrafić zidentyfikować, gdzie maszyna zboczyła z kursu. Musisz mieć zdanie o tym, co działa, a co nie. Nie możesz prosić jej o wiedzę, której sam nie masz, ponieważ z natury najlepsza będzie w przeciętności.

Kluczowa prawda: LLM nic nie wie, niczego nie rozumie. Symuluje wiedzę i symuluje rozumienie. Jednak wszystko, czego naprawdę chce, to twoja aprobata. Tak te systemy zostały wytrenowane i zbudowane. Twoją odpowiedzialnością jest wybór, kiedy dajesz tę aprobatę i w odpowiedzi na co.

Kto kontroluje prompt, kontroluje produkt

Garrett widzi, jak to się rozwija w organizacjach, z którymi pracuje. Jest bardzo podobne do wzorców, które obserwował w digital product design przez lata.

W sercu projektowania produktów cyfrowych istnieje walka, napięcie między tym, co najlepsze dla użytkowników, a tym, co tworzy wzrost dla biznesu. Wszyscy w tej dziedzinie byli uwikłani w to przeciąganie liny przez ostatnie 25 lat.

Garrett podkreśla coś kluczowego: jeśli chcesz, żeby produkty cyfrowe stały się bardziej user-centered w następnej generacji, musisz zrozumieć, że w workflow opartym na AI kto kontroluje prompt, kontroluje produkt.

Język używany do opisywania warunków produktu, wymagań produktu, będzie bardziej bezpośrednio połączony z wynikami niż kiedykolwiek wcześniej. Z tego powodu zespoły projektowe muszą wystąpić z mocnym punktem widzenia na szansę produktową, szansę użytkownika oraz kapitalizować na tym przez kultywowanie prompt work jako ogólnozespołowej dyscypliny rzemieślniczej.

Konsekwencje organizacyjne:

Własność poleceń (promptów) wyznacza kierunek produktu
Potrzebne zespołowe rzemiosło pracy z poleceniami, nie „samotny guru”
Najpierw jasny punkt widzenia na użytkownika i szansę produktową, dopiero potem automatyzacja

Prompt craft vs prompt engineering

Garrett używa terminu „prompt craft” zamiast „prompt engineering”. Jak dotąd nie czuje, żeby to było jeszcze engineering, ponieważ nie ma poziomu matematycznej pewności, jakiego oczekuje w inżynierii.

Dla niego to bardziej przypomina wyrabianie ceramiki niż spawanie stali. Jest to jednak w porządku dla digital product design, ponieważ designerzy zawsze byli rzemieślnikami. Rzemiosło to improwizacja, nie matematyczna pewność. To taniec między twórcą a materiałem – dokładnie taki rytm i wzorzec zaangażowania jest niezbędny przy tych technologiach.

Profil idealnego prompt engineera

Idealny prompt engineer dla produktów cyfrowych powinien łączyć cztery kluczowe kompetencje:

Techniczna biegłość – świadomość technologii i jak je używać

Świadomość użytkownika – zdolność rozumienia perspektywy ludzi, którzy używają tego, co tworzymy

Wizualizacja doświadczeń – umiejętność „widzenia” UX

Ekspresja językowa – zdolność przekładania wszystkiego powyżej na słowa, które można podać maszynie, by uzyskać znaczący wynik

Elements w świecie AI: gdzie jest realna dźwignia

Garrett widzi konkretny sposób zastosowania modelu Elements w sferze AI dla UX. AI ma augmentować decyzje, nie zastępować ekspertów. Model można użyć do:

Rozbicia przypadków użycia w procesie rozwoju
Szukania możliwości augmentacji ekspertyzy
Analizy luk – zauważenia, gdzie alignment jest złamany w górę i w dół stosu modelu
Godzenia trade-offów w ramach płaszczyzn
Syntezy i znajdowania wzorców

Human-machine readable documentation

Garrett porusza coś ważnego, o czym mało kto mówi: jeśli masz workflow oparty na AI, będziesz potrzebować human-machine readable documentation. Dokumentacji pomysłów, która jest łatwa do skonsumowania dla maszyny, ale też użyteczna dla ludzi w zespole.

Gdy to posiadasz, staje się bardzo łatwo generować bazowe implementacje, prototypy i funkcjonalne demonstracje pomysłów UX. Taki materiał zasila systemy tak, aby generowały bazowe implementacje i prototypy, co skraca drogę od idei do działającego dowodu.

Garrett widzi linię przecinającą model w poprzek środka:

Powyżej linii – działają design systems z interfejsem LLM. Trudno mu wyobrazić sobie design systems za 10 lat bez LLM jako głównego interfejsu. Wydaje się to naturalną ewolucją tych systemów – żeby ostatecznie były czymś, z czym rozmawiasz i co tworzy dla ciebie design.

Poniżej linii – leżą struktury danych, które te systemy potrafią przetworzyć. Te sformalizowane sposoby strukturyzowania danych umożliwiają łatwe wchłonięcie do design systemu, który może stworzyć user experience.

Cztery rzeczy, które przynoszą tylko ludzie

To brzmi jak coś bez żadnego czynnika ludzkiego. Garrett widzi jednak cztery naprawdę ważne rzeczy, które ludzie wnoszą do tej pracy:

Imagination – zdolność widzenia czegoś, co nigdy nie mogło być

Intuition – zdolność widzenia czegoś, czego nie można udowodnić

Inspiration – zdolność łączenia jednego sposobu widzenia z innym

Insight – zdolność widzenia czegoś z perspektywy kogoś innego

Projektowanie dla nieprzewidywalności: UX dla produktów AI

W kontekście robienia UX dla produktów AI przytłaczającym wyzwaniem jest to, że nic nie jest już w 100% przewidywalne. Musisz projektować dla probabilistycznego zachowania i wyników.

Z powodu tego probabilistycznego charakteru interakcja użytkownika nie jest tak prosta. Musisz stworzyć przestrzeń w aplikacjach dla wzorców zabawy, eksperymentowania i uczenia się użytkownika – nie tylko machine learning.

Zasady projektowania pod probabilistykę:

Łatwe cofanie zmian – spraw, żeby było naprawdę łatwo cofać się, obniżyć koszt błędów i ułatwić popełnianie pomyłek

Dialog jako wzorzec – mimo że ostatnio dużo się mówi o „multimodalnym AI”, gdzie użytkownicy angażują się z AI przez wiele interfejsów, nawet jeśli nie jest to doświadczenie czatu, dialog wciąż jest fundamentalnym wzorcem zachowania. Ten taniec między użytkownikiem a maszyną: wymiana, korekta kursu, cofnięcie.

Kontrolowana eksploracja – przestrzeń na eksperymenty w bezpiecznych ramach

Information architecture jest absolutnie vitalna dla jakości danych i konsumpcji przez maszyny. Bez information architecture nie ma human-machine readable documentation. Bez information architecture nie ma wielu korzyści z LLM. To wszystko sumuje się do więcej ogrodnictwa i mniej murowania – znacznie bardziej organicznego podejścia do rozwoju produktów niż widzieliśmy wcześniej.

Ścieżka transformacji zespołu: 6 kroków

W rozmowach z liderami designu w ostatnich latach Garrett widział, jak model journey transformacji AI dla zespołów produktowych zaczyna się wyłaniać.

1. Assess the opportunity (Ocena potencjału)
Zidentyfikuj przypadki użycia i znajdź miejsca, gdzie akceleracja może dostarczyć wartość.

2. Square those use cases (Zestrojenie z procesem i technologią)
Dopasuj do faktycznego workflow i faktycznej technologii. Jeśli jesteś znormalizowany na platformach łatwo współpracujących z LLM, będziesz mieć inne opcje.

3. Build up hypotheses (Eksperymenty i hipotezy)
Zaprojektuj i eksperymentuj, wypróbuj coś, udowodnij pomysły oraz zacznij rafinować prompt craft.

4. Take experiment to pilot (Pilotaż w kontrolowanym zakresie)
Zintegruj nowe narzędzia w workflow w wąskim, kontrolowalnym kontekście oraz kontynuuj rafinację i wychwytywanie learningów.

5. Upskill your team (Podnoszenie kompetencji)
Skaluj możliwości zespołu, naucz ich, czego się nauczyłeś o tym, jak angażować się z systemem i jak redukować losowość oraz produkować bardziej niezawodne wyniki.

6. Roll it out (Wdrożenie na szeroką skalę)
Wdróż we wszystkich workflow i work streams.

Infrastruktura potrzebna do transformacji

Żeby dotrzeć do wyższych etapów tej podróży, będziesz potrzebować infrastruktury. Będziesz potrzebować prompt architecture – sposobu, w jaki ludzie mogą kolaboratywnie pracować z językiem promptów, żeby tworzyć konsystentne wyniki. Będziesz także potrzebować strukturalnego sposobu podejmowania decyzji przez dialog – w tym przypadku dialog między ludźmi i maszynami.

Skalowanie wymaga architektury poleceń i ustrukturyzowanego dialogu człowiek–maszyna.

Architektura poleceń: cechy skutecznego podejścia

Garrett zadaje pytanie: jak wygląda skuteczna prompt architecture? Powinna mieć następujące cechy:

Narzędzie do lepszych rozmów o intencjach i implikacjach
Tworzy wspólne rozumienie relacji między decyzjami do podjęcia
Mapa do przekształcania możliwości w decyzje w sposób kierowany celem
Systematyzuje jakościowe, nieprogramowalne decyzje
Progresywnie zawęża przestrzeń możliwości, gdy każdy zestaw decyzji dostarcza kontekst dla następnego
Daje sposób uczenia kogoś lub czegoś, jak myśleć o problemie z tobą

Innymi słowy – jeśli tworzysz prompt architecture na skalę, będziesz potrzebować czegoś, co wygląda bardzo podobnie do Elements of User Experience.

Tree of Thoughts i modele płaszczyznowe

Garrett pokazuje diagram z artykułu naukowego, który wyszedł nieco ponad rok temu – grudzień 2023. Opisuje zaawansowaną technikę prompt engineering zwaną Tree of Thoughts.

To podejście do prompt architecture wymaga ograniczania opcji na każdym etapie procesu decyzyjnego i podejmowania decyzji, które tworzą ograniczenia downstream w przepływie promptów.

Diagram wygląda znajomo. Jest bardzo podobny do tego z książki Garretta z 2002 roku. Ponieważ ich model idzie od góry do dołu, a jego od dołu do góry, Garrett obraca swój.

Oba diagramy opisują dokładnie ten sam pomysł.

To jest stan sztuki prompt engineering teraz. Pomysł tworzenia narzędzia do rozbijania złożonego problemu na dyskretne przestrzenie możliwości. Narzędzie, które może napędzać alignment, balance i clarity, żeby tworzyć decisiveness razem – ludzi i maszyn.

Współczesne podejścia, takie jak „Tree of Thoughts”, odwzorowują tę samą ideę: rozbijanie problemu na dyskretne przestrzenie możliwości i sekwencyjne zawężanie. Różni się kierunek osi, nie mechanika. Dlatego „Elements” można traktować jako szkielet architektury poleceń i prototyp rodziny modeli decyzyjnych.

Gdy umysł skręcił za róg – po raz drugi

To miał być ostatni slajd prezentacji. Jednak gdy Garrett pracował nad prezentacją i myślał o tych pomysłach, patrzył na diagram, z którym spędził tyle czasu. Nagle było tak, jakby jego umysł skręcił za róg i mógł zobaczyć coś, czego wcześniej nie potrafił dostrzec.

Co jeśli najważniejsza rzecz w Elements of User Experience w ogóle nie ma nic wspólnego z user experience?

Co jeśli najważniejsza rzecz w Elements of User Experience to to, co mówi o strukturalnym podejmowaniu decyzji?

Co jeśli ten model był tylko prototypem dla całego wszechświata modeli?

Wszechświat planar concept models

Garrett wyobraża sobie modele, które mają większą głębię. Gdzie można stworzyć nie tylko continuum od góry do dołu, ale continuum wzdłuż osi Z również. Modele, które rozbijają rzeczy na jeszcze więcej płaszczyzn i jeszcze więcej podziałów. Większe, bardziej złożone, bardziej „splatane” modele stanowiące cały wszechświat sposobów wychwytywania przestrzeni możliwości.

Planar concept models – narzędzie do kolaboratywnego podejmowania decyzji przez ludzi i maszyny w złożonych przestrzeniach problemowych.

Miałoby następujące właściwości: model trójwymiarowy, organizujący decyzje w domeny, grupujący te domeny w horyzontalne płaszczyzny według wspólnych trosk, wyrównujący te domeny pionowo z upstream domenami, które ograniczają, separujący pionowe stosy domen według wspólnego spojrzenia na przestrzeń problemową oraz zorganizowany w progresję od dołu do góry w rozwiązywaniu decyzji.

Jak to się kończy? Nie wiadomo

Garrett przyznaje szczerze, że dosłownie nie wie, co się stanie dalej. Jest dużo zmiennych. Wie jednak, że skąd to pójdzie, zależy od nas wszystkich.

Jest nadzwyczajna możliwość robienia wielkich rzeczy z tą technologią i tworzenia wielkiej szkody.

Garrett wierzy jednak, że twórcy z wyobraźnią, intuicją, inspiracją i wnikliwością mogą rozwijać rzemiosło potrzebne do kierowania tą technologią. Wykorzystać wszystko, co może dla nas zrobić, a jednocześnie wykorzystać wszystko, co przynosimy z bycia ludźmi.

Na koniec prezentacji Garrett ogłosił, że wydziela pracę z AI ze swojej praktyki coachingu liderów. Obecnie oferuje konsulting strategii transformacji AI dla zespołów produktów cyfrowych.

📋 MINI-CHECKLISTA WDROŻENIA

Podstawy

Zmapowane use case’y augmentacji do płaszczyzn „Elements”
Właściciele poleceń i zasady wersjonowania
Spójne formaty kontekstu przystępne dla ludzi i maszyn
Interfejs wspiera łatwe cofanie zmian, eksplorację i dialog

Proces

Plan „eksperyment → pilotaż → podnoszenie kompetencji → szerokie wdrożenie” wdrożony w rytmie sprintów
Architektura poleceń jako wspólny język zespołu
Regularny audyt ratio „Cocoa Puffs vs rabbit poop”

📋 CHECKLISTA: Czy Twój zespół jest gotowy na transformację AI?

Detektor króliczych bobków – gotowość zespołu

Czy masz własną wiedzę ekspercką?

Zespół potrafi samodzielnie ocenić jakość outputu AI
Mamy ekspertów domenowych, którzy mogą weryfikować wyniki
Rozumiemy, gdzie AI może popełnić błędy w naszej dziedzinie

Czy rozumiesz probabilistyczny charakter AI?

Akceptujemy, że nic nie będzie w 100% przewidywalne
Projektujemy dla eksperymentowania i uczenia się
Mamy nisko ustawiony koszt błędów i łatwy backtrack

Czy unikasz context overload sickness?

Rozumiemy, że za dużo kontekstu może sprawić, że LLM „robi się rozmazany”
Wiemy, jak zawęzić kontekst wystarczająco, żeby utrzymać fokus
Obserwujemy, czy model nie wpada w analysis paralysis

Czy masz odpowiednią infrastrukturę?

Posiadamy human-machine readable documentation
Nasze design systems są gotowe na integrację z LLM
Mamy uporządkowaną information architecture

Kto kontroluje prompt w Twojej organizacji?

Zespół projektowy ma mocny punkt widzenia na produkt
Prompt craft jest traktowany jako zespołowa dyscyplina
Designerzy są zaangażowani w tworzenie promptów

6 kroków transformacji AI – gdzie jesteś?

Krok 1 – Oceniliśmy możliwości i zidentyfikowaliśmy use cases
Krok 2 – Dopasowaliśmy use cases do naszego workflow i technologii
Krok 3 – Zbudowaliśmy hipotezy i przeprowadziliśmy eksperymenty
Krok 4 – Uruchomiliśmy pilotaż w kontrolowanym kontekście
Krok 5 – Przeszkoliliśmy zespół w prompt craft
Krok 6 – Wdrożyliśmy AI we wszystkich workflow

Profil idealnego prompt engineera – czy masz takich ludzi?

Idealny prompt engineer łączy:

Techniczną biegłość (zna technologie i wie, jak ich używać)
Świadomość użytkownika (rozumie perspektywę użytkowników)
Wizualizację doświadczeń (potrafi „zobaczyć” UX)
Ekspresję językową (przekłada wszystko powyższe na język dla maszyn)

4 niezbędne czynniki ludzkie – czy je wykorzystujesz?

Imagination – wykorzystujemy zdolność widzenia tego, co nigdy nie było
Intuition – doceniamy zdolność widzenia tego, czego nie można udowodnić
Inspiration – łączymy różne sposoby patrzenia na problem
Insight – widzimy problem z perspektywy innych (zwłaszcza użytkowników)

Pamiętaj o lwie, nie o psie

Rozumiemy, że AI to poskramianie lwa, nie tresura psa
Nie traktujemy AI jako „skończonego” – to ciągła praca
Jesteśmy przygotowani na ciągły nadzór i iterację

Kluczowy insight

Mniej kontekstu, lepszy wynik

Standardowo myślimy – Im więcej kontekstu w poleceniach i im większe okno kontekstowe, tym lepszy rezultat.

W praktyce okazuje się, że – Precyzyjnie przycięty, ustrukturyzowany kontekst dopasowany do aktualnej płaszczyzny decyzji (strategy/scope/structure/skeleton/surface) daje trafniejsze i stabilniejsze odpowiedzi. Zbyt szeroki kontekst wywołuje „context overload sickness” i paraliż.

Dlaczego to jest istotne – Ograniczenie szumu zmniejsza halucynacje, przyspiesza przejście przez „przestrzenie możliwości” i poprawia powtarzalność wyników. Sukces nie polega na maksymalizowaniu danych, ale na precyzyjnym ich dozowaniu. Jak w metaforze Play-Doh Fun Factory – potrzebujesz odpowiedniego ściśnięcia (pre-training → system prompts → user context → iteration), żeby przekształcić rozproszony glob matematyki w skoncentrowaną wiązkę lasera.

Test na jutro – Gdy prosisz model o wariant interfejsu, zamiast wklejać cały zestaw założeń, spróbuj: opisz w 6–8 punktach tylko warstwy strategy i scope, dodaj jedną tabelę ograniczeń w formie przystępnej dla maszyny, poproś o wynik wyłącznie na poziomie structure i zastrzeż, aby nie generować rozwiązań z wyższych płaszczyzn. Porównaj z wersją „wszystko w jednym” pod kątem czasu do pierwszego prototypu i liczby poprawek.

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ć. Materiał pochodzi z prezentacji Jesse Jamesa Garretta „The Elements of UX in the Age of AI” – wystąpienia poświęconego 25-leciu stworzenia modelu Elements of User Experience.