P: Co rozumiecie mówiąc "badania korytarzowe"? Bo trochę mi się nie zgadza definicja, ale może u was to inaczej działa

O: Słuszna uwaga, klasyczne badanie korytarzowe kojarzy się z łapaniem przypadkowych osób na kawie w biurze. My to pojęcie nieco rozszerzyliśmy na potrzeby naszej organizacji. Dla nas 'korytarzowość' oznacza niskokosztowość, zwinność i brak formalnego rygoru operacyjnego.

Szybko zauważyliśmy, że łapanie przypadkowych osób nie działa, gdy testujemy skomplikowane narzędzia, np. dla sprzedawców. Dlatego zmodyfikowaliśmy ten format: uczymy ludzi działać szybko i zwinnie, ale na etapie speed testingu dbamy o to, by rozmawiali z realnym użytkownikiem danego produktu. Pokazujemy im, że nawet szybki test zyskuje potężną wartość, gdy dobór uczestnika jest trafny.

P: Czy "demokratyzacją" objeci są tylko pm, czy tez pojektanci?

O: Naszą grupą docelową są przede wszystkim PMowie i projektanci UX. Zdarza się, że potrzeby badawcze pojawiają się też w zespołach niezwiązanych bezpośrednio z technologią, dlatego uczestnikami są niekiedy osoby z obszaru komunikacji czy kategorii.

P: 1) Jak obliczacie ROI demokratyzacji? Jakimi liczbami przekonałyście decydentów? 2) czy Marek to rzeczywista postać? 😊

O: Na ten moment jeszcze nie obliczamy ROI ;) jesteśmy na etapie wyposażenia ludzi w odpowiednie kompetencje i tak jak wspominałyśmy w prezentacji “jeszcze nie wiemy, czy inwestycja w demokratyzację się opłaci” - ale to, co planujemy niebawem robić, to weryfikacja, czy osoby, które odbyły szkolenie faktycznie prowadzą badania, oraz czy jako badacze dostajemy mniej próśb o przeprowadzenie testów użyteczności o niewielkim zakresie.

    Nie, Marek jest postacią stworzoną na potrzeby prezentacji procesu. Chciałyśmy, aby odzwierciedlał reakcje, przeżycia czy sytuacje, które zdarzyły się naprawdę, ale różnym uczestnikom. Marek jest syntezą obaw i sukcesów, których doświadczyli nasi uczestnicy. 

P: Czy szkolicie też badaczy z tego, jak szkolić? Sama wiedza dziedzinowa nie zawsze wystarcza.

O: Do tej pory szkolenie prowadziły osoby chętne i najczęściej miały już doświadczenie w przekazywaniu wiedzy. Dodatkowo szkolenie prowadzimy w parach, więc zawsze nowa osoba pracuje z kimś doświadczonym i może zdobywać umiejętności trenerskie w praktyce. Otrzymuje też gotowe materiały: scenariusz i prezentacje (oczywiście może sugerować w nim zmiany). Natomiast mamy wrażenie, że badacze z natury posiadają już kluczowe kompetencje trenerskie, które na co dzień wykorzystują w swojej pracy.

P: Czy macie centralne repozytorium znalezisk z badań zespołu UXR i uczestników demokratyzacji? W jaki sposób ono wygląda? W jaki sposób “łączycie kropki”?

O: Mamy centralną bazę wiedzy, do której trafiają raporty, zarówno nasze, jak i te z procesu demokratyzacji. Co ważne, publikacja raportu w tej bazie jest warunkiem koniecznym do otrzymania certyfikatu po szkoleniu. W ten sposób dbamy o to, żeby nawet po szybkich testach pozostawał ślad i budujemy w uczestnikach nawyk dzielenia się wiedzą.

    Oczywiście, jak w każdej dużej organizacji, klasyczne przeszukiwanie takiej bazy bywa wyzwaniem. Obecnie pracujemy nad nowym, bardziej optymalnym repozytorium opartym o AI, które pomoże nam automatycznie agregować i syntetyzować te wnioski.

P: Obawiam się że ta demokratyzacja i koncepcja „każdy robi wszystko” oznacza że ten „każdy” robi każdą z prac trochę wolniej i trochę gorzej niż ekspert jednocześnie tracąc czas na robienie rzeczy w których sam jest ekspertem

O: To uzasadniona obawa, uczestnicy demokratyzacji też ją podzielają. Na pewno nie chcemy doprowadzić do sytuacji, w której “każdy robi wszystko”, ale widzimy potrzebę wyposażenia PMów i projektantów w narzędzia do weryfikacji prostych hipotez. Działamy przy założeniu, że badacz takim tematem nie mógłby się zająć w ogóle (bo jest nas znacznie mniej, niż potrzeb badawczych w organizacji). Dlatego, żeby przyspieszyć procesy decyzyjne (i mimo wszystko wesprzeć w ich podejmowaniu), zdecydowaliśmy się na demokratyzację badań. Liczymy, że dzięki temu jako badacze zyskamy też czas na strategiczne badania.

P: Czy próbowaliście zautomatyzować swoją pracęz uzyciem AI aby przyspieszyć proces?

O: Wykorzystanie AI to naturalny kierunek ewolucji tego procesu, ale podchodzimy do niego z dużą odpowiedzialnością. Na ten moment AI wspiera nas głównie w warstwie operacyjnej i przygotowawczej (Research Ops) np. przy generowaniu materiałów warsztatowych. Przypuszczamy też, że sami uczestnicy również eksperymentują z AI przy tworzeniu scenariusza, wstępnej strukturyzacji notatek czy transkrypcji, pisania raportu.

    Obecnie w całym zespole badawczym jesteśmy na etapie prac koncepcyjnych nad systemowym wdrożeniem AI do procesów badawczych, a w tym procesu demokratyzacji. Analizujemy potencjał AI prototypowania do szybkiego generowania makiet pod testy oraz weryfikujemy, jak AI może wesprzeć w szybszej syntezie surowych wniosków, bez ryzyka halucynacji.

P: Jak analizujesz logi bez narzędzia typu GA4? Robisz obliczenia w excelu?

O: Używam dwóch rodzajów narzędzi:

    a) narzędzi do monitoring and observability developerskich - tam często można dokonać prostych wizualizacji i analiz. Czasem nawet bardziej złożonych jak np. DataDog, z którym praca pozwala na tak dużą elastyczność, że jest w stanie zagospodarować 90% analiz.

    b) Python lub wcześniej R - jeśli narzędzia na coś nie pozwalają piszę kod, który pozwala mi już dowolnie opracowywać, filtrować i tworzyć wykresy bez ograniczeń zawartych w UI narzędzi.

    Excela używam jako dodatkowego sprawdzenia analiz/do przeglądania danych, żeby poznać ich strukturę. Z nim trzeba jednak uważać na jedną rzecz - logi są często bardzo dużymi plikami (zależy m.in. od okresu z jakich je mamy), więc często Excel może się zawieszać.

P: Czego dotyczyło to zaznaczone zdanie z Twojego raportu? #suspens

O: Tutaj niestety nie jestem pewny czy dobrze złapałem, ale jeśli chodzi o slajd pod koniec to był to kod strony Allegro z zaznaczonym fragmentem gdzie jest datatestId elementu - chciałem pokazać jak deweloperzy mogą nazywać/operować na jakich nazwach elementów vs. te używane w UXie. W pracy z logami używam praktycznie głównie tych nazw - wtedy mam pewność, że mówimy o tej samej części strony (nie ma też potrzeby wtedy zaznaczania elementów na screenie etc.).

P: Jakie są, z Twojego doświadczenia, najciekawsze dane, na które warto zwracać uwagę w logach? Czy warto śledzić konkretne logi niezależnie od realizowanych projektów, czy raczej zawsze dopasowywać je do konkretnych celów badawczych?

O: Myślę, że zależy to od projektów, ale na pewno mogę polecić wykresy, które "robią wrażenie" i o ile dane pozwalają warto spróbować z nich skorzystać (np. DataDog je oferuje jako wbudowane w platforme, ale w Pythonie też da się je zrobić):

•     Sankey plot - świetnie pokazuje ścieżki nawigacji

•     Retention rate plot - klasyczny wykres obecny w analityce produktowej, ale można go stworzyć customowo w oparciu o logi (wystarczą daty i ID użytkownika)

•     Timeseries plot - świetny wykres pozwalający na przykład wyśledzić kiedy np. coś się zepsuło, bo widać zmiany w czasie

•     Dodatkowo standardowe barcharty, pie charty i inne - powinny być dostępne w narzędziach do obróbki logów, a jak nie to zawsze można zrobić samemu w Pythonie/R.

P: Jak wpadłeś na pomysł wykorzystania logów? Jaka historia za tym stoi? 

O: Wynikało to ściśle z potrzeb produktu - szukaliśmy źródeł danych i logi okazały się jednym z możliwych (i bardzo wartościowym!).

P: Czy wysiłek wkładany w dotarcie do logów i ich analizę naprawdę przewyższa korzystanie z wygodnych narzędzi analitycznych? Jak bardzo korzystanie z logów wpływa na czas dotarcia do danych, i czy narzędzia analityczne nie są „good enough” na co dzień, szczególnie w szybko zmieniającym się środowisku?

O: Myślę, że warto korzystać z obu* i nie zawsze korzystać z logów, natomiast zachęcałbym, żeby dołożyć to sobie do swojego narzędziownika badawczego i wtedy w zależności od potrzeby badawczej używać jednego albo drugiego. Tutaj też dużo zależy jak dobrze skonfigurowana jest analityka produktowa, bo może czasem pokazywać niedokładne dane (warto to przetestować). Jeśli wszystko działa dobrze, a nie potrzeba więcej niż podstawowe dane - to jasne, analityka produktowa jak np. Contentsquare jest jak najbardziej możliwa do wykorzystania.

    *tutaj gwiazdka, bo są obecnie na rynku narzędzia, które pozwalają na 2w1 tzn. i logi i analityka produktowa, więc wtedy ten kontrast nie istnieje np. DataDog

P: Jeśli projektujesz system, który będzie miał skomplikowane logi do analizy dla badacza. Czy masz jakieś wskazówki jak zacząć? 

O: Tutaj nie jestem pewny czy chodziło o system w sensie np. ustalanie nazw/trackingu elementów czy może taki sposób pracy jak zacząć.

    Domyślam się, że to pierwsze, a jeśli tak to zacząłbym od zorientowania się jak firma obecnie nazywa elementy i z czego skorzysta - można nawet użyć inspect toola w przeglądarce na Waszej stronie, żeby zobaczyć jaką strukturę mają nazwy elementów - to fajny punkt wyjścia do rozmowy.

    Warto też pomyśleć o filtrowaniu tzn. zadbaniu, żeby ruch wewnętrzny (my, deweloperzy, testerzy etc.) byli odfiltrowywani.

P: Na ile to praca badawcza, a na ile dla analityka? W niektórych organizacjach mamy obie role. Co polecasz wtedy - jak taka (współ)praca powinna przebiegać?

O: Ciężko mi niestety tutaj coś doradzić, bo różne organizacje różnie mogą do tego podchodzić. Natomiast polecałbym pomyśleć czy jest może gdzieś przestrzeń, żeby zacząć się tego uczyć nawet dla siebie, chociażby podstawowego programowania i zorientowania z czego korzysta się w firmie do zbierania logów, gdyby jeśli nawet nie w tej organizacji to w innej może pojawiłaby się możliwość.

P: Jakie pytania badawcze mieliście w przypadku ankiety?

O: W badaniu ilościowym mieliśmy sporo pytań badawczych. Głównie po to, żeby porównywać doświadczenia z procesu zakupowego w LLM z danymi, z procesu zakupowego na platformie Allegro. Oto kilka z nich.

•     Jak często użytkownicy korzystają z LLM w kontekście zakupów online?

•     W jakich czynnościach LLM wspiera użytkowników podczas zakupów online?

•     W jakich czynnościach w procesie zakupowym LLM jest postrzegany jako najbardziej przydatny.

•     W jakich czynnościach w procesie zakupowym LLM jest postrzegany jako najmniej przydatny.

•     Jak użytkownicy oceniają proces wyszukiwania produktów za pomocą LLM?

P: Czy w procesie badawczym rozmawialiście z osobami, które korzystają z bardziej zaawansowanych funkcji (high-userow) LLMów, np. Claude Workflow?

O: Akurat nie ;) Podczas tego badania celowo chcieliśmy przetestować proces zakupowy w LLM z osobami podatnymi na innowacje, ale nie aż tak zaawansowanymi w obsłudze AI.

P: Czy porównywaliście doświadczenie usera w zewn LLM vs z chatbotem wewn na stronie Allegro? 

O: Bezpośrednio nie, ale prowadziliśmy badania obu rozwiązań ;)

P: Czy mierzyliście się z przedstawicielami biznesu opornymi na tłumaczenia, że dane badanie jest ryzykowne/bezwartościowe w danej formie? Co w sytuacji, kiedy wiecie, że, biorąc pod uwagę ograniczenia czasowe/finansowe, nie dowieziecie rzetelnych wyników, a ktoś „nad Wami” się upiera?

M: Czasami (choć raczej rzadko) bywają takie sytuacje. W takiej sytuacji ważne żeby przed startem jasno i klarownie zakomunikować nasze obawy / perspektywę i żeby osoba zlecająca badanie miała tego pełną świadomość.

Przeważne przed startem każdego badania robimy warsztat kickoff z karteczkami na FigJamie, dzięki temu wszystkie ustalenia ale i też ryzyka) są zmapowane przed startem na piśmie i potem mamy punkt odniesienia, jeśli rezultat badania jest dyskusyjny.

P: Czy macie pomysły jak łączyć trend na demokratyzację badań i takie dojrzałe podejście do UXR?

W: Myślę, że demokratyzacja może iść w parze z dojrzałym podejściem do researchu, a dobrym przykładem było to, jak podeszło do tego Allegro. Opowiedzieli nam o tym na swojej prezentacji.

Czyli przekazywanie tej wiedzy, edukacja oraz prowadzenie szkoleń w ten sposób, że osoby spoza zespołu, które chcą prowadzić research, będą w stanie same sobie odpowiedzieć na pytanie, czy to, jak zadają własne, i to, co chcą zbadać, ma sens.

Nie ukrywajmy, te badania to często nie są bardzo zaawansowane techniki; raczej są to szybkie testy korytarzowe. Wciąż to jest raczej pewna szybka walidacja, czy zdobycie wiedzy na jakiś pilny temat, a nie budowanie strategii.

P: Czy kiedykolwiek „oberwało” Wam się za próbę ewangelizacji i edukacji ludzi na temat tego, czy/kiedy warto robić badania? Jeśli tak, jak wyglądała ta sytuacja?

W: Raczej nie. Jeżeli przekazujesz feedback albo wplatasz swoją wiedzę w sposób pełen szacunku, bez wyższości, to ludzie raczej doceniają Twoją ekspercką wiedzę i po to z Tobą współpracują, po to Ci płacą właśnie, żeby z niej korzystać.

Problemy mogą pojawiać się, gdy ślepo, w taki ewangelistyczny sposób, próbujemy przekonać, że badania muszą się odbyć w tym momencie, bez przyznania, że być może są inne priorytety.

No i tak jak opowiadaliśmy na naszym wystąpieniu, w takich sytuacjach ta próba ewangelizacji, pójście koniecznie w badania, mogłaby się skończyć brakiem wartości dla projektu

P: Czy mieliście sytuacje, że zatrzymaliście pociąg badawczy, ale po fakcie stwierdziliście (dowiadując, się nowych danych), że mogliście jednak jechać tym pociągiem? Co to za sytuacja? 

M: Raczej nie zdarzyło się nam zatrzymać pociągu z przyczyn metodologicznych i potem żałować. Zawsze przy zatrzymywaniu pociągu staramy się dać jakąś alternatywę (badanie w innej formie, czy innym terminie) i przeważnie po zatrzymaniu pociąg rusza dalej ale w innej formie. 

Są czasami takie sytuacje, że coś definitywnie zatrzymaliśmy / odrzuciliśmy, bo z naszej perspektywy nie miało większej wartości / sensu, ale są to rzadkie sytuacje i bardzo skrajne, ale do tej pory nigdy potem nie dochodziliśmy do wniosku że moglibyśmy jednak pojechać tym pociągiem.

Natomiast kilka razy zatrzymaliśmy pociąg z przyczyn organizacyjnych np. odmówiliśmy lub przełożyliśmy badania przez obłożenie w innym projekcie albo kwestie prac innych zespołów. Np. oceniliśmy że badanie nie ma sensu bo w sensownym terminie nie dostaniemy wsadu do badania) po czym projekt potoczył się w innym kierunku, niż zakładaliśmy i okazywało się, że jednak szkoda że danego badania nie przeprowadziliśmy :D 

P: Jeśli macie doświadczenie w pracy in-house, to Waszym zdaniem częściej macie do czynienia z nieproporcjonalnymi oczekiwaniami w przypadku współpracy agencyjnej (zlecenie od klienta) czy w przypadku pracy in-house?

W: Myślę, że to może się zdarzyć w obu tych środowiskach. W pracy agencyjnej współpracujemy z różnymi firmami o różnym poziomie dojrzałości, jeśli chodzi o tematy UX i tematy badawcze. 

W: Za to w pracy in-house'owej częściej spotkałam się osobiście z nierealistycznymi oczekiwaniami co do tego, na jakie pytania może odpowiedzieć research. Czyli częściej pojawiają się takie pytania: „Zbadaj, czy ta funkcjonalność będzie sukcesem?” zamiast „Zbadaj, żeby pomóc nam podjąć lepszą decyzję.”

P: Jak wygląda rekrutacja do takich sesji? Czy i jakie obawy mają klienci, jeśli chodzi o pokazywanie pełnego procesu zakupowego, w tym podawania swoich danych w checkoucie i dokonywania płatności? Jak dbacie o prywatność tych danych?

O: Rekrutacja przebiega dość standardowo. Tak jak wspominaliśmy, w przypadku badań, które kończą się realnym zakupem, oferujemy uczestnikom nieco wyższe wynagrodzenie. Uwzględnia ono kwotę na potencjalny zakup - przy czym dajemy tu pełną dowolność, bo uczestnik może kupić coś droższego lub tańszego, zależnie od własnych potrzeb.

Co ważne, staramy się nie uprzedzać badanych, że podczas sesji dojdzie do zakupu. Chodzi o to, żeby nie przygotowywali sobie wcześniej produktu. Zależy nam na podejrzeniu naturalnego procesu – dokładnie tak, jak wygląda on na co dzień, od początku do końca.

Jeśli chodzi o bezpieczeństwo danych, w momencie samej płatności prosimy uczestnika o chwilowe zatrzymanie udostępniania ekranu. Prosimy wtedy, by jedynie opowiadał nam na głos, co dokładnie robi. Dzięki temu nie widzimy wrażliwych danych, a wciąż jesteśmy w stanie wyłapać ewentualne błędy czy potknięcia na tym etapie.

P: Czy uczestnikami Conti Disco są tylko Kupujący? Jeśli tak, to dlaczego nie inne grupy, np. Sprzedający? 

O: Tak, Conti Disco realizujemy wyłącznie z Kupującymi. Mieliśmy pomysł, żeby przetestować to podejście również z Partnerami (Sprzedającymi), ale po rozmowach z badaczami, którzy na co dzień się nimi opiekują, okazało się, że ta metoda zupełnie nie odpowiada ich potrzebom.

Przede wszystkim wynika to z faktu, że Partnerzy nie przechodzą na Allegro jednego, powtarzalnego flow, które odpowiadałoby klasycznej ścieżce zakupowej. Po ich stronie jest mnóstwo różnych procesów, narzędzi i punktów styku (często również poza samym Allegro). Wokół tak rozproszonych działań niezwykle trudno byłoby zbudować jeden spójny, powtarzalny i - co najważniejsze - realistyczny scenariusz badawczy.

P: Jak z harmonogramem sesji? Czy staracie sie trzymac jednego/dwoch dni w miesiącu czy jednak jakoś inaczej?

O: Trzymamy się stałego, przewidywalnego rytmu: sesje odbywają się co 4 tygodnie w sztywnych godzinach - dwie w środę i dwie w czwartek.

Czasami robimy od tego małe wyjątki. Jeśli rekrutujemy grupy, których doświadczenia mocno różnią się od „typowego” użytkownika (np. seniorów albo osoby korzystające z zagranicznych platform), zdarza nam się rozszerzyć daną edycję o 1-2 dodatkowe spotkania.

P: Czego nie lubicie w conti disco?

O: Maks: Dla mnie najgorszy moment to samo wpisanie moderowania Conti Disco do kwartalnej roadmapy - zwłaszcza gdy widzę, że w tym samym czasie mam na głowie kilka innych projektów, którymi muszę się równolegle opiekować. Na szczęście później jest już z górki. Przy tak powtarzalnym i elastycznym scenariuszu samo przygotowanie do sesji to pikuś. A moderowanie spotkań i obserwacja użytkowników to już czysta przyjemność i konkretny zastrzyk dopaminy 😃

O: Alicja: Nie mam tak konkretnego elementu Conti Disco, którego nie lubię, ale trzeba przyznać, że edycje, w których prowadzimy spotkania z bardziej niszowymi użytkownikami, mogą być bardziej stresujące na etapie rekrutacji. Oczywiście, mamy wsparcie bardzo dobrej agencji, ale przy rekrutacji takich mniej typowych użytkowników nie zawsze jest to takie łatwe i wymaga zarezerwowania więcej czasu i większego zaangażowania od strony badacza.

P: Dlaczego myślisz, że odejdziemy od badań jakościowych? Mój osobisty take jest taki, że będziemy robić więcej concept testingów ze względu na szybsze wytwarzanie makiet / pomysłów / prototypów 🤔

O: Moim zdaniem, nie odejdziemy kompletnie od badań jakościowych, ale będziemy robić dużo więcej ilościowych, bo po prostu będą łatwiejsze do przeprowadzenia. Obecnie jesteśmy w stanie stworzyć dużo taniej prototyp niż kiedyś i przeprowadzić eksperyment lub po prostu wdrożyć coś na produkcję i przetestować to na małym % ruchu. Badania jakościowe będą przeprowadzane rzadziej, ale myślę, że przez to, że jakościowe będą łatwiejsze i jednocześnie tańsze, to jakościówka będzie mogła być przeprowadzana w bardziej pogłębiony sposób.

P: Jeśli postawimy znak równości między testami użyteczności i badaniami jakościowymi to być może faktycznie to odchodzi. Moim zdaniem prawdziwe, pełne kolorów i wiedzy badania jakościowe będą w cenie - bo AI (jeszcze) nie poprowadzi rozmowy, nie wyczyta z kontekstu, tonu głosu i ucieczki wzrokiem.

O: Zgadzam się, AI nie zastąpi badacza w badaniach jakościowych. Być może nie do końca sprecyzowałem swoją myśl na panelu - będziemy robić dużo więcej badań ilościowych niż jakościowych, ale to nie oznacza, że nie będziemy robić jakościowych w ogóle. 

P: Co według Ciebie pozostanie unikatową wartością UX-ów (Researcherów i Designerów) w erze designu zdominowanego przez AI?

O: Uniwersalne, strategiczne umiejętności związane z projektowaniem i wnioskowaniem, takie jak krytyczne myślenie, tworzenie wizji produktu, facylitowanie w procesie projektowym, tworzenie i monitorowanie metryk. Poza tym umiejętności związane z AI: tworzenie produktów pod agentów AI i optymalizacja pod wyszukiwanie w LLM'ach, bezpieczeństwo danych i zarządzanie kontekstem, współpraca interdyscyplinarna z innymi specjalistami i znajomość podstaw budowy systemów opartych o AI (ponieważ każdy produkt będzie w jakimś stopniu AI implementował). 

P: Mówiłeś o swoim doświadczeniu w produkcie, który teraz musi być przeprojektowany - co Twoim zdaniem nie zadziałało w tym przypadku? 

O: Project Manager, który promptował front-end samodzielnie pod wymagania klienta patrzył jedynie na to czy kolejne iteracje zbliżają go do pokrycia całej wymaganej funkcjonalności. Na sam koniec miał pokryty zakres w 100%, ale po drodze zapomniał o użyteczności i dostępności. Końcowy efekt był przeładowany, niedostępny i nieużyteczny dla użytkownika końcowego, mimo, że teoretycznie spełniał wszystkie postawione wymagania.

P: Jaka jest Twoja opina na temat demokratyzacji designu?

O: Jak najbardziej jest to słuszny kierunek, ale przy założeniu, że w procesie uczestniczą designerzy, którzy są "quality gate'm" dla tworzonych rozwiązań. Im więcej głów i spojrzenia na problem, tym ciekawsze rozwiązania powstają. Na sam koniec czym różni się szkic na kartce papieru przygotowany przez analityka od klikalnego prototypu, który spromptował? Po ewaluacji przez designera ten klikalny prototyp może się okazać rozwiązaniem tylko o krok odległym od finalnego rozwiązania. 

P: Jak badacz UX może skorzystać na tym, że PMowie coraz częściej sięgają po AI projektowanie i vibe coding? masz jakieś praktyczne triki?

O: PM może bardzo szybko przelać swoje myśli na działający, klikalny prototyp. W ten sposób unikamy błędu interpretacji i można od razu, dosłownie, pokazać co mamy na myśli. Taki prototyp może trafić później do badań, albo po uprzedniej korekcie zrobionej przez designera. Takie same prototypy mogą tworzyć badacze. Vibe coding to też fajna droga to prezentacji danych i raportów. Po co robić kolejnego PowerPointa, skoro można stworzyć prostą grę lub animację, która opowie tą samą treść w dużo bardziej angażujący sposób?

P: Na jakiej podstawie wybrać odpowiednie narzędzia AI, które wdrożyć do swojego workflow na dłużej/na stałe? Zmiany w świecie AI zachodzą często z dnia na dzień, ciągle pojawiają się nowe toole, jak wybrać te wartościowe? 

O: Na swoim przykładzie mogę powiedzieć, że ja doszedłem do tego metodą prób i błędów. Ten sam prompt, to samo zadanie, wpisywałem do Claude, Gemini i ChatGPT. Sprawdzałem, z którymi zadaniami najlepiej radzi sobie jeden LLM, a którymi inny. Są dostępne benchmarki i porównania, ale ja osobiście stawiam na Claude Pro w wersji desktopowej, korzystam przede wszystkim z Coworka.

P: Czy jesteś w stanie w zadowalający sposób używać swojego Design Systemu w Figma Make / Claude?

O: Na ten moment nie jestem jeszcze do końca zadowolony, nawet jeżeli wypluwany kod jest spójny wizualnie, to nie trzyma struktury komponentów. Natomiast jest to przedmiotem mojej pracy na najbliższy czas, aby przez stworzenie odpowiednich agentów i reguł zmniejszyć dystans między designem, a developmentem do absolutnego minimum, w kontekście pisania front-endu. 

P: Mówisz o wielu narzędziach LLM (Notebook, Claude, Gemini itd.), korzystałaś z wersji płatnych czy darmowych? Jak z bezpieczeństwem danych i ich potencjalną archiwizacją?

O: Korzystamy z płatnych narzędzi, które dają możliwość nieużywania danych do treningu i mają zapewnione bezpieczeństwo danych. 

P: Czy podczas samodzielnego użycia software uczestnicy musieli wykonać zadania od ciebie jako projektantki x badaczki? Czyli po prostu swobodnie robili swoją pracę bez specjalnych wymagań od produktowego zespołu?

O: Mieliśmy przygotowane cele dla zespołu: znalezienie i opisanie charakterystyk minerałów na bazie guidebooku i zdecydowanie o jednym punkcie w pobliżu najbardziej wartościowych minerałów, gdzie zbudują bazę naukową. Natomiast sami mogli zdecydować, jak korzystają z narzędzia i jak organizują pracę czy komunikację.

P: Patrząc na powagę projektu - mieliście dostęp tylko do komercyjnych narzędzi LLM?

O: Tak, tylko do komercyjnych

P: Czy podpinacie analitykę / logi pod prototypy? Jeśli tak, to jak podchodzicie do ich analizy?

O: Tak mamy podpięte logi, dzięki czemu wiemy co było wpisywane w input wyszukiwarki, które oferty były wybierane. Korzystaliśmy również z Hotjara, dzięki czemu po wszystkich wywiadach mogliśmy przeanalizować heatmapy i nagrania sesji. Staramy się łączyć dane ilościowe z jakościowymi, traktując je jako uzupełniające się źródła wiedzy. Wnioski z badań jakościowych stanowią punkt wyjścia (np. hipotezy dotyczące zachowań lub problemów użytkowników), które następnie weryfikujemy i możemy pogłębić poprzez analizę danych z logów, heatmap i nagrań sesji.

P: W jaki sposób odtworzyłyście wygląd platformy pracuj.pl? Jakiego narzędzia użyłyście do przekazania projektu z Figmy do AI, żeby zbudować prototyp funkcjonalny?

O: Mamy opracowaną paczkę referencyjną, która bazuje na naszym design systemie. Design System, który budujemy jest w konwencji AI-Ready, co przekłada się na to, że AI zna kontekst użycia konkretnych komponentów i wie kiedy ich używać. To pozwoliło, że layout mocno przypomina ten, który mamy na produkcji.

Sam prototyp został stworzony w Claude Code - bez ingerencji w warstwę techniczną. Cały proces opierał się na prostych komendach oraz wklejaniu linków do konkretnych frame’ów w Figmie. Dzięki połączeniu przez MCP Server Claude był łatwo w stanie odzwierciedlić layouty jakie mamy. Jak to działa - to konkretnie opisane funkcje, które Claude Code przerodził w działające zgodnie z tym jak potrzebowaliśmy. Podsumowując: najpierw mieliśmy projekt w Figmie następnie poprzez wklejenie konkretnych linków - przez MCP - Claude Code przełożył go na działającą aplikację. Trzeba było to oczywiście dopracować, ale nie był to duży nakład pracy. Cała praca opierała się na wydawaniu komend typu - jak to ma działać, nie technicznych aspektów.

P: Czy zespół projektantów (i badaczy) w jakiś sposób przeciwdziała powstawaniu ai-prototypów bez udziału projektanta? Czy istnieje możliwość że klient zobaczy taki prototyp? 

O: AI potrafi wygenerować interfejs, ale nie zastąpi wiedzy i umiejętności product Designera, który zna architekturę informacji, heurystyki, szerszy kontekst biznesowy i potrzeby użytkowników. W ramach organizacji staramy się uświadamiać, że finalny produkt musi odpowiadać na realne potrzeby użytkowników i biznesu, a nie być efektem prześcigania się w tym kto ma więcej pomysłów. Oczywiście nie zatrzymamy tego co już się dzieje - wszyscy w mniejszym lub większym stopniu korzystają z AI - dlatego ważna jest dla nas kontrola nad procesem badań, powstawania, testowania i wdrażania nowych funkcji i zmian.

Czy klient może zobaczyć taki prototyp? Rozumiem, że Klientem w tym rozumieniu jest firma / osoba, która zleca projekt. W naszym przypadku możemy mówić o interesariuszach - i jak najbardziej mogą zobaczyć prototyp, w niektórych przypadkach jest to wręcz wskazane - aby sami z niego skorzystali, przeszli przez różne ścieżki i zobaczyli jak działa. Warto jednak pamiętać o tym, że taki prototyp służy nam wyłącznie jako zaawansowane narzędzie badawcze, a nie jest finalnym rozwiązaniem projektowe.

P: W jaki sposób przenosicie prototyp z Claude do Figmy? 

O: Mamy stworzony skill, który korzysta z połączenia z Figma MCP. Skrypt wysyła plik HTML lub aplikację z localhost do Figmy bez żadnych pluginów ani screenshotów. Działa przez osadzenie skryptu z serwera Figmy do danej strony, a następnie wywołuje odpowiednie funkcje udostępnione przez MCP figmy, które przechwytuje strukturę strony i tworzy z niego design w Figmie. Cała przeniesiona strona to nie screenshot, tylko edytowalny layout ze strukturą i autolayoutami w figmie, który możemy poddać dalszej obróbce projektanckiej i powpinać elementy z naszego design systemu.

P: Czy halucynacje AI (jeśli występowały) były dla Was problemem w czasie badań i mogły wpłynąć na wyniki? 

O: W przypadku naszych badań halucynacje nie były dużym problemem, a wszystko dzięki wielokrotnym testom prototypu przed badaniami, które pomogły dopracować prompt i szczegóły prototypu. Narzędzia, których używałyśmy do zasilenia prototypu, miały ustalone ramy, które działały oparciu o konkretną logikę biznesową i zamknięty zestaw danych. Nawet jeśli AI wygenerowało drobną niespójność językową, większość użytkowników nie zwracała na nie uwagi, dodatkowo rozpoczynając badania zaznaczałyśmy, że część treści jest generowana automatycznie. Kluczowe elementy i copy, które miały pozostawać bez zmian i być takie same dla każdego respondenta były wcześniej ustalone i dodane na etapie budowania prototypu.

P: Nie wiem, czy możecie o tym mówić, ale z jakim odbiorem spotkało sie wykorzystanie AI w kontekście szukania pracy? Czy użytkownicy ufają tego typu rozwiązaniom, czy mają jakieś obawy?

O: Na badaniach spotykamy się z wieloma różnymi reakcjami na wykorzystywanie AI w poszukiwaniu pracy i staramy się odpowiadać zarówno na potrzeby użytkowników, którzy chcą się nim wspierać, jak i tych, którzy nie są takim wsparciem zainteresowani. Dobrym przykładem jest Kreator CV, gdzie wprowadziliśmy Asystenta Pracuj pomagającego w opisie doświadczenia zawodowego. To rozwiązanie wspiera użytkownika, pozwalając wygenerować propozycję obowiązków lub poprawić własny tekst, który można dalej edytować i dostosować do siebie. Dzięki temu osoby otwarte na AI dostają realną pomoc w momencie, w którym najczęściej się blokowały, a jednocześnie zachowujemy pełną kontrolę po stronie użytkownika, co jest kluczowe dla budowania zaufania. Widzimy też, że mnogą grupą są osoby, które wcześniej korzystały z narzędzi typu ChatGPT poza naszym serwisem, więc przeniesienie tej funkcji bezpośrednio do kreatora znacząco upraszcza ich proces i redukuje wysiłek. Jednocześnie osoby mniej przekonane do AI mogą nadal przejść cały proces bez korzystania z asystenta, co pozwala nam odpowiadać na różne potrzeby użytkowników.

P: WOW! A jak użycie tego typu prototypów wpływa na zasoby (czas i koszty) potrzebne do przeprowadzenia badania w porównaniu do klasycznego, nie AI-owego podejścia? Ile zwykle zajmuje Wam stworzenie i zaakceptowanie takiego prototypu?

O: W naszym przypadku kluczowe jest to, że szybkość i efektywność tworzenia prototypów AI nie bierze się „z samego AI”, tylko z fundamentów, które mamy już zbudowane. Design System, który budujemy jest w konwencji AI-Ready, co przekłada się na to, że AI zna kontekst użycia konkretnych komponentów i wie kiedy ich używać. Znacznie skraca to czas i koszty przygotowania takiego prototypu. Bez solidnych podstaw technicznych (zarządzania tokenami, optymalizacji promptów i strukturyzacji inputu) AI działa mniej precyzyjnie, wymaga więcej iteracji i generuje wyższe koszty. Taki prototyp może powstać zdecydowanie szybciej na przykład w 8 godzin, ale prawdziwe muszą być właśnie założenia, że możemy się oprzeć o Design System i mamy podstawy techniczne, aby w efektywny sposób taki prototyp przygotować. Jeśli te warunki są spełnione to przygotowanie takiego prototypu jest znacznie szybsze, prostsze i może zająć 8 godzin.

P: Jak PO reagują na dodatkowe narzędzie zamiast np. backlogu UX-owego w JIRA?

O: Do tej pory jako CXR w ogóle nie pracowaliśmy z PO w Jirze i naszym jedynym narzędziem do trackowania rekomendacji było Airtable. Jeśli PO uznał, że będzie mógł w najbliższym czasie podjąć rekomendację, wtedy sam przekładał ją na zadanie w Jirze - nie działo się to automatycznie. Aktualnie jesteśmy in progress w rozkminianiu procesu, w którym trzymamy rekomendacje tylko w Jirze i tam je wszystkie aktualizujemy.

P: Jedna rzecz, z której jesteście najbardziej dumni w kontekście przeorganizowania repo z AI?

O: Chyba samo dostrzeżenie problemu! Po włożeniu takiej pracy w stworzenie repozytorium w Airtable mogliśmy wpaść w pułapkę: „Zrobiliśmy wszystko, co się dało, a to, że komuś nie pasują tabele, to nie nasza wina. Niech się nauczą z tego korzystać". Spróbowaliśmy jednak spojrzeć na to całościowo - jaki będzie z tego outcome? Jak niechęć do przekopywania się przez nasze wyniki wpływa na chęć współpracy z UXR? Zerwanie z tymi naszymi dopieszczonymi tabelami nie było łatwe, więc właśnie z tego jesteśmy dumni.

P: Jak aktualizujecie repo? Np. nowa wersja rozwiązała jakieś kwestie z badania, ale popsuła coś innego.

O: Gdyby się okazało, że wdrożyliśmy jakąś rekomendację i na kolejnym badaniu widzimy, że coś pogorszyła - wtedy powstaje nowa rekomendacja obejmująca tę zmianę. Tamta - zgodnie z prawdą - dostaje status zrealizowanej i już jej nie ruszamy. Rzadko generalnie ingerujemy jakkolwiek w treść rekomendacji, zazwyczaj zmieniamy im po prostu status.

P: Jak radzicie sobie z łączeniem wszystkich informacji w ramach repozytorium (np. faktów z wnioskami)?

O: Samo łączenie faktów z wnioskami i rekomendacjami z jednego badania nie jest problemem - w Airtable da się to łatwo zautomatyzować i podpinać między sobą dane w różnych arkuszach. Wszystkie wypracowane przez nas zasady sprawiły, że nie gubimy się i każdy wie, co, gdzie i jak. Natomiast łączenie danych z poprzednimi badaniami jest już bardziej czasochłonne. Robimy to zazwyczaj po tagach - jeśli dany fakt/wniosek/rekomendacja dotyczył np. koszyka, to szukamy poprzednich wniosków z tym samym tagiem. Dodatkowo korzystamy z Omni na Airtable, czyli ich dodatku AI – stworzyliśmy odpowiedni prompt, który (często niedokładnie, ale jednak) wskazuje nam potencjalne fakty/wnioski/rekomendacje z poprzednich badań do połączenia. No i - truizm - po dłuższej pracy w firmie często po prostu pamiętamy poprzednie wyniki i wiemy, co z czym połączyć. Tldr: da się to zrobić, ale jest czasochłonne i wymaga sporo pracy manualnej.

P: Czy testowaliście już interaktywną wersję repozytorium z wewnętrznymi użytkownikami?

O: Na razie testujemy ją tylko w swoim zespole

P: Super prezka! Czy dałoby się skipnąć ten etap zgrywania się z PM-ami a propos tego, czy rekomendacja została wdrożona? Nie ma jakiejś automatycznej integracji Airtable → Jira?

O: Właśnie nad tym pracujemy. Chociaż sam etap omawiania rekomendacji na spotkaniu ma też swoje zalety - daje nam przestrzeń na rozmowę i ponowne przekminienie, co zrobić z daną rekomendacją. Natomiast rzeczywiście staramy się w tym momencie przenieść wszystko do Jiry, tak żeby to zautomatyzować i zupełnie skipnąć wprowadzanie do Airtable i omawianie.

P: A nie uważasz ze taki syntetyczny respondent radziłby  sobie lepiej gdyby zasilić go danymi z  "książkowo" przeprowadzinej segmentacji? I ze syntetyczny respondent ma przyszlosc, ale trzeba wrocic do podstaw - segmentacji "U&A". 

O: Myślę, że lepsze dane wejściowe zdecydowanie poprawiają jakość synthetic users — i dobra segmentacja będzie tu bardzo ważna. Persony często pokrywają się z segmentami, ale częściej są kluczowymi grupami w ramach segmentów. Jest to na pewno ważny trend, ale na podstawie moich eksperymentów wyniki synthetic users na ten moment bardzo się rozjeżdżają z wynikami badań prawdziwych użytkowników. 

P: Wspomniałaś o tym, że ten case ankiety o newsletterze spodobał się interesariuszom z pionu biznesu. W jaki sposób budujecie „zdrowy dystans” do takich praktyk, jeśli biznes już się zajarał? Szczególnie że na co dzień macie trudną grupę respondencką 

O: Bardzo pilnujemy, żeby synthetic outputs nie były traktowane jak „prawdziwy głos użytkownika”, tylko materiał eksploracyjny albo hipoteza. Dużo daje też pokazywanie ograniczeń tych metod — np. jak bardzo wyniki zależały od promptu czy kontekstu. W przypadku ankiet czy wywiadów z personami dokumentujemy nasze wyniki pokazując, gdzie i dlaczego się one rozjeżdżają. To daje nam pole do dyskusji z biznesem - reality check.

P: Czy nie sądzisz (pytanie z tezą), że badania prowadzone w sposób, który opisałaś (łączenie AI, pilnowanie jego jakości, weryfikacji) będą nas bardziej obciążać poznawczo i sprzyjać przeciążeniu oraz wypaleniu?

O: Myślę, że zmienia to rolę badaczki i osobiście nie odczuwam tego jako przeciążenie. Faktycznie więcej jest sprawdzania i kontroli, ale pewne elementy mogą zostać zautomatyzowane. Dla mnie osobiście uwolniło to dużo wolnego czasu na planowanie, strategię oraz zdobywanie nowych umiejętności. 

Playlistę znajdziesz tutaj

Spis wystapień:

1. Katarzyna Szklarz, Łukasz Ogrodniczak - UX Research Confetti by Allegro: Otwarcie

2. Paulina Makuch - Za kulisami, czyli cała prawda o zespole UX Research w Allegro

3. Aga Szóstek - Jak strategicznie badać doświadczenia?

4. Bartosz Narzelski - Product Discovery w Twoim zasięgu 

5. Laura Lachowicz - Co się eksploruje w serwisie, który znają prawie wszyscy?

6. Monika Sznel, Joanna Kalicka - Jak COVID wyreżyserował nam badawczą incepcję? 

7. Klaudia Doerffer - Jak badania z użytkownikami mogą wspierać pracę projektantów? 

8. Krzysztof Jarocki - O badaniach w dużej organizacji, jak tworzyć rozwiązania w oparciu o dane zastane

9. Paweł Adamczak - O badaniach i big data- jak dane behawioralne mogą wspierać badania i rozwój produktu

10.  Paweł Walczak - Jak monitorować rozwój produktu, by nie stracić z pola widzenia potrzeb użytkownika

11. Jakub Dodot - C-Index – metryka skrojona na miarę Allegro  

Playlistę znajdziesz tutaj

Spis wystapień:

1. Piotr Źrołka - Projektowanie uniwersalne & dostępność cyfrowa w kontekście badań 

2. Anna Sieroń - Uproszczony, ale skuteczny proces badawczy 

3. Piotr Kaluba - Akcja-Rekrutacja, czyli jak zadbać o efektywną rekrutację w badaniach UX?

4. Alicja Antkowiak - Junior, Regular, Senior i…? Co to znaczy być ekspertem UX Research? 

5. Katarzyna Zerka - Legendy o idealnych repozytoriach badawczych 

6. Aleksandra Klein - Od stażu po etat - pierwsze miesiące pracy badaczki UX 

7. Jadwiga Kijak - Proces badawczy pod lupą - Research OPS w agencji UX 

Playlistę znajdziesz tutaj

Spis wystapień:

1.  Niepowszednie badania UX - Rafał Salamon

2.  Wykorzystanie tradycyjnych metod badawczych w eksploracji Jobs To Be Done - Ewa Derek

3.  Podróż w nieznane? Co warto wiedzieć przygotowując się na (nie)standardowy projekt - Magdalena Bernatowicz-Bujwid, Joanna Brudnik, Aga Wilke-Trochymiak

4.  Szukanie nieodkrytego, tworzenie nowego - Igor Farafonow 

5.  UX Research na Pol’and’Rocku, czyli kilka słów o badaniach guerrilla - Ania Ostrowska, Gosia Zięba 

6.  Społecznościowe słuchanie jako metoda wyszukiwania potencjałów - Marta Truś 

7.  Zautomatyzowane narzędzia badawcze: Czy są gotowe na główną scenę? - Anna Rennert

8.  Czego Sztuczna Inteligencja może zazdrościć badaczom UX? - Maksymilian Kamiński, Joanna Malinowska 

9.  W drodze do standardu dla niestandardowych sytuacji badawczych - Magda Kołba-Górna, Łukasz Posłuszny 

10.  Neuroróżnorodność w procesie badawczym i projektowym - Karolina Kwas 

11.  Product Design w rytmie Conti Disco - Mateusz Martyn, Wojciech Czerniak

12.  Wylewanie fundamentów, czyli o badaniach w fazie Discovery podczas pracy nad nowymi aplikacjami 

13.  Gdy użytkownik kłamie - jak wykorzystać rozbieżności w danych do dalszego formułowania hipotez 

Playlistę znajdziesz tutaj

Spis wystapień:

1. Czy wszyscy są researcherami? - Laura Lachowicz, Alicja Antkowiak 

2. The future is equal – Allegro Accessibility Research - Małgorzata Podolec 

3. Badania UX w projekcie transformacyjnym - Diana Jankowiak, Joanna Brudnik

4. Cyfrowe kohorty i inne dylematy. Refleksja badacza w pędzącym świecie - Katarzyna Drożdżal 

5. Koniec z silosami wiedzy - jak AI pomogło ożywić moje repozytorium badawcze - Weronika Denisiewicz 

6. Wielkość (efektu) ma znaczenie - Maria Chełkowska-Zacharewicz, Jan Dudzik 

7. Kiedyś to było... czyli które z tradycyjnych metod badawczych dalej są niezbędne - Jakub Dodot 

8. Dobre tłumaczenie to już za mało! - Piotr Adamiak, Anna Sieroń 

9. LLM-y w analizie jakościowej: mniej magii, więcej konkretów - Jakub Serek 

10. Human-Centered Design? - Aga Wilke-Trochymiak

Playlistę znajdziesz tutaj

Spis wystapień:

1. Czy wszyscy są researcherami? - Laura Lachowicz, Alicja Antkowiak 

2. The future is equal – Allegro Accessibility Research - Małgorzata Podolec 

3. Badania UX w projekcie transformacyjnym - Diana Jankowiak, Joanna Brudnik

4. Cyfrowe kohorty i inne dylematy. Refleksja badacza w pędzącym świecie - Katarzyna Drożdżal 

5. Koniec z silosami wiedzy - jak AI pomogło ożywić moje repozytorium badawcze - Weronika Denisiewicz 

6. Wielkość (efektu) ma znaczenie - Maria Chełkowska-Zacharewicz, Jan Dudzik 

7. Kiedyś to było... czyli które z tradycyjnych metod badawczych dalej są niezbędne - Jakub Dodot 

8. Dobre tłumaczenie to już za mało! - Piotr Adamiak, Anna Sieroń 

9. LLM-y w analizie jakościowej: mniej magii, więcej konkretów - Jakub Serek 

10. Human-Centered Design? - Aga Wilke-Trochymiak