Przez lata wystarczał nam prosty porządek. UI odpowiadało za warstwę interfejsu. UX za doświadczenie użytkownika. Z czasem do tego duetu dołączył jeszcze DX, czyli developer experience — sposób myślenia o tym, jak system odczuwa i obsługuje człowiek, który go buduje. Ten model nadal działa. Ale coraz częściej nie domyka już rzeczywistości, w której produkty cyfrowe są nie tylko używane przez ludzi i rozwijane przez developerów, lecz także czytane, interpretowane i obsługiwane przez agentów AI. Właśnie dlatego obok UX i DX coraz częściej pojawia się jeszcze jedno pojęcie: AX, czyli Agent Experience.
Nie chodzi o modny skrót na siłę. Chodzi o realną zmianę. Jeśli interfejs ma dziś drugiego czytelnika, a produkt coraz częściej ma trzeciego uczestnika obok użytkownika i developera, to język, którym opisujemy projektowanie, też zaczyna się zmieniać. AX nie jest jeszcze tak ustalonym terminem jak UX. Ale coraz wyraźniej próbuje nazwać coś, co naprawdę już się dzieje: systemy cyfrowe projektuje się dziś nie tylko dla ludzi, ale również dla agentów, którzy mają z nich korzystać, wykonywać zadania i współpracować z resztą infrastruktury.
UI to nie UX
To najważniejszy punkt wyjścia, bo te dwa pojęcia nadal są często wrzucane do jednego worka. Tymczasem UX od dawna ma dość klarowną definicję: obejmuje wszystkie aspekty interakcji użytkownika końcowego z firmą, jej usługami i produktami. Mówiąc prościej, UX dotyczy całości doświadczenia — tego, jak produkt jest rozumiany, odczuwany i czy pozwala człowiekowi osiągnąć cel. UI to tylko część tego obrazu: warstwa widocznych elementów, kontrolek, wzorców interakcji i układu interfejsu.
Dlatego UI nie jest tym samym co UX. UI odpowiada za to, jak produkt wygląda i jak komunikuje się przez swoje elementy. UX odpowiada za to, jak z tym wszystkim żyje człowiek po drugiej stronie. Można mieć estetyczne UI i słaby UX. Można też mieć interfejs surowy wizualnie, ale wspierający użytkownika lepiej niż bardziej efektowni konkurenci. To rozróżnienie jest ważne nie tylko z powodów definicyjnych. Ono porządkuje myślenie o tym, co właściwie projektujemy.
UX nie działa w próżni, dlatego pojawił się DX
Z czasem okazało się jednak, że sam użytkownik końcowy nie wyczerpuje obrazu produktu. Bo każdy system jest też tworzony, rozwijany, utrzymywany i naprawiany przez ludzi technicznych. Stąd rosnące znaczenie DX, czyli developer experience. W nowszych ujęciach DevEx nie oznacza tylko wygody pisania kodu. Oznacza raczej rzeczywiste doświadczenie developerów i punkty tarcia, które napotykają w codziennej pracy. Obejmuje narzędzia, dokumentację, procesy, przepływ pracy i organizację samego środowiska technicznego.
To ważne, bo DX nie jest luksusowym dodatkiem do produktu. Wpływa na jego jakość, tempo rozwoju, liczbę błędów i przewidywalność całego systemu. Innymi słowy: UX mówi nam, jak produkt odczuwa człowiek, który go używa. DX mówi nam, jak system odczuwa człowiek, który go buduje. I bardzo często jedno zaczyna bezpośrednio wpływać na drugie. Słabe środowisko developerskie rzadko prowadzi do naprawdę dobrego doświadczenia użytkownika końcowego.
Teraz produkt ma jeszcze jednego uczestnika: agenta
Przez długi czas ten duet — UX i DX — był wystarczający. Dziś coraz częściej już nie jest. Powód jest prosty: współczesny produkt cyfrowy coraz częściej nie kończy się na relacji człowiek–interfejs i człowiek–kod. Pojawia się trzeci uczestnik systemu: agent. Czasem działa po stronie użytkownika. Czasem po stronie narzędzi, API i workflow. Czasem jest pośrednikiem. Czasem wykonawcą. Czasem tylko „czyta” produkt, dokumentację albo interfejs. Ale coraz rzadziej jest to już czysto hipotetyczna figura.
To właśnie ten moment zmienia sposób myślenia o produkcie. Bo jeśli obok człowieka, który klika, i developera, który buduje, pojawia się jeszcze agent, który ma rozumieć strukturę systemu, przewidywać działanie narzędzi, poprawnie korzystać z dokumentacji i wykonywać zadania bez ciągłego improwizowania, to stary język zaczyna być za wąski. Nie dlatego, że UX przestaje być ważny. Tylko dlatego, że produkt ma już więcej niż jednego rodzaju uczestnika.
Właśnie tu pojawia się AX
AX, czyli Agent Experience, nie jest jeszcze pojęciem tak ustalonym jak UX. To raczej termin, który szybko rośnie, bo zaczyna opisywać realną lukę między doświadczeniem użytkownika a doświadczeniem developera. Speakeasy ujmuje to bardzo trafnie: AX lokuje się na przecięciu UX i DX, bo agent czasem musi rozumieć potrzeby użytkownika, a czasem niezawodnie współpracować z API, narzędziami i infrastrukturą. Netlify z kolei rozwija wokół tego szerszą rozmowę o „Agent Web” i o tym, że obok doświadczenia ludzkiego współistnieje coraz częściej warstwa projektowana pod agentów.
To bardzo ważne rozróżnienie. AX nie oznacza po prostu „dodania chatbota do produktu”. Nie chodzi też wyłącznie o to, czy agent brzmi naturalnie. AX zaczyna dotyczyć znacznie bardziej podstawowych pytań: czy system jest dla agenta zrozumiały, czy narzędzia są przewidywalne, czy dokumentacja jest jednoznaczna, czy uprawnienia są dobrze ograniczone, czy błędy są czytelne, czy ścieżki działania są bezpieczne i czy agent potrafi wrócić z błędu bez zgadywania, co autor systemu miał na myśli.
AX nie zastępuje UX ani DX
To warto powiedzieć wprost, żeby nie wpaść w tanią przesadę. UX nadal opisuje doświadczenie człowieka. DX nadal opisuje doświadczenie twórcy systemu. AX nie ma unieważniać żadnego z tych pojęć. Bardziej ujawnia, że między nimi pojawiła się nowa warstwa. Jeśli produkt ma być zrozumiały dla użytkownika i wygodny dla developera, ale jednocześnie coraz częściej jest konsumowany, obsługiwany albo wykonywany przez agenta, to potrzebujemy języka dla tego trzeciego wymiaru. I właśnie dlatego AX zaczyna być przydatne.
Najuczciwiej byłoby powiedzieć tak: UX i DX nadal są fundamentami. AX zaczyna być ich rozszerzeniem w świecie, w którym produkt przestaje być wyłącznie relacją między człowiekiem a interfejsem. To nie jest rewolucja przeciw wcześniejszym pojęciom. To raczej próba dopisania brakującego elementu do modelu, który przez lata był wystarczający, ale w środowisku agentowym staje się coraz mniej kompletny.
Jeśli UI ma drugiego czytelnika, to UX nie może kończyć się na człowieku
To jest moment, w którym wcześniejsze rozróżnienia zaczynają składać się w jedną całość. Jeśli UI nie jest już tylko warstwą dla ludzkiego oka, ale również strukturą odczytywaną przez agenta, to UX nie może już zakładać, że jedynym uczestnikiem doświadczenia produktu jest człowiek. A jeśli developer nie buduje już wyłącznie dla użytkownika i backendu, lecz także dla systemów agentowych, które będą jego produkt interpretować i wykorzystywać, to także DX zaczyna spotykać się z czymś nowym.
W tym sensie AX nie jest jeszcze „nową wielką dyscypliną”, ale jest już bardzo sensownym sygnałem zmiany. Pokazuje, że produkty cyfrowe nie są dziś używane tylko w jednej relacji. Są czytane i wykonywane przez różne typy uczestników. Człowiek nadal pozostaje centralny. Developer nadal pozostaje kluczowy. Ale obok nich coraz częściej stoi jeszcze agent — i to on wymusza nowy poziom precyzji w projektowaniu interfejsu, dokumentacji, logiki działania i architektury całego produktu.
Po UX i DX nie przychodzi moda. Przychodzi nowa warstwa odpowiedzialności
Najgorsze, co można dziś zrobić, to potraktować AX jako kolejny modny skrót z branżowego obiegu. W bardziej dojrzałej wersji chodzi o coś odwrotnego: o uznanie, że projektowanie systemów cyfrowych wymaga dziś większej odpowiedzialności za to, kto i jak z nich korzysta. Użytkownik ma swoje potrzeby. Developer ma swoje tarcia. Agent ma swoje ograniczenia i swoją logikę działania. Produkt, który ignoruje którykolwiek z tych wymiarów, szybciej zaczyna się rozsypywać.
Dlatego obok UX i DX coraz częściej warto mówić także o AX. Nie po to, by zastąpić wcześniejsze pojęcia, ale po to, by lepiej opisać świat, w którym interfejs nie kończy się na człowieku, a produkt cyfrowy ma już więcej niż jednego użytkownika.
